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 then
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 7 July 2011 01:22, Laurent Pinchart
laurent.pinch...@ideasonboard.com 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
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.
If
this were removed
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
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 am...@ti.com
---
Changes from v1:
- updated commit message to mention that these changes are specifically
for OMAP4.
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 am...@ti.com
---
Changes from v1:
- Changed the definition
Minor changes to remove the unused code from omap_vout driver.
Signed-off-by: Amber Jain am...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
Changes from v1:
- None.
drivers/media/video/omap/omap_vout.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git
V4L2 side changes to add NV12-color format support to OMAP4.
Signed-off-by: Amber Jain am...@ti.com
---
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
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 for an
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 information is provided by
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-2011 10:20, Hans
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 marko.rist...@kolumbus.fi
wrote:
All that said, I believe that you are correct in that the business
logic needs to ultimately be decided by the bridge
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 mche...@redhat.com
diff --git
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
(V4L,
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 08:31, Hans
On Fri, 1 Jul 2011 15:37:30 +0200
Hans Verkuil hverk...@xs4all.nl 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,
On Thursday, July 07, 2011 18:42:55 Jonathan Corbet wrote:
On Fri, 1 Jul 2011 15:37:30 +0200
Hans Verkuil hverk...@xs4all.nl 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
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 Carvalho
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 sure that
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, move
its
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
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
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.
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
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)
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:
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: Jarod
On Thu, Jul 7, 2011 at 7:58 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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:
On Tue, Jul 5, 2011 at 1:21 PM, Greg KH g...@kroah.com 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
On Thu, Jul 07, 2011 at 08:28:12PM -0400, Jarod Wilson wrote:
On Thu, Jul 7, 2011 at 7:58 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
On Thu, Jul 07, 2011 at 08:31:28PM -0400, Jarod Wilson wrote:
On Tue, Jul 5, 2011 at 1:21 PM, Greg KH g...@kroah.com 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
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/
--
33 matches
Mail list logo
