This is the third version of this patch. The only change I've made is to
update three comments that were no longer in sync with the code after this
change. Thanks to Jonathan Corbet for pointing this out to me.
If there are no more comments, then I want to queue this for v3.1 via the
linux-media t
Hi!
I would like to have my patch[1] ready for linux 3.0. It's a simple
one-liner to solve an easy to fix problem. Is there anything I can do
o accelerate the review process?
Please, CC me your answers as I'm not subscribed to the list.
Tanks!
[1] https://patchwork.kernel.org/patch/849142/
--
T
On Thu, Jul 07, 2011 at 08:31:28PM -0400, Jarod Wilson wrote:
> On Tue, Jul 5, 2011 at 1:21 PM, Greg KH wrote:
> > On Thu, Jun 16, 2011 at 03:31:46PM -0400, Jarod Wilson wrote:
> >> There's really no good reason not to just grab the desired IRQ at driver
> >> init time, instead of every time the l
On Thu, Jul 07, 2011 at 08:28:12PM -0400, Jarod Wilson wrote:
> On Thu, Jul 7, 2011 at 7:58 PM, Dmitry Torokhov
> wrote:
> > On Fri, Jul 01, 2011 at 09:34:45PM +0200, Mauro Carvalho Chehab wrote:
> >> This is an automatic generated email to let you know that the following
> >> patch were queued a
On Tue, Jul 5, 2011 at 1:21 PM, Greg KH wrote:
> On Thu, Jun 16, 2011 at 03:31:46PM -0400, Jarod Wilson wrote:
>> There's really no good reason not to just grab the desired IRQ at driver
>> init time, instead of every time the lirc device node is accessed. This
>> also improves the speed and relia
On Thu, Jul 7, 2011 at 7:58 PM, Dmitry Torokhov
wrote:
> On Fri, Jul 01, 2011 at 09:34:45PM +0200, Mauro Carvalho Chehab wrote:
>> This is an automatic generated email to let you know that the following
>> patch were queued at the
>> http://git.linuxtv.org/media_tree.git tree:
>>
>> Subject: [med
On Fri, Jul 01, 2011 at 09:34:45PM +0200, Mauro Carvalho Chehab wrote:
> This is an automatic generated email to let you know that the following patch
> were queued at the
> http://git.linuxtv.org/media_tree.git tree:
>
> Subject: [media] rc: call input_sync after scancode reports
> Author: Jar
On Monday 04 July 2011 18:41:10 Hans von Marwijk wrote:
> In which GIT or HG repository can I find these patches.
They are not in any of my public repositories yet.
If you need a working driver, I recommend one of the following
repositories:
For kernel >= 2.6.32:
http://linuxtv.org/hg/~endriss/m
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.
Results of the daily build of v4l-dvb:
date:Thu Jul 7 19:00:41 CEST 2011
git hash:df6aabbeb2b8799d97f3886fc994c318bc6a6843
gcc version: i686-linux-gcc (GCC) 4.5
Hi.
IMO, your thoughts about core resource locking mechanism sound good.
I say here some thoughts and examples how the resource locking mechanism might
work.
IMHO, It's good enough now if we are heading to a solution.
At least I would not alone find a proper concept.
07.07.2011 18:14, Mauro Ca
unsubscribe
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Jonathan,
if you change the mt9v034_set_chip_control in mt9v034_configure to..
ret = mt9v034_set_chip_control(mt9v034, MT9V034_CHIP_CONTROL_RESERVED, 0); //
Clear bit 9 for normal operation
..it will start streaming as you startup the driver.
You could consider clearing all bits in mt9v034
Hi Mauro, Hans,
I am really surprised by the havoc caused by the little 2-line patch.
Let me sum up what I (don't) like in Hans' and Mauro's approaches:
Hans approach:
- extend v4l2_enum_dv_preset with fps and flags fields,
- allow enumerating presets by both index and preset code
- add standar
Em 07-07-2011 14:28, Hans Verkuil escreveu:
> On Thursday, July 07, 2011 19:15:24 Mauro Carvalho Chehab wrote:
>> Em 07-07-2011 12:29, Hans Verkuil escreveu:
>>> On Wednesday, July 06, 2011 20:03:52 Mauro Carvalho Chehab wrote:
Instead of having their own generic error codes at the MC API, mov
On Thursday, July 07, 2011 19:15:24 Mauro Carvalho Chehab wrote:
> Em 07-07-2011 12:29, Hans Verkuil escreveu:
> > On Wednesday, July 06, 2011 20:03:52 Mauro Carvalho Chehab wrote:
> >> Instead of having their own generic error codes at the MC API, move
> >> its section to the generic one and be su
Em 07-07-2011 12:29, Hans Verkuil escreveu:
> On Wednesday, July 06, 2011 20:03:52 Mauro Carvalho Chehab wrote:
>> Instead of having their own generic error codes at the MC API, move
>> its section to the generic one and be sure that all media ioctl's
>> will point to it.
>>
>> Signed-off-by: Mauro
On Thursday, July 07, 2011 18:42:55 Jonathan Corbet wrote:
> On Fri, 1 Jul 2011 15:37:30 +0200
> Hans Verkuil wrote:
>
> > In some cases the poll() implementation in a driver has to do different
> > things depending on the events the caller wants to poll for. An example is
> > when a driver needs
For the pvrusb2 portion of this patch:
Acked-By: Mike Isely
-Mike
On Wed, 6 Jul 2011, Mauro Carvalho Chehab wrote:
> Those drivers are not relying at the V4L2 core to handle the ioctl's.
> So, we need to manually patch them every time a change goes to the
> core.
>
> Signed-off-by: Mauro C
On Fri, 1 Jul 2011 15:37:30 +0200
Hans Verkuil wrote:
> In some cases the poll() implementation in a driver has to do different
> things depending on the events the caller wants to poll for. An example is
> when a driver needs to start a DMA engine if the caller polls for POLLIN,
> but doesn't wa
Em 07-07-2011 11:58, Hans Verkuil escreveu:
> On Thursday, July 07, 2011 15:52:53 Mauro Carvalho Chehab wrote:
>> Em 07-07-2011 08:33, Hans Verkuil escreveu:
>>> On Wednesday, July 06, 2011 21:39:46 Mauro Carvalho Chehab wrote:
Em 06-07-2011 09:14, Hans Verkuil escreveu:
>> Em 06-07-2011 0
Hi Daniel,
Thanks for the driver. Couple of quick queries. What do I need
for streaming mode (and does this work well for you?)
If I can get this working, I'm happy to pick up the job of patch
cleanup for you as a thank you.
Jonathan
> Hello again,
>
>> Hi Daniel,
>>
>> On Wednesday 01 June 20
On Wednesday, July 06, 2011 20:04:04 Mauro Carvalho Chehab wrote:
> This patch series contain some fixes on how error codes are handled
> at the media API's. It consists on two parts.
>
> The first part have the DocBook changes:
> - Create a generic errno xml file, used by all media API's
> (V4
On Wednesday, July 06, 2011 20:03:52 Mauro Carvalho Chehab wrote:
> Instead of having their own generic error codes at the MC API, move
> its section to the generic one and be sure that all media ioctl's
> will point to it.
>
> Signed-off-by: Mauro Carvalho Chehab
>
> diff --git a/Documentation/
Em 06-07-2011 16:59, Marko Ristola escreveu:
> 06.07.2011 21:17, Devin Heitmueller kirjoitti:
>> On Wed, Jul 6, 2011 at 1:53 PM, Marko Ristola
>> wrote:
>>>
>>
>> All that said, I believe that you are correct in that the business
>> logic needs to ultimately be decided by the bridge driver, rathe
On Thursday, July 07, 2011 15:52:53 Mauro Carvalho Chehab wrote:
> Em 07-07-2011 08:33, Hans Verkuil escreveu:
> > On Wednesday, July 06, 2011 21:39:46 Mauro Carvalho Chehab wrote:
> >> Em 06-07-2011 09:14, Hans Verkuil escreveu:
> Em 06-07-2011 08:31, Hans Verkuil escreveu:
> >> Em 05-07-
Em 07-07-2011 08:33, Hans Verkuil escreveu:
> On Wednesday, July 06, 2011 21:39:46 Mauro Carvalho Chehab wrote:
>> Em 06-07-2011 09:14, Hans Verkuil escreveu:
Em 06-07-2011 08:31, Hans Verkuil escreveu:
>> Em 05-07-2011 10:20, Hans Verkuil escreveu:
>>
I failed to see what inf
Hi Laurent,
On 07/06/2011 11:47 PM, Laurent Pinchart wrote:
> Hi Sylwester,
>
> On Wednesday 06 July 2011 19:13:39 Sylwester Nawrocki wrote:
>> On the SoCs this driver is intended to support the are three
>> separate pins to supply the MIPI-CSIS subsystem: 1.1V or 1.2V,
>> 1.8V and power supply f
V4L2 side changes to add NV12-color format support to OMAP4.
Signed-off-by: Amber Jain
---
drivers/media/video/omap/omap_vout.c| 107 ++
drivers/media/video/omap/omap_voutdef.h |3 +
2 files changed, 95 insertions(+), 15 deletions(-)
diff --git a/drivers/med
Minor changes to remove the unused code from omap_vout driver.
Signed-off-by: Amber Jain
Signed-off-by: Samreen
---
Changes from v1:
- None.
drivers/media/video/omap/omap_vout.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
Add support to map the buffer using dma_map_single during qbuf which inturn
calls cache flush and unmap the same during dqbuf. This is done to prevent
the artifacts seen because of cache-coherency issues on OMAP4
Signed-off-by: Amber Jain
---
Changes from v1:
- Changed the definition of address v
Extending the omap vout isr handling for:
- secondary lcd over DPI interface,
- HDMI interface.
These are the new interfaces added to OMAP4 DSS.
Signed-off-by: Amber Jain
---
Changes from v1:
- updated commit message to mention that these changes are specifically
for OMAP4.
drivers/media/vi
This patch set addresses following:
- Extend omap vout isr for secondary LCD over DPI panel.
- Extend omap vout isr for HDMI interface.
- DMA map and unmap the V4L2 buffers in qbuf and dqbuf so that they are
properly flushed into memory before DMA starts. If this not done we were
seeing artifac
On Wednesday, July 06, 2011 21:39:46 Mauro Carvalho Chehab wrote:
> Em 06-07-2011 09:14, Hans Verkuil escreveu:
> >> Em 06-07-2011 08:31, Hans Verkuil escreveu:
> Em 05-07-2011 10:20, Hans Verkuil escreveu:
>
> >> I failed to see what information is provided by the "presets" name.
> >
On 7 July 2011 01:22, Laurent Pinchart
wrote:
> Hi Javier,
>
> On Monday 04 July 2011 13:25:10 javier Martin wrote:
>> Hi, Laurent.
>> How is it going?
>>
>> Is there any chance these changes to be included for next release?
>> We are afraid that changes in the framework may turn the patches usele
Hi Laurent,
I found one problem about the uvc camera in my laptop on 3.0-rc6 and
previous kernel:
- no stream data received from camera after resume from system sleep
- will be ok again if reloading uvcvideo after resume
- no odd things are found from usb suspend and pm debug messages
Could you
On Thursday 07 July 2011 00:11:12 Andrew Morton wrote:
> I could review it and put it in there on a preliminary basis for some
> runtime testing. But the question in my mind is how different will the
> code be after the problems which rmk has identified have been fixed?
>
> If "not very different
36 matches
Mail list logo
