On 6 August 2011 04:56, Alistair Buxton wrote:
> Hi,
>
> With the latest driver my card never gets a signal lock, not even
> once. As before there are no error messages. It does always probe
> correctly now though.
I tracked this down to:
http://git.linuxtv.org/anttip/media_tree.git/commit/e5d3e
If there is not enough memory the allocated urb_list will not be freed.
Signed-off-by: Manoel Pinheiro
---
drivers/media/dvb/dvb-usb/usb-urb.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/usb-urb.c
b/drivers/media/dvb/dvb-usb/usb-urb.c
i
Hi,
With the latest driver my card never gets a signal lock, not even
once. As before there are no error messages. It does always probe
correctly now though.
On 5 August 2011 00:43, Antti Palosaari wrote:
> Hello,
> I have done some updates. MXL5005S based RTL2831U devices didn't worked
> due to
> > A simpler approach seems to be to only load the driver,
> when streaming is
> > required. Yes, it would add a (considerable) delay to
> streaming begin, but
> > you'd be completely honest to your user and privacy would
> be guaranteed.
>
> The delay will likely be close to the one introdu
On Fri, 5 Aug 2011 14:31:03 +1000 Stephen Rothwell wrote:
> Hi all,
>
> [The kernel.org mirroring is running slowly today]
Is media/radio/radio-sf16fmr2 an ISA driver or a PCI driver?
ugh. Or is it an I2C driver?
linux-next fails with (this is not a new failure):
ERROR: "snd_tea575x_init" [d
Em 05-08-2011 20:16, Guennadi Liakhovetski escreveu:
> On Fri, 5 Aug 2011, Andrew Chew wrote:
>
One way to solve this can be to defer these I2C
>>> transactions in the image sensor driver all the way up
to the time the image sensor is asked to start streaming
>>> frames. However, it s
On Fri, 5 Aug 2011, Andrew Chew wrote:
> > > One way to solve this can be to defer these I2C
> > transactions in the image sensor driver all the way up
> > > to the time the image sensor is asked to start streaming
> > frames. However, it seems to me that this breaks
> > > the spirit of the pr
Prepare the sh_mobile_ceu_camera friver to support the new
VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF ioctl()s. The .queue_setup()
vb2 operation must be able to handle buffer sizes, provided by the
caller, and the .buf_prepare() operation must not use the currently
configured frame format for its op
In preparation for the forthcoming VIDIOC_CREATE_BUFS ioctl change
the type of the sizes[] argument of the .queue_setup() vb2 operation
from unsigned long to unsigned int to match with the __u32 type of
buffer size variables elsewhere in V4L2. Drivers will also need the
fourcc value, passed along w
On Mon, 2011-07-25 at 19:34 +0100, Malcolm Priestley wrote:
> Firmware information for Kworld UB499-2T T09 based on IT913x series. This
> device
> uses file dvb-usb-it9137-01.fw.
>
>
> Signed-off-by: Malcolm Priestley
>
> ---
> Documentation/dvb/it9137.txt |9 +
> 1 files changed,
> > One way to solve this can be to defer these I2C
> transactions in the image sensor driver all the way up
> > to the time the image sensor is asked to start streaming
> frames. However, it seems to me that this breaks
> > the spirit of the probe; applications will successfully
> probe for c
Em 05-08-2011 17:18, Andrew Chew escreveu:
> I'm looking for some guidance regarding a clean way to support a certain
> camera module.
> We are using the soc_camera framework, and in particular, the ov9740.c image
> sensor driver.
>
> This camera module has the camera activity status LED tied
I'm looking for some guidance regarding a clean way to support a certain camera
module.
We are using the soc_camera framework, and in particular, the ov9740.c image
sensor driver.
This camera module has the camera activity status LED tied to the image
sensor's power. This is meant as a securi
Op 5 aug 2011, om 09:19 heeft Archit Taneja het volgende geschreven:
The DSS2 driver does not support the configuration of the
update_mode of a
panel anymore. Remove the setting of update_mode done in
omap_vout_probe().
Ignore configuration of TE since omap_vout driver doesn't support
manu
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:Fri Aug 5 19:00:59 CEST 2011
git hash:46540f7ac646ada7f22912ea7ea9b761ff5c4718
gcc version: i686-linux-gcc (GCC) 4.5
On Fri, 5 Aug 2011, Oliver Neukum wrote:
> Am Freitag, 5. August 2011, 00:56:03 schrieb Greg KH:
> > On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
> > > I know that this problem were somewhat solved for 3G modems, with the
> > > usage
> > > of the userspace problem usb_
On Fri, 5 Aug 2011, Hans de Goede wrote:
> Hi all,
>
> On 08/04/2011 02:34 PM, Mauro Carvalho Chehab wrote:
> > Em 03-08-2011 20:20, Theodore Kilgore escreveu:
>
>
>
> > > Yes, that kind of thing is an obvious problem. Actually, though, it may be
> > > that this had just better not happen. F
Sorry, just realized I mixed up callback names a bit in my previous
response. Let me rephrase:
Drivers may allow changing formats after buffers have been
initialized. This means that it's possible to s_fmt, reqbufs,
streamon, streamoff and s_fmt again without changing buffers. buf_init
will still
Hi Laurent,
On Fri, Aug 5, 2011 at 01:55, Laurent Pinchart
wrote:
> Hi Marek and Pawel,
>
> While reviewing an OMAP3 ISP patch, I noticed that videobuf2 doesn't verify
> the buffer length field value when a new USERPTR buffer is queued.
>
That's a good catch. We should definitely do something ab
Em 05-08-2011 04:45, Hans de Goede escreveu:
> Hi,
>
> On 08/05/2011 12:56 AM, Greg KH wrote:
>> On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
>>> I know that this problem were somewhat solved for 3G modems, with the usage
>>> of the userspace problem usb_modeswitch, and w
Hi Laurent,
On 08/05/2011 10:59 AM, Laurent Pinchart wrote:
>
> Hi Michael,
>
> Thanks for the patch.
>
> On Thursday 04 August 2011 17:40:37 Michael Jones wrote:
>> Add buffer length to sanity checks for QBUF.
>>
>> Signed-off-by: Michael Jones
>> ---
>> drivers/media/video/omap3isp/ispqueue
Hi Laurent,
On 07/20/2011 10:47 AM, Laurent Pinchart wrote:
>
> Hi Michael,
>
> Sorry for the late reply.
Likewise :)
>
> On Thursday 30 June 2011 10:31:52 Michael Jones wrote:
>> Hi Laurent,
>>
>> I'm observing a system freeze-up with the ISP when writing data to memory
>> directly from the
Hi Michael,
Thanks for the patch.
On Thursday 04 August 2011 17:40:37 Michael Jones wrote:
> Add buffer length to sanity checks for QBUF.
>
> Signed-off-by: Michael Jones
> ---
> drivers/media/video/omap3isp/ispqueue.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --
Hi Marek and Pawel,
While reviewing an OMAP3 ISP patch, I noticed that videobuf2 doesn't verify
the buffer length field value when a new USERPTR buffer is queued.
The length given by userspace is copied to the internal buffer length field.
It seems to be up to drivers to verify that the value i
Hi Mauro,
On Wed, 3 Aug 2011, Patrick Boettcher wrote:
Would you please pull from
git://linuxtv.org/pb/media_tree.git for_v3.0
for the following to changesets:
[media] dib0700: protect the dib0700 buffer access
[media] DiBcom: protect the I2C bufer access
I added a patch from Olivier which
Hi,
On 08/05/2011 09:59 AM, Oliver Neukum wrote:
Am Freitag, 5. August 2011, 09:45:56 schrieb Hans de Goede:
This is the issue on which I feel a bit stonewalled. Simple putting your
fingers in your ears and singing la la la do it in userspace is not going
to cut it here. There is no way to do t
Am Freitag, 5. August 2011, 09:45:56 schrieb Hans de Goede:
> This is the issue on which I feel a bit stonewalled. Simple putting your
> fingers in your ears and singing la la la do it in userspace is not going
> to cut it here. There is no way to do this race free in userspace, unless
> all possib
The two recently added ioctl()s VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF
allow user-space applications to allocate video buffers of different
sizes and hand them over to the driver for fast switching between
different frame formats. This patch adds support for buffers of different
sizes on the sam
This patch adds two new ioctl() handlers: .vidioc_create_bufs() and
.vidioc_prepare_buf() for compliant vb2 soc-camera hosts.
Signed-off-by: Guennadi Liakhovetski
---
Actually, there should be one more patch before this one - to convert
mx3-camera to the new API, otherwise it will break, if any
Replying to Hans' request here's an updated RFC with a new vb2 &
soc-camera implementation.
"v4" refers only to the actual "two new ioctl()s" patch, the rest are
being posted for the first or the second time only.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software D
Prepare the sh_mobile_ceu_camera friver to support the new
VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF ioctl()s. The .queue_setup()
vb2 operation must be able to handle buffer sizes, provided by the
caller, and the .buf_prepare() operation must not use the currently
configured frame format for its op
This patch prepares for a better separation of the buffer preparation
stage.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/video/videobuf2-core.c | 59 +
include/media/videobuf2-core.h |2 +
2 files changed, 39 insertions(+), 22 deletions(-)
In preparation for the forthcoming VIDIOC_CREATE_BUFS ioctl change
the type of the sizes[] argument of the .queue_setup() vb2 operation
from unsigned long to unsigned int to match with the __u32 type of
buffer size variables elsewhere in V4L2.
Signed-off-by: Guennadi Liakhovetski
---
drivers/med
A possibility to preallocate and initialise buffers of different sizes
in V4L2 is required for an efficient implementation of asnapshot mode.
This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and
VIDIOC_PREPARE_BUF and defines respective data structures.
Signed-off-by: Guennadi Liakhovetski
--
Hi,
On 08/05/2011 12:56 AM, Greg KH wrote:
On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
I know that this problem were somewhat solved for 3G modems, with the usage
of the userspace problem usb_modeswitch, and with some quirks for the USB
storage driver, but I'm not sur
Hello Jan,
On Fri, Aug 05, 2011 at 09:21:36AM +0200, Jan Pohanka wrote:
> Hello Uwe,
> thank you for the hint. There was problem with insufficient memory.
> dma_alloc_from_coherent is called several times and when I allocated
> only 4MB, last call failed. When I passed 8MB to
> dma_declare_coheren
Hello Uwe,
thank you for the hint. There was problem with insufficient memory.
dma_alloc_from_coherent is called several times and when I allocated
only 4MB, last call failed. When I passed 8MB to
dma_declare_coherent_memory, it works. Unfortunately I do not
understand why 4MB is not enough for 640
The DSS2 driver does not support the configuration of the update_mode of a
panel anymore. Remove the setting of update_mode done in omap_vout_probe().
Ignore configuration of TE since omap_vout driver doesn't support manual update
displays anyway.
Signed-off-by: Archit Taneja
---
drivers/media/v
Am Freitag, 5. August 2011, 00:56:03 schrieb Greg KH:
> On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
> > I know that this problem were somewhat solved for 3G modems, with the usage
> > of the userspace problem usb_modeswitch, and with some quirks for the USB
> > storage dr
Hi all,
On 08/04/2011 02:34 PM, Mauro Carvalho Chehab wrote:
Em 03-08-2011 20:20, Theodore Kilgore escreveu:
Yes, that kind of thing is an obvious problem. Actually, though, it may be
that this had just better not happen. For some of the hardware that I know
of, it could be a real problem n
40 matches
Mail list logo
