Hi Arnd,
Thanks for your review!
On Mon, Dec 5, 2011 at 10:48 PM, Arnd Bergmann wrote:
> On Friday 02 December 2011, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>
> This looks very nice, but there are a few things I don't understand yet
> and a bunch
Hi, Guennadi
Thank you for explain the label name rules. I've sent the v2 version
patch out. In v2 version I modified the code and make the label name
consistent.
On 12/06/2011 5:49PM, Guennadi Liakhovetski wrote:
> Hi Josh
> Thanks for the patch, but I'll ask you to fix the same thing in it,
t
Signed-off-by: Josh Wu
---
in v2 version, made the label name to be consistent
drivers/media/video/atmel-isi.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index ea4eef4..91ebcfb 100644
This patch
- add ISI_MCK clock enable/disable code.
- change field name in isi_platform_data structure
Signed-off-by: Josh Wu
[g.liakhovet...@gmx.de: fix label names]
Signed-off-by: Guennadi Liakhovetski
Acked-by: Nicolas Ferre
---
Hi, Guennadi
this is the v2 version of the patch series. it is
The ati_remote driver currently uses 2-byte scancodes. However, one of
those bytes is actually a checksum and therefore shouldn't be considered
as part of the scancode.
Fix the driver to only use the actual data byte as a scancode and to
check the checksum itself. Update the bundled keymaps accord
Hi Robert,
On Sunday 04 December 2011 08:33:34 Robert Åkerblom-Andersson wrote:
> Hi, I have been trying to get the mt9p031 driver to work with a
> LI-5M03 camera module and Beagleboard-xM rev C for week's now but I
> just can't get it right for some reason.
>
> I have an older version with 2.6.3
Hi Guennadi,
Thanks for the patch.
On Tuesday 06 December 2011 10:33:03 Guennadi Liakhovetski wrote:
> Improve the use of the WARN_ON() macro and use a local variable, instead
> of reduntantly dereferencing a pointer in v4l2-dev.c
>
> Signed-off-by: Guennadi Liakhovetski
Acked-by: Laurent Pinc
Been trying now to get my IrdetoCam and card working, im using mumudvb for this.
Turning on debug i get the folowing in the output
nfo: Autoconf: Channel number : 0, name : "ERT World" service id 0
Info: Autoconf: Multicast4 ip : 227.25.0.1:1234
Deb0: Autoconf: pids : 5001 (
On Tue, Dec 06, 2011 at 02:20:32PM -0200, Mauro Carvalho Chehab wrote:
> >1) After all the frames with the old resolution are dequeued a buffer
> >with the
> >following flags V4L2_BUF_FLAG_ERROR | V4L2_BUF_FLAG_WRONGFORMAT is
> >returned.
> >2) To acknowledge the resolution ch
On 12/06/2011 11:01 PM, Sylwester Nawrocki wrote:
[...]
>
> It might be much better as the v4l2 events are associated with the frame
> sequence. And if we use controls then you get control events for free,
> and each event carries a frame sequence number int it
> (http://linuxtv.org/downloads/v4l-d
On 12/06/2011 03:07 PM, Ming Lei wrote:
> Hi,
>
> Thanks for your review.
>
> On Tue, Dec 6, 2011 at 5:55 AM, Sylwester Nawrocki wrote:
>> Hi Ming,
>>
>> (I've pruned the Cc list, leaving just the mailing lists)
>>
>> On 12/02/2011 04:02 PM, Ming Lei wrote:
>>> This patch introduces one driver f
On 12/06/2011 10:58 PM, Mauro Carvalho Chehab wrote:
On 06-12-2011 12:13, Thierry Reding wrote:
* Antti Palosaari wrote:
That question is related to that kind of indentation generally, not
only that patch.
On 12/06/2011 03:39 PM, Thierry Reding wrote:
Function parameters on subsequent lines s
On 06-12-2011 12:13, Thierry Reding wrote:
* Antti Palosaari wrote:
That question is related to that kind of indentation generally, not
only that patch.
On 12/06/2011 03:39 PM, Thierry Reding wrote:
Function parameters on subsequent lines should never be aligned with the
function name but rath
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date:Tue Dec 6 19:00:17 CET 2011
git hash:2a887d27708a4f9f3b5ad8258f9e19a150b58f03
gcc version: i686-linux-gcc (GCC
On Wed, Dec 7, 2011 at 12:04 AM, Manu Abraham wrote:
> On Tue, Nov 29, 2011 at 8:01 PM, Mariusz Bialonczyk wrote:
>> This patch add support for reading UNC blocks for stv090x frontend.
>> Partially based on stv0900 code by Abylay Ospan
>>
>> Signed-off-by: Mariusz Bialonczyk
>> ---
>> drivers/
On Tue, Nov 29, 2011 at 8:01 PM, Mariusz Bialonczyk wrote:
> This patch add support for reading UNC blocks for stv090x frontend.
> Partially based on stv0900 code by Abylay Ospan
>
> Signed-off-by: Mariusz Bialonczyk
> ---
> drivers/media/dvb/frontends/stv090x.c | 32 +
Hi Laurent,
On 12/06/2011 05:12 PM, Laurent Pinchart wrote:
> On Thursday 01 December 2011 11:20:53 Sylwester Nawrocki wrote:
>> Update the sub-device drivers having a devnode enabled so they properly
>> handle the new framesamples field of struct v4l2_mbus_framefmt.
>> These drivers don't support
Hi Andreas
[...]
>>> You don't need to wait for write-only operations. Basically all demux
>>> ioctls are write-only. Since vtunerc is using dvb-core's software demux
>>> *locally*, errors for invalid arguments etc. will be returned as usual.
>>>
>>> What's left is one call to FE_SET_FRONTEND for
Hi Laurent,
On 12/06/2011 01:31 PM, Laurent Pinchart wrote:
> Hi Sylwester,
>
> On Sunday 04 December 2011 16:16:12 Sylwester Nawrocki wrote:
>> Change the V4L2_CID_FOCUS_AUTO control type from boolean to a menu
>> type. In case of boolean control we had values 0 and 1 corresponding
>> to manual
On Tue, Dec 6, 2011 at 7:49 PM, Mark Brown
wrote:
> On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote:
>> On 06.12.2011 12:21, Mark Brown wrote:
>> > On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote:
>
>> >> Are you serious? Lower networking layers should be tran
Hi Laurent,
On 12/06/2011 01:26 PM, Laurent Pinchart wrote:
> On Sunday 04 December 2011 16:16:13 Sylwester Nawrocki wrote:
>> From: Heungjun Kim
>>
>> The V4L2_CID_FOCUS_AUTO control has been converted from boolean type,
>> where control's value 0 and 1 were corresponding to manual and automatic
On 06-12-2011 14:11, Kamil Debski wrote:
From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
Sent: 06 December 2011 16:40
On 06-12-2011 13:19, Kamil Debski wrote:
From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
Sent: 06 December 2011 15:42
On 06-12-2011 12:28, 'Sakari Ailus' wrote:
Hi Laurent,
thanks for the comments.
On 12/06/2011 01:32 PM, Laurent Pinchart wrote:
> On Sunday 04 December 2011 16:16:14 Sylwester Nawrocki wrote:
>> The V4L2_CID_METERING_MODE control allows to determine what method
>> is used by the camera to measure the amount of light available for
>> autom
On 06-12-2011 12:35, Sakari Ailus wrote:
Hi Mauro,
On Fri, Dec 02, 2011 at 02:50:17PM -0200, Mauro Carvalho Chehab wrote:
On 02-12-2011 11:57, Sakari Ailus wrote:
Hi Mauro,
On Fri, Dec 02, 2011 at 10:35:40AM -0200, Mauro Carvalho Chehab wrote:
On 02-12-2011 08:31, Kamil Debski wrote:
Hi,
Y
Hi Sylwester,
On Thursday 01 December 2011 11:20:53 Sylwester Nawrocki wrote:
> Update the sub-device drivers having a devnode enabled so they properly
> handle the new framesamples field of struct v4l2_mbus_framefmt.
> These drivers don't support compressed (entropy encoded) formats so the
> fram
> From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
> Sent: 06 December 2011 16:40
>
> On 06-12-2011 13:19, Kamil Debski wrote:
> >> From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
> >> Sent: 06 December 2011 15:42
> >>
> >> On 06-12-2011 12:28, 'Sakari Ailus' wrote:
> >>> Hi all,
>
On 06-12-2011 13:28, Mark Lord wrote:
On 11-12-06 08:56 AM, Devin Heitmueller wrote:
On Tue, Dec 6, 2011 at 8:43 AM, Mauro Carvalho Chehab
wrote:
The driver who binds everything is the bridge driver. In your case, it is
the au0828 driver.
What you're experiencing seems to be some race issue
On 06-12-2011 13:19, Kamil Debski wrote:
From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
Sent: 06 December 2011 15:42
On 06-12-2011 12:28, 'Sakari Ailus' wrote:
Hi all,
On Tue, Dec 06, 2011 at 01:00:59PM +0100, Laurent Pinchart wrote:
...
2) new requirement is for a bigger buffer. DMA
On Tue, Dec 6, 2011 at 8:36 PM, Mauro Carvalho Chehab
wrote:
> On 06-12-2011 12:38, Andreas Oberritter wrote:
>>
>> On 06.12.2011 15:13, Mauro Carvalho Chehab wrote:
>>>
>>> O_NONBLOCK
>>> When opening a FIFO with O_RDONLY or O_WRONLY set:
>>
>> This does not apply.
>
On Tue, Dec 6, 2011 at 10:28 AM, Mark Lord wrote:
> It's always exhibited races for me here. I have long since worked around
> the issue(s), so my own systems currently behave. But with the newer
> HVR-950Q revision (B4F0), the issue is far more prevalent than before.
I'll ask around and see i
On Tue, Dec 06, 2011 at 01:16:58PM +, Arnd Bergmann wrote:
> On Monday 05 December 2011, Rob Clark wrote:
> > > On the topic of a coherency model for dmabuf, I think we need to look at
> > > dma_buf_attachment_map/unmap (and also the mmap variants cpu_start and
> > > cpu_finish or whatever they
On 11-12-06 08:56 AM, Devin Heitmueller wrote:
> On Tue, Dec 6, 2011 at 8:43 AM, Mauro Carvalho Chehab
> wrote:
>> The driver who binds everything is the bridge driver. In your case, it is
>> the au0828 driver.
>>
>> What you're experiencing seems to be some race issue inside it, and not at
>> xc5
> From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
> Sent: 06 December 2011 15:42
>
> On 06-12-2011 12:28, 'Sakari Ailus' wrote:
> > Hi all,
> >
> > On Tue, Dec 06, 2011 at 01:00:59PM +0100, Laurent Pinchart wrote:
> > ...
> >>> 2) new requirement is for a bigger buffer. DMA transfers n
On 06-12-2011 12:38, Andreas Oberritter wrote:
On 06.12.2011 15:13, Mauro Carvalho Chehab wrote:
O_NONBLOCK
When opening a FIFO with O_RDONLY or O_WRONLY set:
This does not apply.
[...]
When opening a block special or character special file that supports
On 06.12.2011 15:19, Rémi Denis-Courmont wrote:
> Le mardi 6 décembre 2011 15:49:11 Andreas Oberritter, vous avez écrit :
>> You don't need to wait for write-only operations. Basically all demux
>> ioctls are write-only. Since vtunerc is using dvb-core's software demux
>> *locally*, errors for inva
> From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
> Sent: 06 December 2011 15:36
>
> Hi Mauro,
>
> On Fri, Dec 02, 2011 at 02:50:17PM -0200, Mauro Carvalho Chehab wrote:
> > On 02-12-2011 11:57, Sakari Ailus wrote:
> > >Hi Mauro,
> > >
> > >On Fri, Dec 02, 2011 at 10:35:40AM -0200, Mauro Carvalho
On 06.12.2011 15:20, Mauro Carvalho Chehab wrote:
> On 06-12-2011 11:49, Andreas Oberritter wrote:
>> On 06.12.2011 14:22, Mauro Carvalho Chehab wrote:
>>> On 05-12-2011 22:07, HoP wrote:
> I doubt that scan or w_scan would support it. Even if it supports,
> that
> would mean that,
On 06.12.2011 15:19, Mark Brown wrote:
> On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote:
>> On 06.12.2011 12:21, Mark Brown wrote:
>>> On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote:
>
Are you serious? Lower networking layers should be transparent to th
On 06-12-2011 12:28, 'Sakari Ailus' wrote:
Hi all,
On Tue, Dec 06, 2011 at 01:00:59PM +0100, Laurent Pinchart wrote:
...
2) new requirement is for a bigger buffer. DMA transfers need to be
stopped before actually writing inside the buffer (otherwise, memory
will be corrupted).
In this case, al
On 06.12.2011 15:13, Mauro Carvalho Chehab wrote:
> O_NONBLOCK
> When opening a FIFO with O_RDONLY or O_WRONLY set:
This does not apply.
[...]
> When opening a block special or character special file that supports
> non-blocking opens:
>
> If O_NONBLOCK
Hi Mauro,
On Fri, Dec 02, 2011 at 02:50:17PM -0200, Mauro Carvalho Chehab wrote:
> On 02-12-2011 11:57, Sakari Ailus wrote:
> >Hi Mauro,
> >
> >On Fri, Dec 02, 2011 at 10:35:40AM -0200, Mauro Carvalho Chehab wrote:
> >>On 02-12-2011 08:31, Kamil Debski wrote:
> >>>Hi,
> >>>
> >>>Yesterday we had a
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042).
This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;
For this device, the ZARLINK456 define is set to true so it is using the
firmwares with ty
xc3028: force reload of DTV7 firmware in VHF band as DTV78 firmware is
not working with bw=7 MHz.
The patch is effective only with Zarlink demodulators.
Signed-off-by: Gianluca Gennari
---
drivers/media/common/tuners/tuner-xc2028.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
di
Hi all,
On Tue, Dec 06, 2011 at 01:00:59PM +0100, Laurent Pinchart wrote:
...
> > > >>> 2) new requirement is for a bigger buffer. DMA transfers need to be
> > > >>> stopped before actually writing inside the buffer (otherwise, memory
> > > >>> will be corrupted).
> > > >>>
> > > >>> In this case,
On 06-12-2011 11:49, Andreas Oberritter wrote:
On 06.12.2011 14:22, Mauro Carvalho Chehab wrote:
On 05-12-2011 22:07, HoP wrote:
I doubt that scan or w_scan would support it. Even if it supports, that
would mean that,
for each ioctl that would be sent to the remote server, the error
code would
Le mardi 6 décembre 2011 15:49:11 Andreas Oberritter, vous avez écrit :
> You don't need to wait for write-only operations. Basically all demux
> ioctls are write-only. Since vtunerc is using dvb-core's software demux
> *locally*, errors for invalid arguments etc. will be returned as usual.
That's
On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote:
> On 06.12.2011 12:21, Mark Brown wrote:
> > On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote:
> >> Are you serious? Lower networking layers should be transparent to the
> >> upper layers. You don't implement VPN
* Antti Palosaari wrote:
> That question is related to that kind of indentation generally, not
> only that patch.
>
> On 12/06/2011 03:39 PM, Thierry Reding wrote:
> >Function parameters on subsequent lines should never be aligned with the
> >function name but rather be indented.
> [...]
> >
On 06-12-2011 11:35, Andreas Oberritter wrote:
On 06.12.2011 14:10, Mauro Carvalho Chehab wrote:
On 06-12-2011 10:01, Andreas Oberritter wrote:
On 06.12.2011 12:18, Mark Brown wrote:
On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
On 05.12.2011 21:55, Alan Cox wrote:
The
Hi,
Thanks for your review.
On Tue, Dec 6, 2011 at 5:55 AM, Sylwester Nawrocki wrote:
> Hi Ming,
>
> (I've pruned the Cc list, leaving just the mailing lists)
>
> On 12/02/2011 04:02 PM, Ming Lei wrote:
>> This patch introduces one driver for face detection purpose.
>>
>> The driver is responsib
That question is related to that kind of indentation generally, not only
that patch.
On 12/06/2011 03:39 PM, Thierry Reding wrote:
Function parameters on subsequent lines should never be aligned with the
function name but rather be indented.
[...]
usb_set_interface(dev
On Tue, Dec 6, 2011 at 8:43 AM, Mauro Carvalho Chehab
wrote:
> The driver who binds everything is the bridge driver. In your case, it is
> the au0828 driver.
>
> What you're experiencing seems to be some race issue inside it, and not at
> xc5000.
>
> On a quick look on it, I'm noticing that there'
On 06.12.2011 14:22, Mauro Carvalho Chehab wrote:
> On 05-12-2011 22:07, HoP wrote:
>>> I doubt that scan or w_scan would support it. Even if it supports, that
>>> would mean that,
>>> for each ioctl that would be sent to the remote server, the error
>>> code would
>>> take 480 ms
>>> to return. Tr
On 06-12-2011 10:51, Mark Lord wrote:
On 11-12-05 06:47 PM, Devin Heitmueller wrote:
On Mon, Dec 5, 2011 at 6:32 PM, Eddi De Pieri wrote:
Sorry, I think I applied follow patch on my tree while I developed
the driver trying to fix tuner initialization.
http://patchwork.linuxtv.org/patch/6617/
Function parameters on subsequent lines should never be aligned with the
function name but rather be indented.
Signed-off-by: Thierry Reding
---
drivers/media/video/tm6000/tm6000-video.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/tm6000/tm60
Checking for &dev->int_in is useless because it returns the address of
the embedded struct tm6000_endpoint, which will always be positive and
therefore true.
Signed-off-by: Thierry Reding
---
drivers/media/video/tm6000/tm6000-input.c |2 +-
drivers/media/video/tm6000/tm6000-video.c |2 +-
On 06.12.2011 14:10, Mauro Carvalho Chehab wrote:
> On 06-12-2011 10:01, Andreas Oberritter wrote:
>> On 06.12.2011 12:18, Mark Brown wrote:
>>> On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
On 05.12.2011 21:55, Alan Cox wrote:
> The USB case is quite different becaus
On 05-12-2011 22:07, HoP wrote:
I doubt that scan or w_scan would support it. Even if it supports, that
would mean that,
for each ioctl that would be sent to the remote server, the error code would
take 480 ms
to return. Try to calculate how many time w_scan would work with that. The
calculus is
On Monday 05 December 2011, Rob Clark wrote:
> > On the topic of a coherency model for dmabuf, I think we need to look at
> > dma_buf_attachment_map/unmap (and also the mmap variants cpu_start and
> > cpu_finish or whatever they might get called) as barriers:
> >
> > So after a dma_buf_map, all pre
On 06-12-2011 10:01, Andreas Oberritter wrote:
On 06.12.2011 12:18, Mark Brown wrote:
On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
On 05.12.2011 21:55, Alan Cox wrote:
The USB case is quite different because your latency is very tightly
bounded, your dead device state is
The original patch used the fast USB quirk to enable fast access to
registers in the tm6000_read_write_usb(). The applied patch moved the
check to the tm6000_reset(), probably due to some merge conflicts.
Signed-off-by: Thierry Reding
---
drivers/media/video/tm6000/tm6000-core.c |4 +++-
1 f
On 11-12-05 06:47 PM, Devin Heitmueller wrote:
> On Mon, Dec 5, 2011 at 6:32 PM, Eddi De Pieri wrote:
>> Sorry, I think I applied follow patch on my tree while I developed
>> the driver trying to fix tuner initialization.
>>
>> http://patchwork.linuxtv.org/patch/6617/
>>
>> I forgot to remove fro
Hi Sylwester,
On Sunday 04 December 2011 16:16:11 Sylwester Nawrocki wrote:
> Hi All,
>
> I put some effort in preparing a documentation for a couple of new controls
> in the camera control class. It's a preeliminary work, it's mainly just
> documentation. There is yet no patches for any driver u
Hi Sylwester,
On Sunday 04 December 2011 16:16:14 Sylwester Nawrocki wrote:
> The V4L2_CID_METERING_MODE control allows to determine what method
> is used by the camera to measure the amount of light available for
> automatic exposure control.
>
> Signed-off-by: Sylwester Nawrocki
> ---
> Docum
Hi Sylwester,
On Sunday 04 December 2011 16:16:12 Sylwester Nawrocki wrote:
> Change the V4L2_CID_FOCUS_AUTO control type from boolean to a menu
> type. In case of boolean control we had values 0 and 1 corresponding
> to manual and automatic focus respectively.
>
> The V4L2_CID_FOCUS_AUTO menu co
Hi Sylwester and Heungjun,
On Sunday 04 December 2011 16:16:13 Sylwester Nawrocki wrote:
> From: Heungjun Kim
>
> The V4L2_CID_FOCUS_AUTO control has been converted from boolean type,
> where control's value 0 and 1 were corresponding to manual and automatic
> focus respectively, to menu type wi
On 06-12-2011 06:12, Thierry Reding wrote:
* Thierry Reding wrote:
* Mauro Carvalho Chehab wrote:
That means that all we need is to get rid of TM6000_QUIRK_NO_USB_DELAY.
I've just reviewed my patches again and it seems that no-USB-delay quirk
patch was only partially applied. The actual locat
On 06-12-2011 04:51, Thierry Reding wrote:
* Mauro Carvalho Chehab wrote:
That means that all we need is to get rid of TM6000_QUIRK_NO_USB_DELAY.
I've just reviewed my patches again and it seems that no-USB-delay quirk
patch was only partially applied. The actual location where it was introduc
On Tue, 6 Dec 2011, Laurent Pinchart wrote:
> Hi Guennadi,
>
> On Tuesday 06 December 2011 09:40:41 Guennadi Liakhovetski wrote:
> > On Thu, 29 Sep 2011, Laurent Pinchart wrote:
> > > On Thursday 29 September 2011 10:44:14 Guennadi Liakhovetski wrote:
> > > > On Thu, 29 Sep 2011, Laurent Pinchart
On 06.12.2011 12:21, Mark Brown wrote:
> On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote:
>> On 05.12.2011 18:39, Mauro Carvalho Chehab wrote:
>
>>> When you put someone via the network, issues like latency, package
>>> drops, IP
>>> congestion, QoS issues, cryptography, tunnel
On 06.12.2011 12:18, Mark Brown wrote:
> On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
>> On 05.12.2011 21:55, Alan Cox wrote:
>>> The USB case is quite different because your latency is very tightly
>>> bounded, your dead device state is rigidly defined, and your loss of
>>>
Hi Kamil,
On Friday 02 December 2011 18:32:33 Kamil Debski wrote:
> Hi,
>
> Thank you for your comments, Mauro!
>
> Laurent there is a question for you below, so it would be great
> if you could spare a minute and have a look.
Sure :-)
> On 02 December 2011 18:08 Mauro Carvalho Chehab wrote:
>
On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote:
> On 05.12.2011 18:39, Mauro Carvalho Chehab wrote:
> > When you put someone via the network, issues like latency, package
> > drops, IP
> > congestion, QoS issues, cryptography, tunneling, etc should be taken
> > into account
>
On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
> On 05.12.2011 21:55, Alan Cox wrote:
> > The USB case is quite different because your latency is very tightly
> > bounded, your dead device state is rigidly defined, and your loss of
> > device is accurately and immediately signa
On Tue, Dec 06, 2011 at 11:13:19AM +0100, Olivier Grenie wrote:
> Dear Dan,
> Indeed, after the "if (state->rf_ramp == NULL)" test, the function
> dib0090_set_rframp_pwm will set the state->rf_ramp. So after this
> line, state->rf_ramp can not be NULL.
>
Ah right. I should have seen that myself.
Hi Guennadi,
On Tuesday 06 December 2011 09:40:41 Guennadi Liakhovetski wrote:
> On Thu, 29 Sep 2011, Laurent Pinchart wrote:
> > On Thursday 29 September 2011 10:44:14 Guennadi Liakhovetski wrote:
> > > On Thu, 29 Sep 2011, Laurent Pinchart wrote:
> > > > On Thursday 29 September 2011 10:18:31 Gu
Dear Dan,
Indeed, after the "if (state->rf_ramp == NULL)" test, the function
dib0090_set_rframp_pwm will set the state->rf_ramp. So after this line,
state->rf_ramp can not be NULL.
But I can make a patch in order to make sure that this code will not be
detected as an error.
Regards,
Olivier
-
Hi Josh
Thanks for the patch, but I'll ask you to fix the same thing in it, that
I've fixed for you in the first patch in this series:
On Wed, 30 Nov 2011, Josh Wu wrote:
> Signed-off-by: Josh Wu
> ---
> drivers/media/video/atmel-isi.c | 17 -
> 1 files changed, 16 insertion
Improve the use of the WARN_ON() macro and use a local variable, instead
of reduntantly dereferencing a pointer in v4l2-dev.c
Signed-off-by: Guennadi Liakhovetski
---
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index a5c9ed1..6a07d28 100644
--- a/drivers/media/vi
On Tue, 6 Dec 2011, Guennadi Liakhovetski wrote:
> Hi Mauro
>
> Here a couple of fixes for 3.2. You've already applied the mt9t112 patch
> from Dan, but only to your 3.3 branch, it certainly has to go to 3.2 too.
Sorry, forgot one more fix (same branch updated):
The following changes since com
Hi Peter,
Thank you for your patch!
I'll include it with the patches we'll be sending to Mauro.
Best wishes,
--
Kamil Debski
Linux Platform Group
Samsung Poland R&D Center
> -Original Message-
> From: Peter Korsgaard [mailto:jac...@gmail.com] On Behalf Of Peter Korsgaard
> Sent: 05 Dece
Hi Laurent
On Thu, 29 Sep 2011, Laurent Pinchart wrote:
> Hi Guennadi,
>
> On Thursday 29 September 2011 10:44:14 Guennadi Liakhovetski wrote:
> > On Thu, 29 Sep 2011, Laurent Pinchart wrote:
> > > On Thursday 29 September 2011 10:18:31 Guennadi Liakhovetski wrote:
> > > > Drivers, that can be b
On 12/06/11 00:37, Eddi De Pieri wrote:
try using scan from dvb-apps and not w_scan.
Actually It seems to me w_scan isn't compatible with this driver due
some missing lock.
I've tired dvbscan (=scan on Gentoo?). Apperently I need some initial
scan file and I found one here:
http://www.mail
* Thierry Reding wrote:
> * Mauro Carvalho Chehab wrote:
> > That means that all we need is to get rid of TM6000_QUIRK_NO_USB_DELAY.
>
> I've just reviewed my patches again and it seems that no-USB-delay quirk
> patch was only partially applied. The actual location where it was introduced
> was in
Hi Mauro
Here a couple of fixes for 3.2. You've already applied the mt9t112 patch
from Dan, but only to your 3.3 branch, it certainly has to go to 3.2 too.
The following changes since commit 8e8da023f5af71662867729db5547dc54786093c:
x86: Fix boot failures on older AMD CPU's (2011-12-04 11:57:
85 matches
Mail list logo
