Re: [RFCv3 PATCH 12/18] vb2_poll: don't start DMA, leave that to the first read().

[Hans Verkuil]

On Tuesday, June 28, 2011 15:58:36 Hans Verkuil wrote:
> On Tuesday, June 28, 2011 14:43:22 Mauro Carvalho Chehab wrote:
> > Em 28-06-2011 09:21, Andy Walls escreveu:
> > > Mauro Carvalho Chehab  wrote:
> > 
> > >> I'm not very comfortable with vb2 returning unexpected errors there.
> > >> Also,
> > >> for me it is clear that, if read will fail, POLLERR should be rised.
> > >>
> > >> Mauro. 
> > >> --
> > >> 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
> > > 
> > > It is also the case that a driver's poll method should never sleep.
> > 
> > True.
> 
> Actually, it is allowed, but only since kernel 2.6.29 (before that it could
> apparently give rise to busy looping if you were unlucky). But the main use
> case is userspace file systems like fuse. Not so much in regular drivers.
> 
> Since drivers can sleep when starting streaming (ivtv will do that, in any
> case), we were in violation of the poll kernel API for a long time :-)
> 
> > > I will try to find the conversation I had with laurent on interpreting 
> > > the POSIX spec on error returns from select() and poll().  I will also 
> > > try to find links to previos discussion with Hans on this.
> > > 
> > > One issue is how to start streaming with apps that:
> > > - Open /dev/video/ in a nonblocking mode, and
> > > - Use the read() method
> > > 
> > > while doing it in a way that is POSIX compliant and doesn't break 
> > > existing apps.  
> > 
> > Well, a first call for poll() may rise a thread that will prepare the 
> > buffers, and
> > return with 0 while there's no data available.
> 
> There is actually no guarantee whatsoever that if poll says you can read(), 
> that that
> read also has to succeed. Other threads can have read the data already, and 
> errors may
> have occured. And in fact, just starting streaming gives no guarantee that 
> there is
> anything to read. For example, starting the DMA engine when there is no valid 
> input
> signal. Many drivers (certainly those dealing with digital interfaces as 
> opposed to
> analog) will just sit and wait. A non-blocking read will just return 0 without
> reading anything.
> 
> So the current poll implementation (and that includes the one in 
> videobuf-core.c as
> well) actually does *not* give any guarantee about whether data will be 
> available
> in read().

Never mind this. I didn't look carefully enough: it does start the DMA and then 
poll
waits for data to arrive. So when poll says there is data, then there is really 
data.
Although applications should always handle EAGAIN anyway: some drivers do 
return it,
even when data is supposed to be available (I had to add that to qv4l2 at one 
time).

Regards,

Hans

> 
> And from the same POSIX link you posted:
> 
> "The poll() function shall support regular files, terminal and 
> pseudo-terminal devices,
> FIFOs, pipes, sockets and [XSR] [Option Start]  STREAMS-based files. [Option 
> End]
> The behavior of poll() on elements of fds that refer to other types of file 
> is unspecified."
> 
> Note the last line: we do not fall under this posix document.
>  
> > > The other constraint is to ensure when only poll()-ing for exception 
> > > conditions, not having significant IO side effects.
> > > 
> > > I'm pretty sure sleeping in a driver's poll() method, or having 
> > > significant side effects, is not ine the spirit of the POSIX select() and 
> > > poll(), even if the letter of POSIX says nothing about it.
> > > 
> > > The method I suggested to Hans is completely POSIX compliant for apps 
> > > using read() and select() and was checked against MythTV as having no bad 
> > > side effects.  (And by thought experiment doesn't break any sensible app 
> > > using nonblocking IO with select() and read().)
> > > 
> > > I did not do analysis for apps that use mmap(), which I guess is the 
> > > current concern.
> 
> There isn't a problem with mmap(). For the stream I/O API you have to call 
> STREAMON
> explicitly in order to start streaming. poll() will not do that for you.
> 
> I was thinking that one improvement that could be realized is that vb2_poll 
> could
> do some basic checks, such as checking whether streaming was already in 
> progress
> (EBUSY), but then I realized that it already does that: this code is only 
> active
> if there is no streaming in progress anyway.
> 
> Regards,
> 
>   Hans
> 
> > 
> > The concern is that it is pointing that there are available data, even when 
> > there is an error.
> > This looks like a POSIX violation for me.
> > 
> > Cheers,
> > Mauro.
> > --
> > 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
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>

Re: [RFCv3 PATCH 12/18] vb2_poll: don't start DMA, leave that to the first read().

[Andy Walls]

On Tue, 2011-06-28 at 21:00 -0300, Mauro Carvalho Chehab wrote:
> Em 28-06-2011 20:14, Andy Walls escreveu:
> > On Tue, 2011-06-28 at 09:43 -0300, Mauro Carvalho Chehab wrote:
> >> Em 28-06-2011 09:21, Andy Walls escreveu:
> > 
> >>> It is also the case that a driver's poll method should never sleep.
> >>
> >> True.
> > 
> >>> One issue is how to start streaming with apps that:
> >>> - Open /dev/video/ in a nonblocking mode, and
> >>> - Use the read() method
> >>>
> >>> while doing it in a way that is POSIX compliant and doesn't break 
> >>> existing apps.  
> >>
> >> Well, a first call for poll() may rise a thread that will prepare the 
> >> buffers, and
> >> return with 0 while there's no data available.
> > 
> > Sure, but that doesn't solve the problem of an app only select()-ing or
> > poll()-ing for exception fd's and not starting any IO.
> 
> Well, a file descriptor can be used only for one thing: or it is a stream file
> descriptor, or it is an event descriptor. You can't have both for the same
> file descriptor. If an application need to check for both, the standard Unix 
> way is:
> 
>   fd_set set;
> 
>   FD_ZERO (&set);
>   FD_SET (fd_stream, &set);
>   FD_SET (fd_event, &set);
> 
>   select (FD_SETSIZE, &set, NULL, NULL, &timeout);
> 
> In other words, or the events nodes need to be different, or an ioctl is 
> needed
> in order to tell the Kernel that the associated file descriptor will be used
> for an event, and that vb2 should not bother with it.

Um, no, that is not correct for Unix fd's and socket descriptors in
general.  I realize that v4l2 events need to be enabled with an ioctl(),
but do we have a restriction that that can't happen on the same fd as
the one used for streaming?

Back in the days before threads were commonly available on Unix systems,
a process would use a single thread calling select() to handle I/O on a
serial port:

fd_set rfds, wfds;
int ttyfd;
...
FD_ZERO(&rfds);
FD_SET(ttyfd, &rfds);
FD_ZERO(&wfds);
FD_SET(ttyfd, &wfds);

n = select(ttyfd+1, &rfds, &wfds, NULL, NULL);

Or TCP socket

fd_set rfds, wfds, efds;
int sockd;
...
FD_ZERO(&rfds);
FD_SET(sockd, &rfds);
FD_ZERO(&wfds);
FD_SET(sockd, &wfds);
FD_ZERO(&efds);
FD_SET(sockd, &efds);

n = select(sockd+1, &rfds, &wfds, &efds, NULL);



> >>> The other constraint is to ensure when only poll()-ing for exception
> >> conditions, not having significant IO side effects.
> >>>
> >>> I'm pretty sure sleeping in a driver's poll() method, or having
> >> significant side effects, is not ine the spirit of the POSIX select()
> >> and poll(), even if the letter of POSIX says nothing about it.
> >>>
> >>> The method I suggested to Hans is completely POSIX compliant for
> >> apps using read() and select() and was checked against MythTV as
> >> having no bad side effects.  (And by thought experiment doesn't break
> >> any sensible app using nonblocking IO with select() and read().)
> >>>
> >>> I did not do analysis for apps that use mmap(), which I guess is the
> >> current concern.
> >>
> >> The concern is that it is pointing that there are available data, even
> >> when there is an error.
> >> This looks like a POSIX violation for me.
> > 
> > It isn't.
> > 
> > From the specification for select():
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/select.html
> > 
> > "A descriptor shall be considered ready for reading when a call to an
> > input function with O_NONBLOCK clear would not block, whether or not the
> > function would transfer data successfully. (The function might return
> > data, an end-of-file indication, or an error other than one indicating
> > that it is blocked, and in each of these cases the descriptor shall be
> > considered ready for reading.)"
> 
> My understanding from the above is that "ready" means:
>   - data;
>   - EOF;
>   - error.

Waiting for data to arrive on an fd, while not streaming is an error
condition for select() should return.  Something has to be done about
that fd in that case, or select()-ing on it is futile.


> if POLLIN (or POLLOUT) is returned, it should mean one of the above, e. g.
> the device is ready to provide data or some error occurred.
> 
> Btw, we're talking about poll(), and not select(). The poll() doc is clearer
> (http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html):
> 
> POLLIN
> Data other than high-priority data may be read without blocking. 
> 
> POLLOUT
> Normal data may be written without blocking. 
> 
> Saying that a -EAGAIN means that data is "ready" is an API abuse.

EAGAIN is the correct errno fo the read that returns no data.  The abuse
is the revent value returned from poll().  However, for any application
that open()s a device node that supports mutliple open()s, it is a valid
circumstance that can happen with POSIX.

One way to avoid abusing the rev

Re: HVR-1250/CX23885 IR Rx

[Andy Walls]

On Tue, 2011-06-28 at 22:17 -0400, Jarod Wilson wrote:
> On Jun 28, 2011, at 6:32 PM, Andy Walls wrote:
> 
> > On Tue, 2011-06-28 at 17:39 -0400, Jarod Wilson wrote:
> > 
> >> I'm thinking that in the
> >> short-term, we should probably make sure msi doesn't get enabled in
> >> the cx23885 driver, and longer-term, we can look at fixing it.
> > 
> > Sounds fine.  But fixcing the cx23885 driver to deal with both PCIe
> > emulation of legacy PCI INTx and PCIe MSI will likely be very involved.
> > (Maybe I'm wrong?)
> 
> I'm not sure either, but I know a few PCI gurus at work who could
> probably lend some insight.
> 
> 
> > Taking a trip down memory lane to 2 Dec 2010...
> > http://www.spinics.net/lists/linux-media/msg25956.html
> 
> Man. I really gotta learn to search the list archive (and bugzillas
> assigned to me...) before sending mail to the list, eh? ;)

You seem to stumble across things that I happened to run across about
6-7 months ago.  So use that as your starting search window. ;)


> > On Wed, 2010-12-01 at 21:52 -0800, David Liontooth wrote:
> >> On 11/29/2010 04:38 AM, Andy Walls wrote:
> >>> On Sun, 2010-11-28 at 23:49 -0800, David Liontooth wrote:
> > 
> >>> For a quick band-aid, use "pci=nomsi" on your kernel command line, and
> >>> reboot to reset the CX23888 hardware.
> >>> 
> >>> The problem is MSI.  The cx23885 driver isn't ready for it.  The patch
> >>> that enabled MSI for cx23885 probably needs to be reverted until some of
> >>> these issues are sorted out.
> > 
> >> -- what do we lose by removing the MSI support patch?
> > 
> > Problems mostly. The driver was written to work with emulated legacy PCI
> > INTx interrupts, which are to be treated as level triggered, and not
> > PCIe MSI, which are to be treated as edge triggered.  That's why I say
> > the cx23885 driver isn't ready for MSI, but I'm not sure how involved an
> > audit and conversion would be.  I know an audit will take time and
> > expertise.
> 
> Dropping msi support looks to be quite trivial,

It is trivial.

>  I got the card behaving
> after only a few lines of change in cx23885-core.c without having to pass
> in pci=nomsi, but I *only* tried IR, I haven't tried video capture. I'll
> see if I can give that a spin tomorrow, and if that behaves, I can send
> along the diff.

It should.  MSI was an ill tested addition to cx23885 IMHO.

BTW, IR interrupts with the CX23885 IR unit are tricky.  The CX23885
(CX25843) A/V core is I2C connected.  Getting the A/V core to clear it's
INT_N line (wired to the main core of the CX23885) requires clearing all
the audio, video, and IR interrupts in the A/V core unit.  The video and
audio interrupts from the A/V core are currently masked.  The IR
interrupts have to be cleared by actually servicing the IR unit.

To deal with that headache, when an A/V core interrupt comes in, I
masked the PCI_AVCORE_INT (or whatever) interuupt on the CX23885 bridge
until the IR unit can be serviced.  Since the A/V core is I2C connected,
the IR unit is serviced in a workqueue work handler thread, where
sleeping is allowed.

I'm not sure how MSI can get a storming or stuck interrupt from the
CX23885 with me masking the PCI_AVCORE_INT.

IIRC the cx23885_irq handler calls some functions that might take a long
time to execute.  Maybe that matters with MSI enabled.  With MSI
disabled, you might want to set up ftrace on the cx23885 driver
functions and look to see if there are any slow paths being encountered
by the cx23885_irq handler.  I suspect the cx23885_irq handler should be
deferring some work other than just IR handling.

http://www.spinics.net/lists/linux-media/msg15762.html

Or, of course, my IR handling could be just so f---ed up that it fails
to clear the IR interrupt.  ;) ftrace might let you see that too.
(I don't have a CX23885 chip, only CX23888's, so I can't experiment.)

>  If we wanted to get really fancy, I could add a modparam
> to let people turn msi back on. (Never had a single issue with this card
> recording with msi enabled, only IR seems busted).

Getting the driver to properly support both MSI and INTx emulation might
take a few changes.  (a bunch of if statements maybe?)  I don't think
letting users choose without the driver being inspected and/or corrected
to handle both is a good idea.


> Just had another thought though... I have an HVR-1800 that *does* have
> issues recording, and the way the video is corrupted, its possible that
> its msi-related... Will have to keep that in mind next time I poke at it.

Uh, huh.

Regards,
Andy

--
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

Re: HVR-1250/CX23885 IR Rx

[Jarod Wilson]

On Jun 28, 2011, at 6:32 PM, Andy Walls wrote:

> On Tue, 2011-06-28 at 17:39 -0400, Jarod Wilson wrote:
> 
>> Up and running on 3.0-rc5 now, and I'm not seeing the panic, but the
>> box keeps hard-locking after some number of keypresses. Can't get a
>> peep out of it with sysrq, nmi watchdog doesn't seem to fire, etc.
>> 
>> At the suggestion of "Dark Shadow", I've also tried booting the box
>> with pci=nomsi. Works a treat then. Since his HVR-1270 and my HVR-1250
>> both behave much better with pci=nomsi, I'm thinking that in the
>> short-term, we should probably make sure msi doesn't get enabled in
>> the cx23885 driver, and longer-term, we can look at fixing it.
> 
> Sounds fine.  But fixcing the cx23885 driver to deal with both PCIe
> emulation of legacy PCI INTx and PCIe MSI will likely be very involved.
> (Maybe I'm wrong?)

I'm not sure either, but I know a few PCI gurus at work who could
probably lend some insight.


> Taking a trip down memory lane to 2 Dec 2010...
> http://www.spinics.net/lists/linux-media/msg25956.html

Man. I really gotta learn to search the list archive (and bugzillas
assigned to me...) before sending mail to the list, eh? ;)


> On Wed, 2010-12-01 at 21:52 -0800, David Liontooth wrote:
>> On 11/29/2010 04:38 AM, Andy Walls wrote:
>>> On Sun, 2010-11-28 at 23:49 -0800, David Liontooth wrote:
> 
>>> For a quick band-aid, use "pci=nomsi" on your kernel command line, and
>>> reboot to reset the CX23888 hardware.
>>> 
>>> The problem is MSI.  The cx23885 driver isn't ready for it.  The patch
>>> that enabled MSI for cx23885 probably needs to be reverted until some of
>>> these issues are sorted out.
> 
>> -- what do we lose by removing the MSI support patch?
> 
> Problems mostly. The driver was written to work with emulated legacy PCI
> INTx interrupts, which are to be treated as level triggered, and not
> PCIe MSI, which are to be treated as edge triggered.  That's why I say
> the cx23885 driver isn't ready for MSI, but I'm not sure how involved an
> audit and conversion would be.  I know an audit will take time and
> expertise.

Dropping msi support looks to be quite trivial, I got the card behaving
after only a few lines of change in cx23885-core.c without having to pass
in pci=nomsi, but I *only* tried IR, I haven't tried video capture. I'll
see if I can give that a spin tomorrow, and if that behaves, I can send
along the diff. If we wanted to get really fancy, I could add a modparam
to let people turn msi back on. (Never had a single issue with this card
recording with msi enabled, only IR seems busted).

Just had another thought though... I have an HVR-1800 that *does* have
issues recording, and the way the video is corrupted, its possible that
its msi-related... Will have to keep that in mind next time I poke at it.

-- 
Jarod Wilson
ja...@wilsonet.com



--
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

[GIT PATCHES FOR 3.0] v4l core and uvcvideo fixes

[Laurent Pinchart]

Hi Mauro,

The following changes since commit b0af8dfdd67699e25083478c63eedef2e72ebd85:

  Linux 3.0-rc5 (2011-06-27 19:12:22 -0700)

are available in the git repository at:
  git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-stable

Laurent Pinchart (2):
  v4l: Don't access media entity after is has been destroyed
  uvcvideo: Ignore entities for terminals with no supported format

Sjoerd Simons (2):
  uvcvideo: Remove buffers from the queues when freeing
  uvcvideo: Disable the queue when failing to start

 drivers/media/video/uvc/uvc_entity.c |   34 ++---
 drivers/media/video/uvc/uvc_queue.c  |2 +
 drivers/media/video/uvc/uvc_video.c  |4 ++-
 drivers/media/video/v4l2-dev.c   |   39 ++---
 4 files changed, 33 insertions(+), 46 deletions(-

The first two patches fix serious regressions causing oopses and need to go in 
3.0. The last two patches fix non-regression bugs and can be delayed until 3.1 
if needed.

-- 
Regards,

Laurent Pinchart
--
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

Re: [RFCv3 PATCH 12/18] vb2_poll: don't start DMA, leave that to the first read().

[Mauro Carvalho Chehab]

Em 28-06-2011 20:14, Andy Walls escreveu:
> On Tue, 2011-06-28 at 09:43 -0300, Mauro Carvalho Chehab wrote:
>> Em 28-06-2011 09:21, Andy Walls escreveu:
> 
>>> It is also the case that a driver's poll method should never sleep.
>>
>> True.
> 
>>> One issue is how to start streaming with apps that:
>>> - Open /dev/video/ in a nonblocking mode, and
>>> - Use the read() method
>>>
>>> while doing it in a way that is POSIX compliant and doesn't break existing 
>>> apps.  
>>
>> Well, a first call for poll() may rise a thread that will prepare the 
>> buffers, and
>> return with 0 while there's no data available.
> 
> Sure, but that doesn't solve the problem of an app only select()-ing or
> poll()-ing for exception fd's and not starting any IO.

Well, a file descriptor can be used only for one thing: or it is a stream file
descriptor, or it is an event descriptor. You can't have both for the same
file descriptor. If an application need to check for both, the standard Unix 
way is:

fd_set set;

FD_ZERO (&set);
FD_SET (fd_stream, &set);
FD_SET (fd_event, &set);

select (FD_SETSIZE, &set, NULL, NULL, &timeout);

In other words, or the events nodes need to be different, or an ioctl is needed
in order to tell the Kernel that the associated file descriptor will be used
for an event, and that vb2 should not bother with it.

>>> The other constraint is to ensure when only poll()-ing for exception
>> conditions, not having significant IO side effects.
>>>
>>> I'm pretty sure sleeping in a driver's poll() method, or having
>> significant side effects, is not ine the spirit of the POSIX select()
>> and poll(), even if the letter of POSIX says nothing about it.
>>>
>>> The method I suggested to Hans is completely POSIX compliant for
>> apps using read() and select() and was checked against MythTV as
>> having no bad side effects.  (And by thought experiment doesn't break
>> any sensible app using nonblocking IO with select() and read().)
>>>
>>> I did not do analysis for apps that use mmap(), which I guess is the
>> current concern.
>>
>> The concern is that it is pointing that there are available data, even
>> when there is an error.
>> This looks like a POSIX violation for me.
> 
> It isn't.
> 
> From the specification for select():
> http://pubs.opengroup.org/onlinepubs/009695399/functions/select.html
> 
> "A descriptor shall be considered ready for reading when a call to an
> input function with O_NONBLOCK clear would not block, whether or not the
> function would transfer data successfully. (The function might return
> data, an end-of-file indication, or an error other than one indicating
> that it is blocked, and in each of these cases the descriptor shall be
> considered ready for reading.)"

My understanding from the above is that "ready" means:
- data;
- EOF;
- error.

if POLLIN (or POLLOUT) is returned, it should mean one of the above, e. g.
the device is ready to provide data or some error occurred.

Btw, we're talking about poll(), and not select(). The poll() doc is clearer
(http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html):

POLLIN
Data other than high-priority data may be read without blocking. 

POLLOUT
Normal data may be written without blocking. 

Saying that a -EAGAIN means that data is "ready" is an API abuse. This
can actually work, but it will effectively mean that poll or select won't
do anything, except for wasting a some CPU cycles.

> To a userspace app, a non-blocking read() can always return an error,
> regarless of the previous select() or poll() result.  And all
> applications that use select() or poll() folowed by a nonblocking read()
> should be prepared to handle an errno from the read().
> 
> However, that excerpt from the select() specification does imply, that
> perhaps, the driver should probably start streaming using a work item
> and one of the CMWQ workers, so that the read() doesn't block.

Cheers,
Mauro.
--
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

Re: [RFCv3 PATCH 12/18] vb2_poll: don't start DMA, leave that to the first read().

[Andy Walls]

On Tue, 2011-06-28 at 09:43 -0300, Mauro Carvalho Chehab wrote:
> Em 28-06-2011 09:21, Andy Walls escreveu:

> > It is also the case that a driver's poll method should never sleep.
> 
> True.

> > One issue is how to start streaming with apps that:
> > - Open /dev/video/ in a nonblocking mode, and
> > - Use the read() method
> > 
> > while doing it in a way that is POSIX compliant and doesn't break existing 
> > apps.  
> 
> Well, a first call for poll() may rise a thread that will prepare the 
> buffers, and
> return with 0 while there's no data available.

Sure, but that doesn't solve the problem of an app only select()-ing or
poll()-ing for exception fd's and not starting any IO.


> > The other constraint is to ensure when only poll()-ing for exception
> conditions, not having significant IO side effects.
> > 
> > I'm pretty sure sleeping in a driver's poll() method, or having
> significant side effects, is not ine the spirit of the POSIX select()
> and poll(), even if the letter of POSIX says nothing about it.
> > 
> > The method I suggested to Hans is completely POSIX compliant for
> apps using read() and select() and was checked against MythTV as
> having no bad side effects.  (And by thought experiment doesn't break
> any sensible app using nonblocking IO with select() and read().)
> > 
> > I did not do analysis for apps that use mmap(), which I guess is the
> current concern.
> 
> The concern is that it is pointing that there are available data, even
> when there is an error.
> This looks like a POSIX violation for me.

It isn't.

>From the specification for select():
http://pubs.opengroup.org/onlinepubs/009695399/functions/select.html

"A descriptor shall be considered ready for reading when a call to an
input function with O_NONBLOCK clear would not block, whether or not the
function would transfer data successfully. (The function might return
data, an end-of-file indication, or an error other than one indicating
that it is blocked, and in each of these cases the descriptor shall be
considered ready for reading.)"

To a userspace app, a non-blocking read() can always return an error,
regarless of the previous select() or poll() result.  And all
applications that use select() or poll() folowed by a nonblocking read()
should be prepared to handle an errno from the read().

However, that excerpt from the select() specification does imply, that
perhaps, the driver should probably start streaming using a work item
and one of the CMWQ workers, so that the read() doesn't block.

Regards,
Andy


--
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

Re: FW: OMAP 3 ISP

[Laurent Pinchart]

Hi Alex,

On Tuesday 28 June 2011 09:47:07 Alex Gershgorin wrote:
> Hi Laurent,
> 
> I recently got the Zoom OMAP35xx Torpedo and began testing OMAP3ISP.
> Currently I have a problem I can't solve.
> See Message from booting Kernel:
> 
> Linux media interface: v0.10
> Linux video capture interface: v2.00
> omap3isp omap3isp: Revision 2.0 found
> omap-iommu omap-iommu.0: isp: version 1.1
> isp_register_subdev_group: Unable to register subdev
> 
> What could be the problem, why sub device can't pass a registration?

This means the v4l2_i2c_new_subdev_board() failed. Do you have a driver for 
the subdev ? Does it get loaded ? Does its probe() function get called ?

-- 
Regards,

Laurent Pinchart
--
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

Re: HVR-1250/CX23885 IR Rx

[Andy Walls]

On Tue, 2011-06-28 at 17:39 -0400, Jarod Wilson wrote:

> Up and running on 3.0-rc5 now, and I'm not seeing the panic, but the
> box keeps hard-locking after some number of keypresses. Can't get a
> peep out of it with sysrq, nmi watchdog doesn't seem to fire, etc.
> 
> At the suggestion of "Dark Shadow", I've also tried booting the box
> with pci=nomsi. Works a treat then. Since his HVR-1270 and my HVR-1250
> both behave much better with pci=nomsi, I'm thinking that in the
> short-term, we should probably make sure msi doesn't get enabled in
> the cx23885 driver, and longer-term, we can look at fixing it.

Sounds fine.  But fixcing the cx23885 driver to deal with both PCIe
emulation of legacy PCI INTx and PCIe MSI will likely be very involved.
(Maybe I'm wrong?)

Taking a trip down memory lane to 2 Dec 2010...
http://www.spinics.net/lists/linux-media/msg25956.html

On Wed, 2010-12-01 at 21:52 -0800, David Liontooth wrote:
> On 11/29/2010 04:38 AM, Andy Walls wrote:
> > On Sun, 2010-11-28 at 23:49 -0800, David Liontooth wrote:

> > For a quick band-aid, use "pci=nomsi" on your kernel command line, and
> > reboot to reset the CX23888 hardware.
> >
> > The problem is MSI.  The cx23885 driver isn't ready for it.  The patch
> > that enabled MSI for cx23885 probably needs to be reverted until some of
> > these issues are sorted out.

> -- what do we lose by removing the MSI support patch?

Problems mostly. The driver was written to work with emulated legacy PCI
INTx interrupts, which are to be treated as level triggered, and not
PCIe MSI, which are to be treated as edge triggered.  That's why I say
the cx23885 driver isn't ready for MSI, but I'm not sure how involved an
audit and conversion would be.  I know an audit will take time and
expertise.


Regards,
Andy

--
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

Re: HVR-1250/CX23885 IR Rx

[Jarod Wilson]

On Jun 28, 2011, at 6:30 AM, Andy Walls wrote:

> Jarod Wilson  wrote:
> 
>> On Apr 10, 2011, at 7:08 PM, Andy Walls wrote:
>> 
>>> On Sat, 2011-04-09 at 21:39 -0400, Jarod Wilson wrote:
>>> 
> Jarod,
> 
> The HVR-1850 uses a raw IR receiver in the CX23888 and older
 HVR-1250s use the raw IR receiver in the CX23885.  They both work
>> for
 Rx (I need to tweak the Cx23885 rx watermark though), but I never
 found time to finish Tx (lack of kernel interface when I had time).
> 
> If you obtain one of these I can answer any driver questions.
 
 Quite some time back, I bought an HVR-1800 and an HVR-1250. I know
>> one of
 them came with an mceusb transceiver and remote, as was pretty sure
>> it was
 the 1800. For some reason, I didn't recall the 1250 coming with
>> anything at
 all, but looking at dmesg output for it:
 
 cx23885 driver version 0.0.2 loaded
 cx23885 :03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 CORE cx23885[0]: subsystem: 0070:7911, board: Hauppauge
>> WinTV-HVR1250 [card=3,autodetected]
 tveeprom 0-0050: Hauppauge model 79001, rev E3D9, serial# 4904656
 tveeprom 0-0050: MAC address is 00:0d:fe:4a:d6:d0
 tveeprom 0-0050: tuner model is Microtune MT2131 (idx 139, type 4)
 tveeprom 0-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88)
 tveeprom 0-0050: audio processor is CX23885 (idx 39)
 tveeprom 0-0050: decoder processor is CX23885 (idx 33)
 tveeprom 0-0050: has no radio, has IR receiver, has no IR
>> transmitter
 
 So it seems I do have hardware. However, its one of the two tuner
>> cards in
 my "production" mythtv backend right now, making it a bit hard to do
>> any
 experimenting with. If I can get it out of there, it looks like I
>> just add
 an enable_885_ir=1, and I should be able to poke at it...
>>> 
>>> Yeah.  Igor's TeVii S470 CX23885 based card had interrupt storms when
>>> enabled, so IR for '885 chips is disabled by default.  To
>> investigate, I
>>> tried to by an HVR-1250 with a CX23885, but instead got an HVR-1275
>> with
>>> a CX23888.  dandel, on IRC, did a pretty decent job in testing
>> HVR-1250
>>> operation and finding it works, despite climbing kernel
>>> build/development learning curve at the time.
>> ...
>> 
>> Finally got some time to play with my 1250, dug out its rx cable, turns
>> out to
>> be the same one I special-ordered to work on the 1150 Devin sent me.
>> Oops.
>> Anyway. First impressions, not so good. Got a panic on boot, somewhere
>> in
>> cx23885_video_irq, iirc, when booting with enable_885_ir=1 set.
>> However, dmesg
>> was somewhere in the middle of cx18 init of the HVR-1600 in the box.
>> Dunno if
>> there's any way that's actually directly related, but I yanked the
>> 1600. After
>> doing that, the box managed to boot fine, but then while testing
>> w/ir-keytable
>> and an RC-6 remote, I got what I think was the same panic -- definitely
>> the
>> cx23885_video_irq bit in the trace, something about sleeping while
>> atomic, IP
>> at mwait_idle. (On the plus side, IR did seem to be working before
>> that).
>> 
>> Note also that this is a 2.6.32-based kernel with a 2.6.38-era backport
>> of the
>> driver code, because that's what was on this box. Was about to put it
>> back into
>> "production" use, but hey, its summer, there's nothing really for it to
>> record
>> for another few months, so I'll keep it out and throw it into another
>> box with
>> a newer kernel and serial console, etc., so I can further debug...
> 
> In a very early version of the CX23885 IR changes I made the mistake of 
> performing I2C transactions in an interrupt handler.  That has been fixed in 
> cx23885 for quite some time though.  It also required some I2C fixes in 
> cx25840-core.c IIRC, which again, has been fixed for some time.

Up and running on 3.0-rc5 now, and I'm not seeing the panic, but the
box keeps hard-locking after some number of keypresses. Can't get a
peep out of it with sysrq, nmi watchdog doesn't seem to fire, etc.

At the suggestion of "Dark Shadow", I've also tried booting the box
with pci=nomsi. Works a treat then. Since his HVR-1270 and my HVR-1250
both behave much better with pci=nomsi, I'm thinking that in the
short-term, we should probably make sure msi doesn't get enabled in
the cx23885 driver, and longer-term, we can look at fixing it.

-- 
Jarod Wilson
ja...@wilsonet.com



--
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

Patch proposition for DVB-T configuration file for Paris area

[Bogdan Cristea]

Hi

I would like to propose the attached patch for de DVB-T configuration file for 
Paris area (found in openSUSE 11.4 in this location)
/usr/share/dvb/dvb-t/fr-Paris

With the current configuration file only 5 channels are found, while in 
reality there are almost 35 channels.

regards
-- 
Bogdan Cristea
Embedded Software Engineer
Philog
46 rue d'Amsterdam
75009 Paris, France
tel: +33 (0)6 21 64 15 81
web: http://sites.google.com/site/cristeab/
8,23c8,19
< #R1: France 3, France 2, France 5, LCP, France ô
< #R2: Direct 8, BFM TV, i>TELE, DirectStar, Gulli, France 4
< #R3: CANAL+, CANAL+ CINEMA, CANAL+ SPORT, PLANETE, TPS STAR
< #R4: ARTE HD, PARIS PREMIERE, M6, W9, NT1
< #R5: TF1 HD, France 2 HD, M6HD
< #R6: TF1, NRJ12, Eurosport, LCI, TMC, TF6, ARTE
< #Local: Canal 21, IDF1, NRJ Paris, BFM Business Paris
< 
< T 585834000 8MHz 3/4 NONE QAM64 8k 1/8 NONE
< T 505834000 8MHz 3/4 NONE QAM64 8k 1/8 NONE
< T 481834000 8MHz 3/4 NONE QAM64 8k 1/8 NONE
< T 545834000 8MHz 3/4 NONE QAM64 8k 1/8 NONE
< T 529834000 8MHz 3/4 NONE QAM64 8k 1/8 NONE
< T 561834000 8MHz 3/4 NONE QAM64 8k 1/8 NONE
< T 569834000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
< 
---
> T 474166000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
> T 498166000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
> T 522166000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
> T 538166000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
> T 562166000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
> T 586166000 8MHz 3/4 NONE QAM64 8k 1/8 NONE
> T 714166000 8MHz 3/4 NONE QAM64 8k 1/8 NONE
> T 738166000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
> T 754166000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
> T 762166000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
> T 786166000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
> T 810166000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

Genius TVGo C03 TV Card not recognised

[Thomas Spigel]

Hello, 
The em28xx module can't recognise my tvcard on my linux ubuntu 11.04.
Here is the dmesg log. Please tell me if there's any way to run this
card on my system. If not, i would like to help you to include it in
your modules.

CARD: Genius TVGo C03 hybrid tvcard
DMESG LOG:
[13291.629753] em28xx: New device @ 480 Mbps (eb1a:2883, interface 0,
class 0)
[13291.629853] em28xx #0: chip ID is em2882/em2883
[13291.712108] em28xx #0: i2c eeprom 00: 1a eb 67 95 58 04 16 40 d0 12
5c 00 6a 12 00 00
[13291.712119] em28xx #0: i2c eeprom 10: 00 00 04 57 4e 07 01 00 00 00
00 00 00 00 00 00
[13291.712129] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 01 00 00 00
00 00 5b 1e 00 00
[13291.712139] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01
00 00 00 00 00 00
[13291.712148] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[13291.712158] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[13291.712167] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00
12 03 54 00 56 00
[13291.712177] em28xx #0: i2c eeprom 70: 47 00 6f 00 20 00 43 00 30 00
33 00 20 00 44 00
[13291.712186] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00
00 00 00 00 00 00
[13291.712196] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[13291.712205] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[13291.712214] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[13291.712224] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[13291.712233] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[13291.712242] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[13291.712252] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[13291.712262] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash =
0xbf6800e1
[13291.712264] em28xx #0: EEPROM info:
[13291.712266] em28xx #0:   AC97 audio (5 sample rates)
[13291.712267] em28xx #0:   500mA max power
[13291.712269] em28xx #0:   Table at 0x04, strings=0x126a, 0x, 0x
[13291.744483] em28xx #0: found i2c device @ 0xa0 [eeprom]
[13291.749105] em28xx #0: found i2c device @ 0xb8 [tvp5150a]
[13291.750977] em28xx #0: found i2c device @ 0xc2 [tuner (analog)]
[13291.762357] em28xx #0: Your board has no unique USB ID and thus need
a hint to be detected. 
[13291.762362] em28xx #0: You may try to use card= insmod option to
workaround that.
[13291.762364] em28xx #0: Please send an email with this log to:
[13291.762366] em28xx #0:   V4L Mailing List

[13291.762368] em28xx #0: Board eeprom hash is 0xbf6800e1
[13291.762370] em28xx #0: Board i2c devicelist hash is 0x27e10080


--
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

[cron job] v4l-dvb daily build: ERRORS

[Hans Verkuil]

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:Tue Jun 28 19:00:37 CEST 2011
git hash:7023c7dbc3944f42aa1d6910a6098c5f9e23d3f1
gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
spec-git: ERRORS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
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

Re: [PATCHv2 10/13] [media] gspca: don't include linux/version.h

[Jean-Francois Moine]

On Mon, 27 Jun 2011 23:17:34 -0300
Mauro Carvalho Chehab  wrote:

> Instead of handling a per-driver driver version, use the
> per-subsystem one.
> 
> As reviewed by Jean-Francois Moine :
>   - the 'info' may be simplified:
> 
> Reviewed-by: Jean-Francois Moine 
> Acked-by: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Jean-Francois Moine 

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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

Re: [PATCH] [media] v4l2 core: return -ENOIOCTLCMD if an ioctl doesn't exist

[Arnd Bergmann]

On Tuesday 28 June 2011, Alan Cox wrote:
> > (In fact, the correct thing to do would probably be to just do
> > 
> >#define ENOIOCTLCMD ENOTTY
> > 
> > and get rid of any translation - just giving ENOTTY a more appropriate
> > name and less chance for confusion)
> 
> Some code uses the two to separate 'the driver specific helper code
> doesn't handle this' and 'does handle this'. In that situation you take
> away the ability of a driver to override a midlayer ioctl with -ENOTTY to
> say "I don't support this even if most people do"

Right. Similarly, in compat_sys_ioctl returning -ENOIOCTLCMD from
fops->compat_ioctl means "the driver has provided no compatibility
handler for this command, need to check the global translation table",
while -ENOTTY returned from ->compat_ioctl means "this command won't
work on this device, don't bother looking at the table and don't
print an annoying message".

Arnd
--
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

Re: FM RDS receiver

[Markus Rechberger]

On Tue, Jun 28, 2011 at 12:02 AM, Helmut Auer  wrote:
> Hello List,
>
> Can you recommend any FM receiver card or usb stick currently available in
> Germany with RDS support ?

We do have some FM Receiver/Transmitters which support RDS, however they
are still only available upon request at this time.
Audio is represented by ALSA (snd-usb-audio), radio can be controlled
via v4l1/v4l2 from userspace.

Alternatively Sundtek MediaTV Pro also supports RDS and is available
on the market
right now (decoders can be requested), audio is represented as OSS,
although Alsa shouldn't be too difficult using
the new userspace Alsa interface.

Markus
--
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

Re: [PATCH] [media] v4l2 core: return -ENOIOCTLCMD if an ioctl doesn't exist

[Alan Cox]

> (In fact, the _correct_ thing to do would probably be to just do
> 
>#define ENOIOCTLCMD ENOTTY
> 
> and get rid of any translation - just giving ENOTTY a more appropriate
> name and less chance for confusion)

Some code uses the two to separate 'the driver specific helper code
doesn't handle this' and 'does handle this'. In that situation you take
away the ability of a driver to override a midlayer ioctl with -ENOTTY to
say "I don't support this even if most people do"

> There may be applications out there that really break when they get
> ENOTTY instead of EINVAL. But most cases that check for errors from
> ioctl's tend to just say "did this succeed or not" rather than "did
> this return EINVAL". That's *doubly* true since the error code has
> been ambiguous, so checking for the exact error code has always been
> pretty pointless.

Chances are if anything is busted its busted the other way on Linux and
expects -ENOTTY. Certainly the large number I've been fixing over time
haven't shown up any problems.
--
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

[PATCHv2 00/13] Remove linux/version.h from most drivers/media/

[Mauro Carvalho Chehab]

At the V4L2 API, one of the fields of VIDIOC_QUERYCAP requires the usage
of KERNEL_VERSION macro, in order to provide the driver version. However,
this is not handled consistently across subsystems. There are very few
drivers that take it seriously.

So, instead of the current way, let's replace it by a subsystem version.
After this patch series, only 4 drivers will keep including linux/version.h
on their c files, as they don't use the V4L2 core ioctl handler
(uvc, pvrusb2, sn9c102 and et61x251).

After this patch series, if VIDIOC_QUERYCAP returns version 3.x.y,
with x > 0, then userspace applications can be sure that the V4L2 core
is using V4L2 API version 3.x.y.

-

The version 2 of this patch series removes the patches that were
replacing -EINVAL error code when an ioctl is not implemented, as
more changes will likely be needed at the DocBook and on drivers,
in order to fix the inconsistencies. I'll be working on that and
submit those changes later.

Per Jean-Francois request, I broke the gspca patch into a separate
one, and simplified the info() call.

Also added Hans ack into the patch series.

Mauro Carvalho Chehab (13):
  [media] v4l2-ioctl: Add a default value for kernel version
  [media] drxd, siano: Remove unused include linux/version.h
  [media] Stop using linux/version.h on most video drivers
  [media] pwc: Use the default version for VIDIOC_QUERYCAP
  [media] ivtv,cx18: Use default version control for VIDIOC_QUERYCAP
  [media] et61x251: Use LINUX_VERSION_CODE for VIDIOC_QUERYCAP
  [media] pvrusb2: Use LINUX_VERSION_CODE for VIDIOC_QUERYCAP
  [media] sn9c102: Use LINUX_VERSION_CODE for VIDIOC_QUERYCAP
  [media] uvcvideo: Use LINUX_VERSION_CODE for VIDIOC_QUERYCAP
  [media] gspca: don't include linux/version.h
  [media] Stop using linux/version.h the remaining video drivers
  [media] radio: Use the subsystem version control for VIDIOC_QUERYCAP
  [media] DocBook/v4l: Document the new system-wide version behavior

 Documentation/DocBook/media/v4l/common.xml |   10 -
 Documentation/DocBook/media/v4l/v4l2.xml   |6 +
 .../DocBook/media/v4l/vidioc-querycap.xml  |   15 -
 drivers/media/dvb/frontends/drxd_hard.c|1 -
 drivers/media/dvb/siano/smscoreapi.h   |1 -
 drivers/media/radio/dsbr100.c  |7 +
 drivers/media/radio/radio-aimslab.c|5 +---
 drivers/media/radio/radio-aztech.c |5 +---
 drivers/media/radio/radio-cadet.c  |5 +---
 drivers/media/radio/radio-gemtek.c |7 +
 drivers/media/radio/radio-maxiradio.c  |   10 +++-
 drivers/media/radio/radio-mr800.c  |6 +---
 drivers/media/radio/radio-rtrack2.c|5 +---
 drivers/media/radio/radio-sf16fmi.c|5 +---
 drivers/media/radio/radio-tea5764.c|6 +---
 drivers/media/radio/radio-terratec.c   |5 +---
 drivers/media/radio/radio-timb.c   |3 +-
 drivers/media/radio/radio-trust.c  |5 +---
 drivers/media/radio/radio-typhoon.c|9 +++
 drivers/media/radio/radio-zoltrix.c|5 +---
 drivers/media/radio/si470x/radio-si470x-i2c.c  |4 +--
 drivers/media/radio/si470x/radio-si470x-usb.c  |2 -
 drivers/media/radio/si470x/radio-si470x.h  |1 -
 drivers/media/radio/wl128x/fmdrv.h |5 +---
 drivers/media/radio/wl128x/fmdrv_v4l2.c|1 -
 drivers/media/video/arv.c  |5 +--
 drivers/media/video/au0828/au0828-core.c   |1 +
 drivers/media/video/au0828/au0828-video.c  |5 
 drivers/media/video/bt8xx/bttv-driver.c|   14 +++-
 drivers/media/video/bt8xx/bttvp.h  |3 --
 drivers/media/video/bw-qcam.c  |3 +-
 drivers/media/video/c-qcam.c   |3 +-
 drivers/media/video/cpia2/cpia2.h  |5 
 drivers/media/video/cpia2/cpia2_v4l.c  |   12 +++---
 drivers/media/video/cx18/cx18-driver.h |1 -
 drivers/media/video/cx18/cx18-ioctl.c  |1 -
 drivers/media/video/cx18/cx18-version.h|8 +--
 drivers/media/video/cx231xx/cx231xx-video.c|   14 +++-
 drivers/media/video/cx231xx/cx231xx.h  |1 -
 drivers/media/video/cx23885/altera-ci.c|1 -
 drivers/media/video/cx23885/cx23885-417.c  |1 -
 drivers/media/video/cx23885/cx23885-core.c |   13 ++-
 drivers/media/video/cx23885/cx23885-video.c|1 -
 drivers/media/video/cx23885/cx23885.h  |3 +-
 drivers/media/video/cx88/cx88-alsa.c   |   19 +++--
 drivers/media/video/cx88/cx88-blackbird.c  |   20 ++
 drivers/media/video/cx88/cx88-dvb.c|   18 ++-

[PATCHv2 10/13] [media] gspca: don't include linux/version.h

[Mauro Carvalho Chehab]

Instead of handling a per-driver driver version, use the
per-subsystem one.

As reviewed by Jean-Francois Moine :
- the 'info' may be simplified:

Reviewed-by: Jean-Francois Moine 
Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/video/gspca/gspca.c 
b/drivers/media/video/gspca/gspca.c
index 08ce994..d0b79a9 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -24,7 +24,6 @@
 #define MODULE_NAME "gspca"
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -51,11 +50,12 @@
 #error "DEF_NURBS too big"
 #endif
 
+#define DRIVER_VERSION_NUMBER  "2.13.0"
+
 MODULE_AUTHOR("Jean-François Moine ");
 MODULE_DESCRIPTION("GSPCA USB Camera Driver");
 MODULE_LICENSE("GPL");
-
-#define DRIVER_VERSION_NUMBER  KERNEL_VERSION(2, 13, 0)
+MODULE_VERSION(DRIVER_VERSION_NUMBER);
 
 #ifdef GSPCA_DEBUG
 int gspca_debug = D_ERR | D_PROBE;
@@ -1291,7 +1291,6 @@ static int vidioc_querycap(struct file *file, void  *priv,
}
usb_make_path(gspca_dev->dev, (char *) cap->bus_info,
sizeof(cap->bus_info));
-   cap->version = DRIVER_VERSION_NUMBER;
cap->capabilities = V4L2_CAP_VIDEO_CAPTURE
  | V4L2_CAP_STREAMING
  | V4L2_CAP_READWRITE;
@@ -2478,10 +2477,7 @@ EXPORT_SYMBOL(gspca_auto_gain_n_exposure);
 /* -- module insert / remove -- */
 static int __init gspca_init(void)
 {
-   info("v%d.%d.%d registered",
-   (DRIVER_VERSION_NUMBER >> 16) & 0xff,
-   (DRIVER_VERSION_NUMBER >> 8) & 0xff,
-   DRIVER_VERSION_NUMBER & 0xff);
+   info("v" DRIVER_VERSION_NUMBER " registered");
return 0;
 }
 static void __exit gspca_exit(void)
-- 
1.7.1


--
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

[PATCHv2 13/13] [media] DocBook/v4l: Document the new system-wide version behavior

[Mauro Carvalho Chehab]

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/v4l/common.xml 
b/Documentation/DocBook/media/v4l/common.xml
index 9028721..a86f7a0 100644
--- a/Documentation/DocBook/media/v4l/common.xml
+++ b/Documentation/DocBook/media/v4l/common.xml
@@ -236,7 +236,15 @@ important parts of the API.
 The &VIDIOC-QUERYCAP; ioctl is available to check if the kernel
 device is compatible with this specification, and to query the functions and I/O
-methods supported by the device. Other features can be queried
+methods supported by the device.
+
+Starting with kernel version 3.1, VIDIOC-QUERYCAP will return the
+V4L2 API version used by the driver, with generally matches the Kernel version.
+There's no need of using &VIDIOC-QUERYCAP; to check if an specific ioctl is
+supported, the V4L2 core now returns ENOIOCTLCMD if a driver doesn't provide
+support for an ioctl.
+
+Other features can be queried
 by calling the respective ioctl, for example &VIDIOC-ENUMINPUT;
 to learn about the number, types and names of video connectors on the
 device. Although abstraction is a major objective of this API, the
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
b/Documentation/DocBook/media/v4l/v4l2.xml
index a7fd76d..c5ee398 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -128,6 +128,12 @@ structs, ioctls) must be noted in more detail in the 
history chapter
 applications. -->
 
   
+   3.1
+   2011-06-27
+   mcc, po
+   Documented that VIDIOC_QUERYCAP now returns a per-subsystem 
version instead of a per-driver one.
+  
+  
2.6.39
2011-03-01
mcc, po
diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml 
b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
index f29f1b8..7aa6973 100644
--- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
@@ -67,9 +67,8 @@ driver is not compatible with this specification the ioctl 
returns an
Name of the driver, a unique NUL-terminated
 ASCII string. For example: "bttv". Driver specific applications can
 use this information to verify the driver identity. It is also useful
-to work around known bugs, or to identify drivers in error reports.
-The driver version is stored in the version
-field.Storing strings in fixed sized arrays is bad
+to work around known bugs, or to identify drivers in error reports.
+Storing strings in fixed sized arrays is bad
 practice but unavoidable here. Drivers and applications should take
 precautions to never read or write beyond the end of the array and to
 make sure the strings are properly NUL-terminated.
@@ -100,9 +99,13 @@ empty string (bus_info[0] = 
0).

[PATCHv2 09/13] [media] uvcvideo: Use LINUX_VERSION_CODE for VIDIOC_QUERYCAP

[Mauro Carvalho Chehab]

uvcvideo doesn't use vidioc_ioctl2. As the API is changing to use
a common version for all drivers, we need to expliticly fix this
driver.

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/video/uvc/uvc_driver.c 
b/drivers/media/video/uvc/uvc_driver.c
index b6eae48..749c722 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1857,7 +1858,7 @@ static int uvc_probe(struct usb_interface *intf,
sizeof(dev->mdev.serial));
strcpy(dev->mdev.bus_info, udev->devpath);
dev->mdev.hw_revision = le16_to_cpu(udev->descriptor.bcdDevice);
-   dev->mdev.driver_version = DRIVER_VERSION_NUMBER;
+   dev->mdev.driver_version = LINUX_VERSION_CODE;
if (media_device_register(&dev->mdev) < 0)
goto error;
 
diff --git a/drivers/media/video/uvc/uvc_v4l2.c 
b/drivers/media/video/uvc/uvc_v4l2.c
index 543a803..cdd967b 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -571,7 +571,7 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned 
int cmd, void *arg)
strlcpy(cap->card, vdev->name, sizeof cap->card);
usb_make_path(stream->dev->udev,
  cap->bus_info, sizeof(cap->bus_info));
-   cap->version = DRIVER_VERSION_NUMBER;
+   cap->version = LINUX_VERSION_CODE;
if (stream->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
cap->capabilities = V4L2_CAP_VIDEO_CAPTURE
  | V4L2_CAP_STREAMING;
diff --git a/drivers/media/video/uvc/uvcvideo.h 
b/drivers/media/video/uvc/uvcvideo.h
index 20107fd..df32a43 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -183,8 +183,7 @@ struct uvc_xu_control {
  * Driver specific constants.
  */
 
-#define DRIVER_VERSION_NUMBER  KERNEL_VERSION(1, 1, 0)
-#define DRIVER_VERSION "v1.1.0"
+#define DRIVER_VERSION "1.1.1"
 
 /* Number of isochronous URBs. */
 #define UVC_URBS   5
-- 
1.7.1


--
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

[PATCHv2 07/13] [media] pvrusb2: Use LINUX_VERSION_CODE for VIDIOC_QUERYCAP

[Mauro Carvalho Chehab]

pvrusb2 doesn't use vidioc_ioctl2. As the API is changing to use
a common version for all drivers, we need to expliticly fix this
driver.

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/video/pvrusb2/pvrusb2-main.c 
b/drivers/media/video/pvrusb2/pvrusb2-main.c
index 2254194..c1d9bb6 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-main.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-main.c
@@ -168,6 +168,7 @@ module_exit(pvr_exit);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
+MODULE_VERSION("0.9.1");
 
 
 /*
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c 
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index 3876114..573749a 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -91,7 +91,7 @@ static struct v4l2_capability pvr_capability ={
.driver = "pvrusb2",
.card   = "Hauppauge WinTV pvr-usb2",
.bus_info   = "usb",
-   .version= KERNEL_VERSION(0, 9, 0),
+   .version= LINUX_VERSION_CODE,
.capabilities   = (V4L2_CAP_VIDEO_CAPTURE |
   V4L2_CAP_TUNER | V4L2_CAP_AUDIO | V4L2_CAP_RADIO |
   V4L2_CAP_READWRITE),
-- 
1.7.1


--
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

[PATCHv2 08/13] [media] sn9c102: Use LINUX_VERSION_CODE for VIDIOC_QUERYCAP

[Mauro Carvalho Chehab]

sn9c102 doesn't use vidioc_ioctl2. As the API is changing to use
a common version for all drivers, we need to expliticly fix this
driver.

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/video/sn9c102/sn9c102.h 
b/drivers/media/video/sn9c102/sn9c102.h
index cbfc444..22ea211 100644
--- a/drivers/media/video/sn9c102/sn9c102.h
+++ b/drivers/media/video/sn9c102/sn9c102.h
@@ -21,7 +21,6 @@
 #ifndef _SN9C102_H_
 #define _SN9C102_H_
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/media/video/sn9c102/sn9c102_core.c 
b/drivers/media/video/sn9c102/sn9c102_core.c
index 0e07c49..d8eece8 100644
--- a/drivers/media/video/sn9c102/sn9c102_core.c
+++ b/drivers/media/video/sn9c102/sn9c102_core.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -47,8 +48,7 @@
 #define SN9C102_MODULE_AUTHOR   "(C) 2004-2007 Luca Risolia"
 #define SN9C102_AUTHOR_EMAIL""
 #define SN9C102_MODULE_LICENSE  "GPL"
-#define SN9C102_MODULE_VERSION  "1:1.47pre49"
-#define SN9C102_MODULE_VERSION_CODE  KERNEL_VERSION(1, 1, 47)
+#define SN9C102_MODULE_VERSION  "1:1.48"
 
 /*/
 
@@ -2158,7 +2158,7 @@ sn9c102_vidioc_querycap(struct sn9c102_device* cam, void 
__user * arg)
 {
struct v4l2_capability cap = {
.driver = "sn9c102",
-   .version = SN9C102_MODULE_VERSION_CODE,
+   .version = LINUX_VERSION_CODE,
.capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_READWRITE |
V4L2_CAP_STREAMING,
};
-- 
1.7.1


--
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

[PATCHv2 11/13] [media] Stop using linux/version.h the remaining video drivers

[Mauro Carvalho Chehab]

Standardize the remaining video drivers to return the API version
for the VIDIOC_QUERYCAP version, instead of a per-driver version.

Those drivers had the version updated more recently or are SoC
drivers. Even so, it doesn't sound a good idea to keep a per-driver
version control, so, let's use the per-subsystem version control
instead.

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/video/davinci/vpif_capture.c 
b/drivers/media/video/davinci/vpif_capture.c
index d93ad74..49e4deb 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -44,6 +43,7 @@
 
 MODULE_DESCRIPTION("TI DaVinci VPIF Capture driver");
 MODULE_LICENSE("GPL");
+MODULE_VERSION(VPIF_CAPTURE_VERSION);
 
 #define vpif_err(fmt, arg...)  v4l2_err(&vpif_obj.v4l2_dev, fmt, ## arg)
 #define vpif_dbg(level, debug, fmt, arg...)\
@@ -1677,7 +1677,6 @@ static int vpif_querycap(struct file *file, void  *priv,
 {
struct vpif_capture_config *config = vpif_dev->platform_data;
 
-   cap->version = VPIF_CAPTURE_VERSION_CODE;
cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
strlcpy(cap->driver, "vpif capture", sizeof(cap->driver));
strlcpy(cap->bus_info, "DM646x Platform", sizeof(cap->bus_info));
@@ -2211,10 +2210,8 @@ static __init int vpif_probe(struct platform_device 
*pdev)
vfd->v4l2_dev = &vpif_obj.v4l2_dev;
vfd->release = video_device_release;
snprintf(vfd->name, sizeof(vfd->name),
-"DM646x_VPIFCapture_DRIVER_V%d.%d.%d",
-(VPIF_CAPTURE_VERSION_CODE >> 16) & 0xff,
-(VPIF_CAPTURE_VERSION_CODE >> 8) & 0xff,
-(VPIF_CAPTURE_VERSION_CODE) & 0xff);
+"DM646x_VPIFCapture_DRIVER_V%s",
+VPIF_CAPTURE_VERSION);
/* Set video_dev to the video device */
ch->video_dev = vfd;
}
diff --git a/drivers/media/video/davinci/vpif_capture.h 
b/drivers/media/video/davinci/vpif_capture.h
index 7a4196d..064550f 100644
--- a/drivers/media/video/davinci/vpif_capture.h
+++ b/drivers/media/video/davinci/vpif_capture.h
@@ -23,7 +23,6 @@
 
 /* Header files */
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -33,11 +32,7 @@
 #include "vpif.h"
 
 /* Macros */
-#define VPIF_MAJOR_RELEASE 0
-#define VPIF_MINOR_RELEASE 0
-#define VPIF_BUILD 1
-#define VPIF_CAPTURE_VERSION_CODE  ((VPIF_MAJOR_RELEASE << 16) | \
-   (VPIF_MINOR_RELEASE << 8) | VPIF_BUILD)
+#define VPIF_CAPTURE_VERSION   "0.0.2"
 
 #define VPIF_VALID_FIELD(field)(((V4L2_FIELD_ANY == field) || \
(V4L2_FIELD_NONE == field)) || \
diff --git a/drivers/media/video/davinci/vpif_display.c 
b/drivers/media/video/davinci/vpif_display.c
index cdf659a..286f029 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -47,6 +46,7 @@
 
 MODULE_DESCRIPTION("TI DaVinci VPIF Display driver");
 MODULE_LICENSE("GPL");
+MODULE_VERSION(VPIF_DISPLAY_VERSION);
 
 #define DM646X_V4L2_STD (V4L2_STD_525_60 | V4L2_STD_625_50)
 
@@ -701,7 +701,6 @@ static int vpif_querycap(struct file *file, void  *priv,
 {
struct vpif_display_config *config = vpif_dev->platform_data;
 
-   cap->version = VPIF_DISPLAY_VERSION_CODE;
cap->capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
strlcpy(cap->driver, "vpif display", sizeof(cap->driver));
strlcpy(cap->bus_info, "Platform", sizeof(cap->bus_info));
@@ -1740,10 +1739,8 @@ static __init int vpif_probe(struct platform_device 
*pdev)
vfd->v4l2_dev = &vpif_obj.v4l2_dev;
vfd->release = video_device_release;
snprintf(vfd->name, sizeof(vfd->name),
-"DM646x_VPIFDisplay_DRIVER_V%d.%d.%d",
-(VPIF_DISPLAY_VERSION_CODE >> 16) & 0xff,
-(VPIF_DISPLAY_VERSION_CODE >> 8) & 0xff,
-(VPIF_DISPLAY_VERSION_CODE) & 0xff);
+"DM646x_VPIFDisplay_DRIVER_V%s",
+VPIF_DISPLAY_VERSION);
 
/* Set video_dev to the video device */
ch->video_dev = vfd;
diff --git a/drivers/media/video/davinci/vpif_display.h 
b/drivers/media/video/davinci/vpif_display.h
index b53aaa8..5d1936d 100644
--- a/drivers/media/video/davinci/vpif_display.h
+++ b/drivers/media/video/davinci/vpif_display.h
@@ -18,7 +18,6 @@
 
 /* Header files */
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -27,12 +26,7 @@
 #include "vpif.h"
 
 /* Macros */
-#define VPIF_MAJOR_RELEASE (0)
-#define VPIF_MINOR_RELEASE (0)
-

[PATCHv2 06/13] [media] et61x251: Use LINUX_VERSION_CODE for VIDIOC_QUERYCAP

[Mauro Carvalho Chehab]

et61x251 doesn't use vidioc_ioctl2. As the API is changing to use
a common version for all drivers, we need to expliticly fix this
driver.

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/video/et61x251/et61x251.h 
b/drivers/media/video/et61x251/et61x251.h
index bf66189..14bb907 100644
--- a/drivers/media/video/et61x251/et61x251.h
+++ b/drivers/media/video/et61x251/et61x251.h
@@ -21,7 +21,6 @@
 #ifndef _ET61X251_H_
 #define _ET61X251_H_
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/media/video/et61x251/et61x251_core.c 
b/drivers/media/video/et61x251/et61x251_core.c
index a982750..d7efb33 100644
--- a/drivers/media/video/et61x251/et61x251_core.c
+++ b/drivers/media/video/et61x251/et61x251_core.c
@@ -18,6 +18,7 @@
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.   *
  ***/
 
+#include 
 #include 
 #include 
 #include 
@@ -48,8 +49,7 @@
 #define ET61X251_MODULE_AUTHOR  "(C) 2006-2007 Luca Risolia"
 #define ET61X251_AUTHOR_EMAIL   ""
 #define ET61X251_MODULE_LICENSE "GPL"
-#define ET61X251_MODULE_VERSION "1:1.09"
-#define ET61X251_MODULE_VERSION_CODE  KERNEL_VERSION(1, 1, 9)
+#define ET61X251_MODULE_VERSION "1.1.10"
 
 /*/
 
@@ -1579,7 +1579,7 @@ et61x251_vidioc_querycap(struct et61x251_device* cam, 
void __user * arg)
 {
struct v4l2_capability cap = {
.driver = "et61x251",
-   .version = ET61X251_MODULE_VERSION_CODE,
+   .version = LINUX_VERSION_CODE,
.capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_READWRITE |
V4L2_CAP_STREAMING,
};
-- 
1.7.1


--
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

[PATCHv2 05/13] [media] ivtv,cx18: Use default version control for VIDIOC_QUERYCAP

[Mauro Carvalho Chehab]

After discussing with Andy Walls on irc, we've agreeded that this
is the best thing to do. No regressions will be introduced, as 3.x.y
is greater then the current versions for cx18 and ivtv.

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/video/cx18/cx18-driver.h 
b/drivers/media/video/cx18/cx18-driver.h
index 0864272..1834207 100644
--- a/drivers/media/video/cx18/cx18-driver.h
+++ b/drivers/media/video/cx18/cx18-driver.h
@@ -25,7 +25,6 @@
 #ifndef CX18_DRIVER_H
 #define CX18_DRIVER_H
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/media/video/cx18/cx18-ioctl.c 
b/drivers/media/video/cx18/cx18-ioctl.c
index 1933d4d..6ec61c9 100644
--- a/drivers/media/video/cx18/cx18-ioctl.c
+++ b/drivers/media/video/cx18/cx18-ioctl.c
@@ -469,7 +469,6 @@ static int cx18_querycap(struct file *file, void *fh,
strlcpy(vcap->card, cx->card_name, sizeof(vcap->card));
snprintf(vcap->bus_info, sizeof(vcap->bus_info),
 "PCI:%s", pci_name(cx->pci_dev));
-   vcap->version = CX18_DRIVER_VERSION;/* version */
vcap->capabilities = cx->v4l2_cap;  /* capabilities */
return 0;
 }
diff --git a/drivers/media/video/cx18/cx18-version.h 
b/drivers/media/video/cx18/cx18-version.h
index cd189b6..fed48b6 100644
--- a/drivers/media/video/cx18/cx18-version.h
+++ b/drivers/media/video/cx18/cx18-version.h
@@ -23,12 +23,6 @@
 #define CX18_VERSION_H
 
 #define CX18_DRIVER_NAME "cx18"
-#define CX18_DRIVER_VERSION_MAJOR 1
-#define CX18_DRIVER_VERSION_MINOR 5
-#define CX18_DRIVER_VERSION_PATCHLEVEL 0
-
-#define CX18_VERSION __stringify(CX18_DRIVER_VERSION_MAJOR) "." 
__stringify(CX18_DRIVER_VERSION_MINOR) "." 
__stringify(CX18_DRIVER_VERSION_PATCHLEVEL)
-#define CX18_DRIVER_VERSION KERNEL_VERSION(CX18_DRIVER_VERSION_MAJOR, \
-   CX18_DRIVER_VERSION_MINOR, CX18_DRIVER_VERSION_PATCHLEVEL)
+#define CX18_VERSION "1.5.1"
 
 #endif
diff --git a/drivers/media/video/ivtv/ivtv-driver.h 
b/drivers/media/video/ivtv/ivtv-driver.h
index 84bdf0f..8f9cc17 100644
--- a/drivers/media/video/ivtv/ivtv-driver.h
+++ b/drivers/media/video/ivtv/ivtv-driver.h
@@ -36,7 +36,6 @@
  *using information provided by Jiun-Kuei Jung @ AVerMedia.
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c 
b/drivers/media/video/ivtv/ivtv-ioctl.c
index f9e347d..ac210ac 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -757,7 +757,6 @@ static int ivtv_querycap(struct file *file, void *fh, 
struct v4l2_capability *vc
strlcpy(vcap->driver, IVTV_DRIVER_NAME, sizeof(vcap->driver));
strlcpy(vcap->card, itv->card_name, sizeof(vcap->card));
snprintf(vcap->bus_info, sizeof(vcap->bus_info), "PCI:%s", 
pci_name(itv->pdev));
-   vcap->version = IVTV_DRIVER_VERSION;/* version */
vcap->capabilities = itv->v4l2_cap; /* capabilities */
return 0;
 }
diff --git a/drivers/media/video/ivtv/ivtv-version.h 
b/drivers/media/video/ivtv/ivtv-version.h
index b67a404..a20f346 100644
--- a/drivers/media/video/ivtv/ivtv-version.h
+++ b/drivers/media/video/ivtv/ivtv-version.h
@@ -21,11 +21,6 @@
 #define IVTV_VERSION_H
 
 #define IVTV_DRIVER_NAME "ivtv"
-#define IVTV_DRIVER_VERSION_MAJOR 1
-#define IVTV_DRIVER_VERSION_MINOR 4
-#define IVTV_DRIVER_VERSION_PATCHLEVEL 2
-
-#define IVTV_VERSION __stringify(IVTV_DRIVER_VERSION_MAJOR) "." 
__stringify(IVTV_DRIVER_VERSION_MINOR) "." 
__stringify(IVTV_DRIVER_VERSION_PATCHLEVEL)
-#define IVTV_DRIVER_VERSION 
KERNEL_VERSION(IVTV_DRIVER_VERSION_MAJOR,IVTV_DRIVER_VERSION_MINOR,IVTV_DRIVER_VERSION_PATCHLEVEL)
+#define IVTV_VERSION "1.4.3"
 
 #endif
-- 
1.7.1


--
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

[PATCHv2 02/13] [media] drxd, siano: Remove unused include linux/version.h

[Mauro Carvalho Chehab]

Both drxd and siano drivers were including linux/version.h without
any reason. Probably, this is due to some compatibility code that
used to exist before having their support added into the Linux
Kernel.

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/dvb/frontends/drxd_hard.c 
b/drivers/media/dvb/frontends/drxd_hard.c
index ea4c1c3..f132e49 100644
--- a/drivers/media/dvb/frontends/drxd_hard.c
+++ b/drivers/media/dvb/frontends/drxd_hard.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "dvb_frontend.h"
diff --git a/drivers/media/dvb/siano/smscoreapi.h 
b/drivers/media/dvb/siano/smscoreapi.h
index 8ecadec..c592ae0 100644
--- a/drivers/media/dvb/siano/smscoreapi.h
+++ b/drivers/media/dvb/siano/smscoreapi.h
@@ -22,7 +22,6 @@ along with this program.  If not, see 
.
 #ifndef __SMS_CORE_API_H__
 #define __SMS_CORE_API_H__
 
-#include 
 #include 
 #include 
 #include 
-- 
1.7.1


--
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

[PATCHv2 12/13] [media] radio: Use the subsystem version control for VIDIOC_QUERYCAP

[Mauro Carvalho Chehab]

Just like the video drivers, the right thing to do is to use
the per-subsystem version control.

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index 3d8cc42..25e58cb 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -102,10 +102,7 @@
 /*
  * Version Information
  */
-#include  /* for KERNEL_VERSION MACRO */
-
-#define DRIVER_VERSION "v0.46"
-#define RADIO_VERSION KERNEL_VERSION(0, 4, 6)
+#define DRIVER_VERSION "0.4.7"
 
 #define DRIVER_AUTHOR "Markus Demleitner "
 #define DRIVER_DESC "D-Link DSB-R100 USB FM radio driver"
@@ -335,7 +332,6 @@ static int vidioc_querycap(struct file *file, void *priv,
strlcpy(v->driver, "dsbr100", sizeof(v->driver));
strlcpy(v->card, "D-Link R-100 USB FM Radio", sizeof(v->card));
usb_make_path(radio->usbdev, v->bus_info, sizeof(v->bus_info));
-   v->version = RADIO_VERSION;
v->capabilities = V4L2_CAP_TUNER;
return 0;
 }
@@ -647,3 +643,4 @@ module_exit (dsbr100_exit);
 MODULE_AUTHOR( DRIVER_AUTHOR );
 MODULE_DESCRIPTION( DRIVER_DESC );
 MODULE_LICENSE("GPL");
+MODULE_VERSION(DRIVER_VERSION);
diff --git a/drivers/media/radio/radio-aimslab.c 
b/drivers/media/radio/radio-aimslab.c
index 4ce10db..1c3f844 100644
--- a/drivers/media/radio/radio-aimslab.c
+++ b/drivers/media/radio/radio-aimslab.c
@@ -33,7 +33,6 @@
 #include   /* request_region   */
 #include/* msleep   */
 #include/* kernel radio structs */
-#include  /* for KERNEL_VERSION MACRO */
 #include   /* outb, outb_p */
 #include 
 #include 
@@ -41,6 +40,7 @@
 MODULE_AUTHOR("M.Kirkwood");
 MODULE_DESCRIPTION("A driver for the RadioTrack/RadioReveal radio card.");
 MODULE_LICENSE("GPL");
+MODULE_VERSION("0.0.3");
 
 #ifndef CONFIG_RADIO_RTRACK_PORT
 #define CONFIG_RADIO_RTRACK_PORT -1
@@ -53,8 +53,6 @@ module_param(io, int, 0);
 MODULE_PARM_DESC(io, "I/O address of the RadioTrack card (0x20f or 0x30f)");
 module_param(radio_nr, int, 0);
 
-#define RADIO_VERSION KERNEL_VERSION(0, 0, 2)
-
 struct rtrack
 {
struct v4l2_device v4l2_dev;
@@ -223,7 +221,6 @@ static int vidioc_querycap(struct file *file, void  *priv,
strlcpy(v->driver, "radio-aimslab", sizeof(v->driver));
strlcpy(v->card, "RadioTrack", sizeof(v->card));
strlcpy(v->bus_info, "ISA", sizeof(v->bus_info));
-   v->version = RADIO_VERSION;
v->capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
return 0;
 }
diff --git a/drivers/media/radio/radio-aztech.c 
b/drivers/media/radio/radio-aztech.c
index dd8a6ab..eed7b08 100644
--- a/drivers/media/radio/radio-aztech.c
+++ b/drivers/media/radio/radio-aztech.c
@@ -30,7 +30,6 @@
 #include   /* request_region   */
 #include/* udelay   */
 #include/* kernel radio structs */
-#include   /* for KERNEL_VERSION MACRO */
 #include   /* outb, outb_p */
 #include 
 #include 
@@ -38,6 +37,7 @@
 MODULE_AUTHOR("Russell Kroll, Quay Lu, Donald Song, Jason Lewis, Scott 
McGrath, William McGrath");
 MODULE_DESCRIPTION("A driver for the Aztech radio card.");
 MODULE_LICENSE("GPL");
+MODULE_VERSION("0.0.3");
 
 /* acceptable ports: 0x350 (JP3 shorted), 0x358 (JP3 open) */
 
@@ -53,8 +53,6 @@ module_param(io, int, 0);
 module_param(radio_nr, int, 0);
 MODULE_PARM_DESC(io, "I/O address of the Aztech card (0x350 or 0x358)");
 
-#define RADIO_VERSION KERNEL_VERSION(0, 0, 2)
-
 struct aztech
 {
struct v4l2_device v4l2_dev;
@@ -188,7 +186,6 @@ static int vidioc_querycap(struct file *file, void  *priv,
strlcpy(v->driver, "radio-aztech", sizeof(v->driver));
strlcpy(v->card, "Aztech Radio", sizeof(v->card));
strlcpy(v->bus_info, "ISA", sizeof(v->bus_info));
-   v->version = RADIO_VERSION;
v->capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
return 0;
 }
diff --git a/drivers/media/radio/radio-cadet.c 
b/drivers/media/radio/radio-cadet.c
index bc9ad08..16a089f 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -30,7 +30,6 @@
  * Changed API to V4L2
  */
 
-#include 
 #include   /* Modules  */
 #include /* Initdata */
 #include   /* request_region   */
@@ -46,6 +45,7 @@
 MODULE_AUTHOR("Fred Gleason, Russell Kroll, Quay Lu, Donald Song, Jason Lewis, 
Scott McGrath, William McGrath");
 MODULE_DESCRIPTION("A driver for the ADS Cadet AM/FM/RDS radio card.");
 MODULE_LICENSE("GPL");
+MODULE_VERSION("0.3.4");
 
 static int io = -1;/* default to isapnp activation */
 static int radio_nr = -1;
@@ -54,8 +54,6 @@ module_param(io, int, 0);
 MODULE_PARM_DESC(io, "I/O address of Cadet card 
(0x330,0x332,0x334,0x336,0x338,0x33a,0x33c,0x33e)");
 module_param(radio_nr, int, 0);
 
-#define CADET_VERSIO

[PATCHv2 04/13] [media] pwc: Use the default version for VIDIOC_QUERYCAP

[Mauro Carvalho Chehab]

After discussing with Hans, change pwc to use the default version
control.

The only version ever used for pwc driver is 10.0.12, due to
commit 2b455db6d456ef2d44808a8377fd3bc832e08317.

Changing it to 3.x.y won't conflict with the old version.
There's no namespace conflicts in any predictable future.

Even on the remote far-away case where we might have a conflict,
it will be on just one specific stable Kernel release (Kernel 10.0.12),
if we ever have such stable release.

So, it is safe and consistent on using 3.x.y numering schema for
it.

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/video/pwc/pwc-v4l.c 
b/drivers/media/video/pwc/pwc-v4l.c
index f85c512..059bd95 100644
--- a/drivers/media/video/pwc/pwc-v4l.c
+++ b/drivers/media/video/pwc/pwc-v4l.c
@@ -349,7 +349,6 @@ static int pwc_querycap(struct file *file, void *fh, struct 
v4l2_capability *cap
strcpy(cap->driver, PWC_NAME);
strlcpy(cap->card, vdev->name, sizeof(cap->card));
usb_make_path(pdev->udev, cap->bus_info, sizeof(cap->bus_info));
-   cap->version = PWC_VERSION_CODE;
cap->capabilities =
V4L2_CAP_VIDEO_CAPTURE  |
V4L2_CAP_STREAMING  |
diff --git a/drivers/media/video/pwc/pwc.h b/drivers/media/video/pwc/pwc.h
index 78185c6..98950de 100644
--- a/drivers/media/video/pwc/pwc.h
+++ b/drivers/media/video/pwc/pwc.h
@@ -44,12 +44,7 @@
 #include 
 
 /* Version block */
-#define PWC_MAJOR  10
-#define PWC_MINOR  0
-#define PWC_EXTRAMINOR 15
-
-#define PWC_VERSION_CODE KERNEL_VERSION(PWC_MAJOR, PWC_MINOR, PWC_EXTRAMINOR)
-#define PWC_VERSION __stringify(PWC_MAJOR) "." __stringify(PWC_MINOR) "." 
__stringify(PWC_EXTRAMINOR)
+#define PWC_VERSION"10.0.15"
 #define PWC_NAME   "pwc"
 #define PFXPWC_NAME ": "
 
-- 
1.7.1


--
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

[PATCHv2 03/13] [media] Stop using linux/version.h on most video drivers

[Mauro Carvalho Chehab]

All the modified drivers didn't have any version increment since
Jan, 1 2011. Several of them didn't have any version increment
for a long time, even having new features and important bug fixes
happening.

As we're now filling the QUERYCAP version with the current Kernel
Release, we don't need to maintain a per-driver version control
anymore. So, let's just use the default.

In order to preserve the Kernel module version history, a
KERNEL_VERSION() macro were added to all modified drivers, and
the extraver number were incremented.

I opted to preserve the per-driver version control to a few
drivers: cx18, davinci, fsl-viu, gspca, ivtv, m5mols, soc_camera,
pwc, pvrusb2, s2255, s5p-fimc and sh_vou.

A few drivers are still using the legacy way to handle ioctl's.
So, we can't do such change on them, otherwise, they'll break.
Those are: uvc, et61x251 and sn9c102.

The rationale is that the per-driver version control seems to be
actively maintained on those.

Yet, I think that the better for them would be to just use the
default version numbering, instead of doing that by themselves.

While here, removed a few uneeded include linux/version.h

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/video/arv.c b/drivers/media/video/arv.c
index f989f28..b6ed44a 100644
--- a/drivers/media/video/arv.c
+++ b/drivers/media/video/arv.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -54,7 +53,7 @@
  */
 #define USE_INT0   /* Don't modify */
 
-#define VERSION"0.04"
+#define VERSION"0.0.5"
 
 #define ar_inl(addr)   inl((unsigned long)(addr))
 #define ar_outl(val, addr) outl((unsigned long)(val), (unsigned 
long)(addr))
@@ -404,7 +403,6 @@ static int ar_querycap(struct file *file, void  *priv,
strlcpy(vcap->driver, ar->vdev.name, sizeof(vcap->driver));
strlcpy(vcap->card, "Colour AR VGA", sizeof(vcap->card));
strlcpy(vcap->bus_info, "Platform", sizeof(vcap->bus_info));
-   vcap->version = KERNEL_VERSION(0, 0, 4);
vcap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_READWRITE;
return 0;
 }
@@ -879,3 +877,4 @@ module_exit(ar_cleanup_module);
 MODULE_AUTHOR("Takeo Takahashi ");
 MODULE_DESCRIPTION("Colour AR M64278(VGA) for Video4Linux");
 MODULE_LICENSE("GPL");
+MODULE_VERSION(VERSION);
diff --git a/drivers/media/video/au0828/au0828-core.c 
b/drivers/media/video/au0828/au0828-core.c
index ca342e4..1e4ce50 100644
--- a/drivers/media/video/au0828/au0828-core.c
+++ b/drivers/media/video/au0828/au0828-core.c
@@ -292,3 +292,4 @@ module_exit(au0828_exit);
 MODULE_DESCRIPTION("Driver for Auvitek AU0828 based products");
 MODULE_AUTHOR("Steven Toth ");
 MODULE_LICENSE("GPL");
+MODULE_VERSION("0.0.2");
diff --git a/drivers/media/video/au0828/au0828-video.c 
b/drivers/media/video/au0828/au0828-video.c
index c03eb29..0b3e481 100644
--- a/drivers/media/video/au0828/au0828-video.c
+++ b/drivers/media/video/au0828/au0828-video.c
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -43,8 +42,6 @@
 
 static DEFINE_MUTEX(au0828_sysfs_lock);
 
-#define AU0828_VERSION_CODE KERNEL_VERSION(0, 0, 1)
-
 /* --
Videobuf operations
--*/
@@ -1254,8 +1251,6 @@ static int vidioc_querycap(struct file *file, void  *priv,
strlcpy(cap->card, dev->board.name, sizeof(cap->card));
strlcpy(cap->bus_info, dev->v4l2_dev.name, sizeof(cap->bus_info));
 
-   cap->version = AU0828_VERSION_CODE;
-
/*set the device capabilities */
cap->capabilities = V4L2_CAP_VIDEO_CAPTURE |
V4L2_CAP_VBI_CAPTURE |
diff --git a/drivers/media/video/bt8xx/bttv-driver.c 
b/drivers/media/video/bt8xx/bttv-driver.c
index a97cf27..696e978 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -57,6 +57,7 @@
 
 #include 
 
+#define BTTV_VERSION "0.9.19"
 
 unsigned int bttv_num; /* number of Bt848s in use */
 struct bttv *bttvs[BTTV_MAX];
@@ -163,6 +164,7 @@ MODULE_PARM_DESC(radio_nr, "radio device numbers");
 MODULE_DESCRIPTION("bttv - v4l/v4l2 driver module for bt848/878 based cards");
 MODULE_AUTHOR("Ralph Metzler & Marcus Metzler & Gerd Knorr");
 MODULE_LICENSE("GPL");
+MODULE_VERSION(BTTV_VERSION);
 
 /* --- */
 /* sysfs   */
@@ -2616,7 +2618,6 @@ static int bttv_querycap(struct file *file, void  *priv,
strlcpy(cap->card, btv->video_dev->name, sizeof(cap->card));
snprintf(cap->bus_info, sizeof(cap->bus_info),
 "PCI:%s", pci_name(btv->c.pci));
-   cap->version = BTTV_VERSION_CODE;
cap->capabilities =
V4L2_CAP_VIDEO_CAPTURE |
 

[PATCHv2 01/13] [media] v4l2-ioctl: Add a default value for kernel version

[Mauro Carvalho Chehab]

Most drivers don't increase kernel versions as newer features are added or
bug fixes are solved. So, vidioc_querycap returned value for cap->version is
meaningless. Instead of keeping this situation forever, let's add a default
value matching the current Linux version.

Drivers that want to keep their own version control can still do it, as they
can override the default value for cap->version.

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 213ba7d..61ac6bf 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -605,6 +606,7 @@ static long __video_do_ioctl(struct file *file,
if (!ops->vidioc_querycap)
break;
 
+   cap->version = LINUX_VERSION_CODE;
ret = ops->vidioc_querycap(file, fh, cap);
if (!ret)
dbgarg(cmd, "driver=%s, card=%s, bus=%s, "
-- 
1.7.1


--
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

[PATCH] Fix locking problem in vivi

[Hans Verkuil]

Fix sleep-in-atomic-context bug in vivi (you need to run with lock debugging 
on):

Jun 28 18:14:39 tschai kernel: [   80.970478] BUG: sleeping function called 
from invalid context at kernel/mutex.c:271
Jun 28 18:14:39 tschai kernel: [   80.970483] in_atomic(): 0, irqs_disabled(): 
1, pid: 2854, name: vivi-000
Jun 28 18:14:39 tschai kernel: [   80.970485] INFO: lockdep is turned off.
Jun 28 18:14:39 tschai kernel: [   80.970486] irq event stamp: 0
Jun 28 18:14:39 tschai kernel: [   80.970487] hardirqs last  enabled at (0): [< 
 (null)>]   (null)
Jun 28 18:14:39 tschai kernel: [   80.970490] hardirqs last disabled at (0): 
[] copy_process+0x61b/0x1440
Jun 28 18:14:39 tschai kernel: [   80.970495] softirqs last  enabled at (0): 
[] copy_process+0x61b/0x1440
Jun 28 18:14:39 tschai kernel: [   80.970498] softirqs last disabled at (0): [< 
 (null)>]   (null)
Jun 28 18:14:39 tschai kernel: [   80.970502] Pid: 2854, comm: vivi-000 
Tainted: P3.0.0-rc1-tschai #372
Jun 28 18:14:39 tschai kernel: [   80.970504] Call Trace:
Jun 28 18:14:39 tschai kernel: [   80.970509]  [] 
__might_sleep+0xf3/0x130
Jun 28 18:14:39 tschai kernel: [   80.970512]  [] 
mutex_lock_nested+0x2f/0x60
Jun 28 18:14:39 tschai kernel: [   80.970517]  [] 
vivi_fillbuff+0x20e/0x3f0 [vivi]
Jun 28 18:14:39 tschai kernel: [   80.970520]  [] ? 
do_raw_spin_lock+0x54/0x150
Jun 28 18:14:39 tschai kernel: [   80.970524]  [] ? 
read_tsc+0xe/0x20
Jun 28 18:14:39 tschai kernel: [   80.970528]  [] ? 
getnstimeofday+0x57/0xe0
Jun 28 18:14:39 tschai kernel: [   80.970531]  [] 
vivi_thread+0x191/0x2f0 [vivi]
Jun 28 18:14:39 tschai kernel: [   80.970534]  [] ? 
try_to_wake_up+0x2d0/0x2d0
Jun 28 18:14:39 tschai kernel: [   80.970537]  [] ? 
vivi_fillbuff+0x3f0/0x3f0 [vivi]
Jun 28 18:14:39 tschai kernel: [   80.970541]  [] 
kthread+0xb6/0xc0
Jun 28 18:14:39 tschai kernel: [   80.970544]  [] 
kernel_thread_helper+0x4/0x10
Jun 28 18:14:39 tschai kernel: [   80.970547]  [] ? 
retint_restore_args+0x13/0x13
Jun 28 18:14:39 tschai kernel: [   80.970550]  [] ? 
__init_kthread_worker+0x70/0x70
Jun 28 18:14:39 tschai kernel: [   80.970552]  [] ? 
gs_change+0x13/0x13

Tested with vivi.

This bug was introduced in 2.6.39.

Regards,

Hans

Signed-off-by: Hans Verkuil 

diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 2238a61..52eff8b 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -524,11 +524,13 @@ static void vivi_thread_tick(struct vivi_dev *dev)
spin_lock_irqsave(&dev->slock, flags);
if (list_empty(&dma_q->active)) {
dprintk(dev, 1, "No active queue to serve\n");
-   goto unlock;
+   spin_unlock_irqrestore(&dev->slock, flags);
+   return;
}
 
buf = list_entry(dma_q->active.next, struct vivi_buffer, list);
list_del(&buf->list);
+   spin_unlock_irqrestore(&dev->slock, flags);
 
do_gettimeofday(&buf->vb.v4l2_buf.timestamp);
 
@@ -538,8 +540,6 @@ static void vivi_thread_tick(struct vivi_dev *dev)
 
vb2_buffer_done(&buf->vb, VB2_BUF_STATE_DONE);
dprintk(dev, 2, "[%p/%d] done\n", buf, buf->vb.v4l2_buf.index);
-unlock:
-   spin_unlock_irqrestore(&dev->slock, flags);
 }
 
 #define frames_to_ms(frames)   \
--
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

Re: [PATCH] [media] v4l2 core: return -ENOIOCTLCMD if an ioctl doesn't exist

[Linus Torvalds]

On Mon, Jun 27, 2011 at 11:04 PM, Hans Verkuil  wrote:
>
> Of course, since vfs_ioctl does the same thing this is clearly isn't some
> isolated V4L thing. Pot. Kettle.

Oh, absolutely. V4L is not at all the only confused user around.

The EINVAL thing goes way back, and is a disaster. It predates Linux
itself, as far as I can tell. You'll fin dlots of man-pages that have
this line in it:

  EINVAL Request or argp is not valid.

and it shows up in POSIX etc. And sadly, it generally shows up
_before_ the line that says

  ENOTTY The specified request does not apply to the kind of object
that the descriptor d references.

so a lot of people get to the EINVAL, and never even notice the ENOTTY.

And the above is from the current Linux man-pages - they are better
than most. Googling for posix and ioctl, the first hit is some
streams-specific man-page that is much worse, and makes you really
think that EINVAL would be the right error for a bad ioctl.

The reason is probably that ENOTTY has always been a "wft?" kind of
error code. It doesn't make sense as a name for some filesystem or
driver writer. Any sane person goes "Of _course_ it's not a tty, why
would I say that?"

At least glibc (and hopefully other C libraries) use a _string_ that
makes much more sense: strerror(ENOTTY) is "Inappropriate ioctl for
device"

The particular translation of ENOIOCTLCMD to EINVAL was always a
mistake. I'll happily try to change it for 3.1, but I'll need to do it
early in the merge window to check for any issues.

(In fact, the _correct_ thing to do would probably be to just do

   #define ENOIOCTLCMD ENOTTY

and get rid of any translation - just giving ENOTTY a more appropriate
name and less chance for confusion)

> It was my understanding that we shouldn't break the userspace API. This breaks
> the userspace API. If everyone else says it's fine to break the userspace API
> this time, then who am I to object?

We are indeed never supposed to break userspace.

But that does not mean that we cannot fix bugs. It only means exactly
what it says: we cannot break user space.

If we fix a bug, and it turns out that user space actually depends on
that bug, then we need to revert the fix. But it never means "you can
never make any changes at all to interfaces". It only means "you
cannot make any changes that break applications".

There may be applications out there that really break when they get
ENOTTY instead of EINVAL. But most cases that check for errors from
ioctl's tend to just say "did this succeed or not" rather than "did
this return EINVAL". That's *doubly* true since the error code has
been ambiguous, so checking for the exact error code has always been
pretty pointless.

So the common use of the error code tends to be for things like
strerror(), and then it would be a real improvement to show
"Inappropriate ioctl for device" when the device doesn't support that
ioctl, wouldn't it?

But yes, let's try to fix it, and if it turns out that that breaks
something, we must simply revert and probably add a comment to the
source code ("EINVAL is wrong, it should be ENOTTY, but xyzzy only
works with EINVAL").

   Linus
--
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

[RFC PATCH] Add support for V4L2_EVENT_SUB_FL_NO_FEEDBACK

[Hans Verkuil]

Originally no control events would go to the filehandle that called the
VIDIOC_S_CTRL/VIDIOC_S_EXT_CTRLS ioctls. This was to prevent a feedback
loop.

This is now only done if the new V4L2_EVENT_SUB_FL_NO_FEEDBACK flag is
set.

Based on a suggestion from Mauro Carvalho Chehab .

This goes on top of the patch series I posted today titled:
"Allocate events per-event-type, v4l2-ctrls cleanup"

Signed-off-by: Hans Verkuil 
---
 .../DocBook/media/v4l/vidioc-subscribe-event.xml   |   31 ++--
 drivers/media/video/v4l2-ctrls.c   |3 +-
 include/linux/videodev2.h  |3 +-
 3 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml 
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 039a969..0d4465f 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -114,25 +114,20 @@
  
V4L2_EVENT_CTRL
3
-   This event requires that the id
+   This event requires that the 
id
matches the control ID from which you want to receive events.
This event is triggered if the control's value changes, if a
button control is pressed or if the control's flags change.
This event has a &v4l2-event-ctrl; associated with it. This 
struct
contains much of the same information as &v4l2-queryctrl; and
-   &v4l2-control;.
+   &v4l2-control;.
 
-   If the event is generated due to a call to &VIDIOC-S-CTRL; or
-   &VIDIOC-S-EXT-CTRLS;, then the event will not be sent to
-   the file handle that called the ioctl function. This prevents
-   nasty feedback loops.
-
-   This event type will ensure that no information is lost when
+   This event type will ensure that no information is lost 
when
more events are raised than there is room internally. In that
case the &v4l2-event-ctrl; of the second-oldest event is kept,
but the changes field of the
second-oldest event is ORed with the 
changes
-   field of the oldest event.
+   field of the oldest event.

  
  
@@ -157,6 +152,24 @@
that are triggered by a status change such as 
V4L2_EVENT_CTRL.
Other events will ignore this flag.
  
+ 
+   V4L2_EVENT_SUB_FL_NO_FEEDBACK
+   0x0002
+   If set, then events directly caused by an ioctl will 
not be sent to
+   the filehandle that called that ioctl. For example, changing a 
control using
+   &VIDIOC-S-CTRL; will not cause a V4L2_EVENT_CTRL to be sent 
back to that
+   same filehandle. All other filehandles that are subscribed to 
that event
+   will still receive it. This prevents feedback loops where an 
application
+   changes a control to a one value and then another, and then 
receives an
+   event telling it that that control has changed to the first 
value.
+
+   Since it can't tell whether that event was caused by 
another application
+   or by the first value change it is hard to decide whether to 
set the
+   control to the value in the event, or ignore it.
+
+   This flag will prevent this situation from 
happening.
+   
+ 

   
 
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index bc08f86..bac793a 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -590,7 +590,8 @@ static void send_event(struct v4l2_fh *fh, struct v4l2_ctrl 
*ctrl, u32 changes)
fill_event(&ev, ctrl, changes);
 
list_for_each_entry(sev, &ctrl->ev_subs, node)
-   if (sev->fh && sev->fh != fh)
+   if (sev->fh && (sev->fh != fh ||
+   !(sev->flags & V4L2_EVENT_SUB_FL_NO_FEEDBACK)))
v4l2_event_queue_fh(sev->fh, &ev);
 }
 
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index baafe2f..00bae77 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1832,7 +1832,8 @@ struct v4l2_event {
__u32   reserved[8];
 };
 
-#define V4L2_EVENT_SUB_FL_SEND_INITIAL (1 << 0)
+#define V4L2_EVENT_SUB_FL_SEND_INITIAL (1 << 0)
+#define V4L2_EVENT_SUB_FL_NO_FEEDBACK  (1 << 1)
 
 struct v4l2_event_subscription {
__u32   type;
-- 
1.7.1

--
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

[RFC PATCH] capture-example: allow V4L2_PIX_FMT_GREY with USERPTR

[Michael Jones]

There is an assumption that the format coming from the device
needs 2 bytes per pixel, which is not the case when the device
delivers e.g. V4L2_PIX_FMT_GREY. This doesn't manifest itself with
IO_METHOD_MMAP because init_mmap() (the default) doesn't take
sizeimage as an argument.

Signed-off-by: Michael Jones 
---

This same issue would apply to other formats which have 1 byte per pixel,
this patch only fixes it for GREY.  Is this OK for now, or does somebody
have a better suggestion for supporting other formats as well?

 contrib/test/capture-example.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/contrib/test/capture-example.c b/contrib/test/capture-example.c
index 3852c58..0eb5235 100644
--- a/contrib/test/capture-example.c
+++ b/contrib/test/capture-example.c
@@ -416,6 +416,7 @@ static void init_device(void)
struct v4l2_crop crop;
struct v4l2_format fmt;
unsigned int min;
+   unsigned int bytes_per_pixel;
 
if (-1 == xioctl(fd, VIDIOC_QUERYCAP, &cap)) {
if (EINVAL == errno) {
@@ -519,7 +520,8 @@ static void init_device(void)
}
 
/* Buggy driver paranoia. */
-   min = fmt.fmt.pix.width * 2;
+   bytes_per_pixel = fmt.fmt.pix.pixelformat == V4L2_PIX_FMT_GREY ? 1 : 2;
+   min = fmt.fmt.pix.width * bytes_per_pixel;
if (fmt.fmt.pix.bytesperline < min)
fmt.fmt.pix.bytesperline = min;
min = fmt.fmt.pix.bytesperline * fmt.fmt.pix.height;
-- 
1.7.5.4


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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

[GIT PATCHES FOR 3.1] Add Control Event and autofoo/foo support

[Hans Verkuil]

Hi Mauro,

This is the same as the first pull request, except for:

- the poll patch has been removed (to be discussed further)
- the corresponding poll changes in ivtv were removed (pending same
  discussion).
- a new patch has been added that fixes your manual_mode_value comments.

Note that I have left out the 'event feedback' fix in this patch series.
I'm going to make a patch for the second patch series instead: it's much
easier to implement there (that may have been a reason why I didn't
implement such a flag in the first place). I'll post that fix later for
review.

Regards,

Hans

The following changes since commit 7023c7dbc3944f42aa1d6910a6098c5f9e23d3f1:

  [media] DVB: dvb-net, make the kconfig text helpful (2011-06-21 15:55:15 
-0300)

are available in the git repository at:
  ssh://linuxtv.org/git/hverkuil/media_tree.git core8b

Hans Verkuil (18):
  v4l2-ctrls: introduce call_op define
  v4l2-ctrls: simplify error_idx handling.
  v4l2-ctrls: drivers should be able to ignore the READ_ONLY flag
  v4l2-ioctl: add ctrl_handler to v4l2_fh
  v4l2-subdev: implement per-filehandle control handlers.
  v4l2-ctrls: fix and improve volatile control handling.
  v4l2-controls.txt: update to latest v4l2-ctrl.c changes.
  v4l2-ctrls: add v4l2_ctrl_auto_cluster to simplify autogain/gain scenarios
  DocBook: Improve cluster documentation and document the new autoclusters.
  vivi: add autogain/gain support to test the autocluster functionality.
  v4l2-ctrls: add v4l2_fh pointer to the set control functions.
  v4l2-ctrls: add control events.
  v4l2-ctrls: simplify event subscription.
  V4L2 spec: document control events.
  vivi: support control events.
  ivtv: add control event support.
  v4l2-compat-ioctl32: add VIDIOC_DQEVENT support.
  v4l2-ctrls: make manual_mode_value 8 bits and check against control range.

 Documentation/DocBook/media/v4l/vidioc-dqevent.xml |   17 +-
 .../DocBook/media/v4l/vidioc-subscribe-event.xml   |  142 +-
 Documentation/video4linux/v4l2-controls.txt|   69 -
 drivers/media/radio/radio-wl1273.c |2 +-
 drivers/media/radio/wl128x/fmdrv_v4l2.c|2 +-
 drivers/media/video/ivtv/ivtv-fileops.c|   11 +-
 drivers/media/video/ivtv/ivtv-ioctl.c  |2 +
 drivers/media/video/saa7115.c  |4 +-
 drivers/media/video/v4l2-compat-ioctl32.c  |   37 +++
 drivers/media/video/v4l2-ctrls.c   |  333 
 drivers/media/video/v4l2-device.c  |1 +
 drivers/media/video/v4l2-event.c   |  130 ++--
 drivers/media/video/v4l2-fh.c  |6 +-
 drivers/media/video/v4l2-ioctl.c   |   40 ++-
 drivers/media/video/v4l2-subdev.c  |   14 +-
 drivers/media/video/vivi.c |   53 +++-
 include/linux/videodev2.h  |   29 ++-
 include/media/v4l2-ctrls.h |   92 +-
 include/media/v4l2-event.h |2 +
 include/media/v4l2-fh.h|2 +
 kernel/compat.c|1 +
 21 files changed, 842 insertions(+), 147 deletions(-)
--
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

Re: [RFCv3 PATCH 12/18] vb2_poll: don't start DMA, leave that to the first read().

[Hans Verkuil]

On Tuesday, June 28, 2011 14:43:22 Mauro Carvalho Chehab wrote:
> Em 28-06-2011 09:21, Andy Walls escreveu:
> > Mauro Carvalho Chehab  wrote:
> 
> >> I'm not very comfortable with vb2 returning unexpected errors there.
> >> Also,
> >> for me it is clear that, if read will fail, POLLERR should be rised.
> >>
> >> Mauro. 
> >> --
> >> 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
> > 
> > It is also the case that a driver's poll method should never sleep.
> 
> True.

Actually, it is allowed, but only since kernel 2.6.29 (before that it could
apparently give rise to busy looping if you were unlucky). But the main use
case is userspace file systems like fuse. Not so much in regular drivers.

Since drivers can sleep when starting streaming (ivtv will do that, in any
case), we were in violation of the poll kernel API for a long time :-)

> > I will try to find the conversation I had with laurent on interpreting the 
> > POSIX spec on error returns from select() and poll().  I will also try to 
> > find links to previos discussion with Hans on this.
> > 
> > One issue is how to start streaming with apps that:
> > - Open /dev/video/ in a nonblocking mode, and
> > - Use the read() method
> > 
> > while doing it in a way that is POSIX compliant and doesn't break existing 
> > apps.  
> 
> Well, a first call for poll() may rise a thread that will prepare the 
> buffers, and
> return with 0 while there's no data available.

There is actually no guarantee whatsoever that if poll says you can read(), 
that that
read also has to succeed. Other threads can have read the data already, and 
errors may
have occured. And in fact, just starting streaming gives no guarantee that 
there is
anything to read. For example, starting the DMA engine when there is no valid 
input
signal. Many drivers (certainly those dealing with digital interfaces as 
opposed to
analog) will just sit and wait. A non-blocking read will just return 0 without
reading anything.

So the current poll implementation (and that includes the one in 
videobuf-core.c as
well) actually does *not* give any guarantee about whether data will be 
available
in read().

And from the same POSIX link you posted:

"The poll() function shall support regular files, terminal and pseudo-terminal 
devices,
FIFOs, pipes, sockets and [XSR] [Option Start]  STREAMS-based files. [Option 
End]
The behavior of poll() on elements of fds that refer to other types of file is 
unspecified."

Note the last line: we do not fall under this posix document.
 
> > The other constraint is to ensure when only poll()-ing for exception 
> > conditions, not having significant IO side effects.
> > 
> > I'm pretty sure sleeping in a driver's poll() method, or having significant 
> > side effects, is not ine the spirit of the POSIX select() and poll(), even 
> > if the letter of POSIX says nothing about it.
> > 
> > The method I suggested to Hans is completely POSIX compliant for apps using 
> > read() and select() and was checked against MythTV as having no bad side 
> > effects.  (And by thought experiment doesn't break any sensible app using 
> > nonblocking IO with select() and read().)
> > 
> > I did not do analysis for apps that use mmap(), which I guess is the 
> > current concern.

There isn't a problem with mmap(). For the stream I/O API you have to call 
STREAMON
explicitly in order to start streaming. poll() will not do that for you.

I was thinking that one improvement that could be realized is that vb2_poll 
could
do some basic checks, such as checking whether streaming was already in progress
(EBUSY), but then I realized that it already does that: this code is only active
if there is no streaming in progress anyway.

Regards,

Hans

> 
> The concern is that it is pointing that there are available data, even when 
> there is an error.
> This looks like a POSIX violation for me.
> 
> Cheers,
> Mauro.
> --
> 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
> 
--
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

Re: [PATCH] Fix suspend/resume of pxa_camera driver

[Guennadi Liakhovetski]

Hi Robert

Hope you don't mind me resuming an almost 3 year old mail thread;) I'm 
referring to your patches to soc-camera core and pxa-camera, adding PM 
support to them. Below is your message again, explaining, why the standard 
pm hooks cannot be used to suspend and resume the camera host and the 
camera sensor. While trying to make soc-camera play nicer with the V4L2 
generic framework, I was trying to eliminate as many redundant pieces from 
soc-camera as possible and replace them with standard methods. This made 
me re-consider those your patches. Let's have a look at your 
argumentation:

On Thu, 31 Jul 2008, Guennadi Liakhovetski wrote:

> On Wed, 30 Jul 2008, Robert Jarzmik wrote:
> 
> > Guennadi Liakhovetski  writes:
> > 
> > >> >> For the camera part, by now, I'm using standard suspend/resume 
> > >> >> functions of the
> > >> >> platform driver (mt9m111.c). It does work, but it's not clean ATM. 
> > >> >> The chaining
> > >> >> between the driver resume function and the availability of the I2C 
> > >> >> bus are not
> > >> >> properly chained. I'm still working on it.
> > >> >
> > >> > Yes, we have to clarify this too.
> > All right, I have my mind clarified, let's discuss now.
> > 
> > >>  - I cook up a clean suspend/resume (unless you did it first of course :)
> > Well, let's expose what we're facing here :
> >  - our video chip driver (ex: mt9m111) is an i2c driver
> >   => its resume function is called when i2c bus is resumed, so all is fine 
> > here
> > 
> >  - our video chip needs an external clock to work
> >   => example: mt9m111 needs a clock from pxa camera interface to have its 
> > i2c
> >   unit enabled
> >   => the mt9m111 driver resume function is unusable, as pxa_camera is 
> > resumed
> >   _after_ mt9m111, and thus mt9m111's i2c unit is not available at that 
> > moment
> > 
> >  - a working suspend/resume restores fully the video chip state
> >   => restores width/height/bpp
> >   => restores autoexposure, brightness, etc ...
> >   => all that insures userland is not impacted by suspend/resume
> > 
> > So, the only way I see to have suspend/resume working is :
> >  - modify soc_camera_ops to add suspend and resume functions
> >  - add suspend and resume functions in each chip driver (mt9m001, mt9m111, 
> > ...)
> >  - modify soc_camera.c (or pxa_camera.c ?) to call icd->ops->suspend() and
> >  icd->ops->resume()
> >  - modify pxa_camera.c (the patch I sent before)

So, we currently have 3 instances: soc-camera bus, i2c bus, and pxa-camera 
platform device driver. You say, i2c resumes as first, then at some point 
pxa-camera and soc-camera - in this or reverse order. This is why we 
cannoe use i2c-resume to bring the sensor up before pxa-camera has 
restored its master clock. So, currently we hook onto the soc-camera bus, 
which then calls pxa-camera's resume, which then restores camera host's 
state and resumes the sensor. Now, the question: wouldn't this also work, 
if we eliminate the soc-camera resume path? And instead just used 
pxa-camera resume method to bring up the sensor? Coule you please test the 
below patch?

Thanks
Guennadi

> > 
> > Would you find that acceptable, or is there a better way ?
> 
> Ok, you're suggesting to add suspend() and resume() to 
> soc_camera_bus_type, right? But are we sure that its resume will be called 
> after both camera (so far i2c) and host (so far platform, can also be PCI 
> or USB...) busses are resumed? If not, we might have to do something 
> similar to scan_add_host() / scan_add_device() - accept signals from the 
> host and the camera and when both are ready actually resume them...
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> 
> --
> video4linux-list mailing list
> Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Subject: [PATCH] V4L: remove soc-camera PM, use camera host driver PM instead

Using soc-camera bus power management to suspend and resume video devices 
introduces a redundant indirection level. It can easily be removed by 
using camera host driver's own PM hooks.

Signed-off-by: Guennadi Liakhovetski 
---
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index ebebed9..ec9e829 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -727,7 +727,7 @@ static const struct v4l2_queryctrl mt9m111_controls[] = {
 };
 
 static int mt9m111_resume(struct soc_camera_device *icd);
-static int mt9m111_suspend(struct soc_camera_device *icd, pm_message_t state);
+static int mt9m111_suspend(struct soc_camera_device *icd);
 
 static struct soc_camera_ops mt9m111_ops = {
.suspend= mt9m111_suspend,
@@ -901,7 +901,7 @@ static int mt9m111_s_ctrl(struct v4l2_subdev *sd, struct 
v4l2_control *ctrl)
return r

Help getting TechniSat SkyStar HD2 working in Ubuntu 10.10

[John Taylor]

I'm having problems with this card- I can get it to scan DVB-S and
DVB-S2 using scan-s2, and can get it to tune to DVB-S channels, but I
cannot szap to DVB-S2 channels

szap2 -p -t 2 "BBC HD" reports error ioctl DVBFE_SET_DELSYS failed:
Operation not supported

I have tried the latest s2-liplianin and v4l-dvb mantis drivers but no joy

Can anyone help?

John

output lspci -vv
01:08.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV
PCI Bridge Controller [Ver 1.0] (rev 01)
Subsystem: Device 1ae4:0003
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR-  Link[LNKA] -> GSI 18
(level, low) -> IRQ 18
[  161.582113] DVB: registering new adapter (Mantis DVB adapter)
[  162.471365] stb0899_attach: Attaching STB0899
[  162.471375] stb6100_attach: Attaching STB6100
[  162.471593] LNBx2x attached on addr=8
[  162.471601] DVB: registering adapter 1 frontend 0 (STB0899 Multistandard)...
--
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

Re: [GIT PATCHES FOR 3.1] Add Control Event and autofoo/foo support

[Hans Verkuil]

On Tuesday, June 28, 2011 14:53:22 Hans Verkuil wrote:
> Hi Mauro,
> 
> This is the same as the first pull request, except for:
> 
> - the poll patch has been removed (to be discussed further)
> - a new patch has been added that fixes your manual_mode_value comments.

I've removed this branch: without the poll change I also need to revert part
of the vivi and ivtv changes.

I'll repost soon.

Regards,

Hans

> 
> Note that I have left out the 'event feedback' fix in this patch series.
> I'm going to make a patch for the second patch series instead: it's much
> easier to implement there (that may have been a reason why I didn't
> implement such a flag in the first place). I'll post that fix later for
> review.
> 
> Regards,
> 
>   Hans
> 
> The following changes since commit 7023c7dbc3944f42aa1d6910a6098c5f9e23d3f1:
> 
>   [media] DVB: dvb-net, make the kconfig text helpful (2011-06-21 15:55:15 
> -0300)
> 
> are available in the git repository at:
>   ssh://linuxtv.org/git/hverkuil/media_tree.git core8b
> 
> Hans Verkuil (18):
>   v4l2-ctrls: introduce call_op define
>   v4l2-ctrls: simplify error_idx handling.
>   v4l2-ctrls: drivers should be able to ignore the READ_ONLY flag
>   v4l2-ioctl: add ctrl_handler to v4l2_fh
>   v4l2-subdev: implement per-filehandle control handlers.
>   v4l2-ctrls: fix and improve volatile control handling.
>   v4l2-controls.txt: update to latest v4l2-ctrl.c changes.
>   v4l2-ctrls: add v4l2_ctrl_auto_cluster to simplify autogain/gain 
> scenarios
>   DocBook: Improve cluster documentation and document the new 
> autoclusters.
>   vivi: add autogain/gain support to test the autocluster functionality.
>   v4l2-ctrls: add v4l2_fh pointer to the set control functions.
>   v4l2-ctrls: add control events.
>   v4l2-ctrls: simplify event subscription.
>   V4L2 spec: document control events.
>   vivi: support control events.
>   ivtv: add control event support.
>   v4l2-compat-ioctl32: add VIDIOC_DQEVENT support.
>   v4l2-ctrls: make manual_mode_value 8 bits and check against control 
> range.
> 
>  Documentation/DocBook/media/v4l/vidioc-dqevent.xml |   17 +-
>  .../DocBook/media/v4l/vidioc-subscribe-event.xml   |  142 +-
>  Documentation/video4linux/v4l2-controls.txt|   69 -
>  drivers/media/radio/radio-wl1273.c |2 +-
>  drivers/media/radio/wl128x/fmdrv_v4l2.c|2 +-
>  drivers/media/video/ivtv/ivtv-fileops.c|   34 +--
>  drivers/media/video/ivtv/ivtv-ioctl.c  |2 +
>  drivers/media/video/saa7115.c  |4 +-
>  drivers/media/video/v4l2-compat-ioctl32.c  |   37 +++
>  drivers/media/video/v4l2-ctrls.c   |  333 
> 
>  drivers/media/video/v4l2-device.c  |1 +
>  drivers/media/video/v4l2-event.c   |  130 ++--
>  drivers/media/video/v4l2-fh.c  |6 +-
>  drivers/media/video/v4l2-ioctl.c   |   40 ++-
>  drivers/media/video/v4l2-subdev.c  |   14 +-
>  drivers/media/video/vivi.c |   53 +++-
>  include/linux/videodev2.h  |   29 ++-
>  include/media/v4l2-ctrls.h |   92 +-
>  include/media/v4l2-event.h |2 +
>  include/media/v4l2-fh.h|2 +
>  kernel/compat.c|1 +
>  21 files changed, 849 insertions(+), 163 deletions(-)
> --
> 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
> 
--
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

[GIT PATCHES FOR 3.1] Add Control Event and autofoo/foo support

[Hans Verkuil]

Hi Mauro,

This is the same as the first pull request, except for:

- the poll patch has been removed (to be discussed further)
- a new patch has been added that fixes your manual_mode_value comments.

Note that I have left out the 'event feedback' fix in this patch series.
I'm going to make a patch for the second patch series instead: it's much
easier to implement there (that may have been a reason why I didn't
implement such a flag in the first place). I'll post that fix later for
review.

Regards,

Hans

The following changes since commit 7023c7dbc3944f42aa1d6910a6098c5f9e23d3f1:

  [media] DVB: dvb-net, make the kconfig text helpful (2011-06-21 15:55:15 
-0300)

are available in the git repository at:
  ssh://linuxtv.org/git/hverkuil/media_tree.git core8b

Hans Verkuil (18):
  v4l2-ctrls: introduce call_op define
  v4l2-ctrls: simplify error_idx handling.
  v4l2-ctrls: drivers should be able to ignore the READ_ONLY flag
  v4l2-ioctl: add ctrl_handler to v4l2_fh
  v4l2-subdev: implement per-filehandle control handlers.
  v4l2-ctrls: fix and improve volatile control handling.
  v4l2-controls.txt: update to latest v4l2-ctrl.c changes.
  v4l2-ctrls: add v4l2_ctrl_auto_cluster to simplify autogain/gain scenarios
  DocBook: Improve cluster documentation and document the new autoclusters.
  vivi: add autogain/gain support to test the autocluster functionality.
  v4l2-ctrls: add v4l2_fh pointer to the set control functions.
  v4l2-ctrls: add control events.
  v4l2-ctrls: simplify event subscription.
  V4L2 spec: document control events.
  vivi: support control events.
  ivtv: add control event support.
  v4l2-compat-ioctl32: add VIDIOC_DQEVENT support.
  v4l2-ctrls: make manual_mode_value 8 bits and check against control range.

 Documentation/DocBook/media/v4l/vidioc-dqevent.xml |   17 +-
 .../DocBook/media/v4l/vidioc-subscribe-event.xml   |  142 +-
 Documentation/video4linux/v4l2-controls.txt|   69 -
 drivers/media/radio/radio-wl1273.c |2 +-
 drivers/media/radio/wl128x/fmdrv_v4l2.c|2 +-
 drivers/media/video/ivtv/ivtv-fileops.c|   34 +--
 drivers/media/video/ivtv/ivtv-ioctl.c  |2 +
 drivers/media/video/saa7115.c  |4 +-
 drivers/media/video/v4l2-compat-ioctl32.c  |   37 +++
 drivers/media/video/v4l2-ctrls.c   |  333 
 drivers/media/video/v4l2-device.c  |1 +
 drivers/media/video/v4l2-event.c   |  130 ++--
 drivers/media/video/v4l2-fh.c  |6 +-
 drivers/media/video/v4l2-ioctl.c   |   40 ++-
 drivers/media/video/v4l2-subdev.c  |   14 +-
 drivers/media/video/vivi.c |   53 +++-
 include/linux/videodev2.h  |   29 ++-
 include/media/v4l2-ctrls.h |   92 +-
 include/media/v4l2-event.h |2 +
 include/media/v4l2-fh.h|2 +
 kernel/compat.c|1 +
 21 files changed, 849 insertions(+), 163 deletions(-)
--
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

Re: [RFCv3 PATCH 12/18] vb2_poll: don't start DMA, leave that to the first read().

[Mauro Carvalho Chehab]

Em 28-06-2011 09:21, Andy Walls escreveu:
> Mauro Carvalho Chehab  wrote:

>> I'm not very comfortable with vb2 returning unexpected errors there.
>> Also,
>> for me it is clear that, if read will fail, POLLERR should be rised.
>>
>> Mauro. 
>> --
>> 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
> 
> It is also the case that a driver's poll method should never sleep.

True.

> I will try to find the conversation I had with laurent on interpreting the 
> POSIX spec on error returns from select() and poll().  I will also try to 
> find links to previos discussion with Hans on this.
> 
> One issue is how to start streaming with apps that:
> - Open /dev/video/ in a nonblocking mode, and
> - Use the read() method
> 
> while doing it in a way that is POSIX compliant and doesn't break existing 
> apps.  

Well, a first call for poll() may rise a thread that will prepare the buffers, 
and
return with 0 while there's no data available.

> The other constraint is to ensure when only poll()-ing for exception 
> conditions, not having significant IO side effects.
> 
> I'm pretty sure sleeping in a driver's poll() method, or having significant 
> side effects, is not ine the spirit of the POSIX select() and poll(), even if 
> the letter of POSIX says nothing about it.
> 
> The method I suggested to Hans is completely POSIX compliant for apps using 
> read() and select() and was checked against MythTV as having no bad side 
> effects.  (And by thought experiment doesn't break any sensible app using 
> nonblocking IO with select() and read().)
> 
> I did not do analysis for apps that use mmap(), which I guess is the current 
> concern.

The concern is that it is pointing that there are available data, even when 
there is an error.
This looks like a POSIX violation for me.

Cheers,
Mauro.
--
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

RE: [RFC] Media Controller Capture driver for DM365

[Hadli, Manjunath]

Laurent,
  Sorry for getting back late on this. I was also tied up. I am following it up 
with the patches.

-Manju

On Mon, May 02, 2011 at 03:36:23, Laurent Pinchart wrote:
> Hi Manjunath,
> 
> On Wednesday 27 April 2011 16:14:03 Hadli, Manjunath wrote:
> > Introduction
> > 
> > This is the proposal of the initial version of design and 
> > implementation of the DM365 VPFE (Video Port Front End) drivers using 
> > Media Controloler , the initial version which supports the following:
> > 1) dm365 vpfe
> > 2) ccdc,previewer,resizer,h3a,af blocks
> > 3) supports both continuous and single-shot modes
> > 4) supports user pointer exchange and memory mapped modes for buffer 
> > allocation
> > 
> > This driver bases its design on Laurent Pinchart's Media Controller 
> > Design whose patches for Media Controller and subdev enhancements form the 
> > base.
> > The driver also takes copious elements taken from Laurent Pinchart and 
> > others' OMAP ISP driver based on Media Controller. So thank you all 
> > the people who are responsible for the Media Controller and the OMAP 
> > ISP driver.
> 
> You're welcome.
> 
> > Also, the core functionality of the driver comes from the arago vpfe 
> > capture driver of which the CCDC capture was based on V4L2, with other 
> > drivers like Previwer, and Resizer.
> > 
> > The specification for DM365 can be found here:
> > dm365  vpfe: http://www.ti.com/litv/pdf/sprufg8c
> > 
> > The initial version of the  driver implementation can be found here:
> > 
> > http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h
> > =refs
> > /heads/mc_release
> 
> I'll try to review the code, but I got the DM644x V4L2 display driver on my 
> todo-list first :-)
> 
> > Driver Design: Main entities
> > 
> > The hardware modules for dm355,dm365 are mainly ipipe, ipipeif,isif. 
> > These hardware modules are generically exposed to the user level in 
> > the for of
> > dm6446 style modules. Mainly -
> > ccdc, previewer, resizer in addition to the other histogram and auto 
> > color/white balance correction and auto focus modules.
> 
> I'm curious, why do you name the modules CCDC and previewer in the code, when 
> they're called ISIF, IPIPEIF and IPIPE in the documentation ? That's quite 
> confusing.
The driver is intended to support Dm365, Dm355 and Dm6446. The three are 
similar and there are some internal differences. The counterparts for IPIPE in 
Dm6446 are known by names as CCDC , previewer etc and a good part of the world 
knows the driver by that name. So rather than changing the names, we decided to 
keep them as-is.
> 
> > 1)MT9P031 sensor  module for RAW capture
> > 2)TVP7002 decoder module for HD inputs 3)TVP514x decoder module for SD 
> > inputs 4)CCDC capture module 5)Previewer Module for Bayer to YUV 
> > conversion 6)Resizer Module for scaling
> > 
> > Connection for on-the-fly capture
> > -
> > Mt9P031 
> > -->CCDC--->Previewer(optional)--->Resizer(optional)--->Video
> > 
> > TVP7002 ---
> > 
> > TV514x  ---
> > 
> > File Organisation
> > -
> > 
> > main driver files
> > 
> > drivers/media/video/davinci/vpfe_capture.c
> > include/media/davinci/vpfe_capture.h
> > 
> > Instantiatiation of the v4l2 device, media device and all  subdevs 
> > from here.
> > 
> > video Interface files
> > -
> > drivers/media/video/davinci/vpfe_video.c
> > include/media/davinci/vpfe_video.h
> > 
> > Implements all the v4l2 video operations with a generic implementation 
> > for continuous and one shot mode.
> > 
> > subdev interface files
> > --
> > These file implement the subdev interface functionality for each of 
> > the subdev entities - mainly the entry points and their 
> > implementations in a IP generic way.
> > 
> > drivers/media/video/davinci/vpfe_ccdc.c
> > drivers/media/video/davinci/vpfe_previewer.c
> > drivers/media/video/davinci/vpfe_resizer.c
> > drivers/media/video/davinci/vpfe_af.c
> > drivers/media/video/davinci/vpfe_aew.c
> > drivers/media/video/mt9p031.c
> > drivers/media/video/tvp514x.c
> > drivers/media/video/tvp7002.c
> > drivers/media/video/ths7353.c
> > 
> > include/media/davinci/vpfe_ccdc.h
> > include/media/davinci/vpfe_previewer.h
> > include/media/davinci/vpfe_resizer.h
> > include/media/davinci/vpfe_af.h
> > include/media/davinci/vpfe_aew.h
> > include/media/tvp514x.h
> > drivers/media/video/tvp514x_regs.h
> > include/media/tvp7002.h
> > drivers/media/video/tvp7002_reg.h
> > 
> > core implementation files
> > -
> > These provide a core implementation routines for ccdc, ipipeif, 
> > ipipe,aew, af, resizer hardware modules.
> > 
> > drivers/media/video/davinci/dm365_ccdc.c
> > drivers/media/video/davinci/dm365_ipipe.c
> > drivers/media/video/davinci/dm365_def_para.c
> > drivers/media/video/davinci/dm365_ipipe_hw.c
> > drivers/media/video/davinci/dm3xx_ipipe.c
> > drivers/media/video/davin

Re: [RFCv3 PATCH 12/18] vb2_poll: don't start DMA, leave that to the first read().

[Andy Walls]

Mauro Carvalho Chehab  wrote:

>Em 28-06-2011 04:33, Hans Verkuil escreveu:
>> On Monday, June 27, 2011 23:52:37 Mauro Carvalho Chehab wrote:
>>> Em 07-06-2011 12:05, Hans Verkuil escreveu:
 From: Hans Verkuil 

 The vb2_poll function would start read-DMA if called without any
>streaming
 in progress. This unfortunately does not work if the application
>just wants
 to poll for exceptions. This information of what the application is
>polling
 for is sadly unavailable in the driver.

 Andy Walls suggested to just return POLLIN | POLLRDNORM and let the
>first
 call to read() start the DMA. This initial read() call will return
>EAGAIN
 since no actual data is available yet, but it does start the DMA.

 Applications must handle EAGAIN in any case since there can be
>other reasons
 for EAGAIN as well.

 Signed-off-by: Hans Verkuil 
 ---
  drivers/media/video/videobuf2-core.c |   17 +++--
  1 files changed, 3 insertions(+), 14 deletions(-)

 diff --git a/drivers/media/video/videobuf2-core.c
>b/drivers/media/video/videobuf2-core.c
 index 6ba1461..ad75c95 100644
 --- a/drivers/media/video/videobuf2-core.c
 +++ b/drivers/media/video/videobuf2-core.c
 @@ -1372,27 +1372,16 @@ static int __vb2_cleanup_fileio(struct
>vb2_queue *q);
  unsigned int vb2_poll(struct vb2_queue *q, struct file *file,
>poll_table *wait)
  {
unsigned long flags;
 -  unsigned int ret;
struct vb2_buffer *vb = NULL;
  
/*
 * Start file I/O emulator only if streaming API has not been
>used yet.
 */
if (q->num_buffers == 0 && q->fileio == NULL) {
 -  if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ)) {
 -  ret = __vb2_init_fileio(q, 1);
 -  if (ret)
 -  return POLLERR;
 -  }
 -  if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE)) {
 -  ret = __vb2_init_fileio(q, 0);
 -  if (ret)
 -  return POLLERR;
 -  /*
 -   * Write to OUTPUT queue can be done immediately.
 -   */
 +  if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ))
 +  return POLLIN | POLLRDNORM;
 +  if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE))
return POLLOUT | POLLWRNORM;
 -  }
}
>>>
>>> There is one behavior change on this patchset:  __vb2_init_fileio()
>checks for some
>>> troubles that may happen during device streaming initialization,
>returning POLLERR
>>> if there is a problem there.
>>>
>>> By moving this code to be called only at read, it means the poll()
>will not fail
>>> anymore, but the first read() will fail. The man page for read()
>doesn't tell that
>>> -EBUSY or -ENOMEM could happen there. The same happens with V4L2
>specs. So, it is
>>> clearly violating kernel ABI.
>>>
>>> NACK.
>> 
>> Actually, almost nothing changes in the ABI. It's counterintuitive,
>but
>> this is what happens:
>> 
>> 1) The poll() function in a driver does not actually return any error
>codes.
>> It never did. It returns a poll mask, which is expected to be POLLERR
>in case
>> of any error. All that it does is that select() returns if it waits
>for reading
>> or writing. Any actual error codes are never propagated. 
>
>Yes, but POLLERR will return error on the vb2 cases that return -EBUSY
>or -ENOMEM.
>This doesn't violate the ioctl ABI.
>
>> This means BTW that
>> our poll manual page is wrong (what a surprise), most of those error
>codes can
>> never be returned.
>
>True. The DocBook needs a fix. Posix describes it as:
>   http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html
>
>> 
>> 2) Suppose we try to start streaming in poll. If this works, then
>poll returns,
>> with POLLIN set, and the next read() will succeed (actually, it can
>return an
>> error as well, but for other error conditions in case of e.g.
>hardware errors).
>> 
>> The problem with this is of course that this will also start the
>streaming if
>> all we wanted to wait for was an exception. That's not what we want
>at all.
>> Ideally we could inspect in the driver what the caller wanted to wait
>for, but
>> that information is not available, unfortunately.
>> 
>> 3) The other case is that we try to start streaming in poll and it
>fails.
>> In that case any errors are lost and poll returns POLLERR (note that
>the poll(2)
>> manual page says that POLLERR is for output only, but clearly in the
>linux
>> kernel it is accepted both input and output).
>
>Posix doesn't impose such restriction.
>
>> But for the select() call this POLLERR information is lost as well
>and the
>> application will call read() anyway, which now will attempt to start
>the
>> streaming (again after poll() tried it t

[RFCv2 PATCH 13/13] v4l2-event.h: add overview documentation to the header.

[Hans Verkuil]

From: Hans Verkuil 

It's getting confusing who is linking to what, so add an overview at
the start of the header.

Signed-off-by: Hans Verkuil 
---
 include/media/v4l2-event.h |   34 ++
 1 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 7abeb39..5f14e88 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -29,6 +29,40 @@
 #include 
 #include 
 
+/*
+ * Overview:
+ *
+ * Events are subscribed per-filehandle. An event specification consists of a
+ * type and is optionally associated with an object identified through the
+ * 'id' field. So an event is uniquely identified by the (type, id) tuple.
+ *
+ * The v4l2-fh struct has a list of subscribed events. The 
v4l2_subscribed_event
+ * struct is added to that list, one for every subscribed event.
+ *
+ * Each v4l2_subscribed_event struct ends with an array of v4l2_kevent structs.
+ * This array (ringbuffer, really) is used to store any events raised by the
+ * driver. The v4l2_kevent struct links into the 'available' list of the
+ * v4l2_fh struct so VIDIOC_DQEVENT will know which event to dequeue first.
+ *
+ * Finally, if the event subscription is associated with a particular object
+ * such as a V4L2 control, then that object needs to know about that as well
+ * so that an event can be raised by that object. So the 'node' field can
+ * be used to link the v4l2_subscribed_event struct into a list of that
+ * object.
+ *
+ * So to summarize:
+ *
+ * struct v4l2_fh has two lists: one of the subscribed events, and one of the
+ * pending events.
+ *
+ * struct v4l2_subscribed_event has a ringbuffer of raised (pending) events of
+ * that particular type.
+ *
+ * If struct v4l2_subscribed_event is associated with a specific object, then
+ * that object will have an internal list of struct v4l2_subscribed_event so
+ * it knows who subscribed an event to that object.
+ */
+
 struct v4l2_fh;
 struct v4l2_subscribed_event;
 struct video_device;
-- 
1.7.1

--
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

[RFCv2 PATCH 12/13] v4l2-ctrls/v4l2-events: small coding style cleanups

[Hans Verkuil]

From: Hans Verkuil 

Thanks to Laurent Pinchart .

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c |2 +-
 drivers/media/video/v4l2-event.c |6 ++
 include/media/v4l2-ctrls.h   |1 -
 include/media/v4l2-event.h   |   34 +++---
 4 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 627a1e4..bc08f86 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -586,7 +586,7 @@ static void send_event(struct v4l2_fh *fh, struct v4l2_ctrl 
*ctrl, u32 changes)
struct v4l2_subscribed_event *sev;
 
if (list_empty(&ctrl->ev_subs))
-   return;
+   return;
fill_event(&ev, ctrl, changes);
 
list_for_each_entry(sev, &ctrl->ev_subs, node)
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index b1c19fc..53b190c 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -100,10 +100,9 @@ static struct v4l2_subscribed_event *v4l2_event_subscribed(
 
assert_spin_locked(&fh->vdev->fh_lock);
 
-   list_for_each_entry(sev, &fh->subscribed, list) {
+   list_for_each_entry(sev, &fh->subscribed, list)
if (sev->type == type && sev->id == id)
return sev;
-   }
 
return NULL;
 }
@@ -169,9 +168,8 @@ void v4l2_event_queue(struct video_device *vdev, const 
struct v4l2_event *ev)
 
spin_lock_irqsave(&vdev->fh_lock, flags);
 
-   list_for_each_entry(fh, &vdev->fh_list, list) {
+   list_for_each_entry(fh, &vdev->fh_list, list)
__v4l2_event_queue_fh(fh, ev, ×tamp);
-   }
 
spin_unlock_irqrestore(&vdev->fh_lock, flags);
 }
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 5fc3a2d..0a22209 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -31,7 +31,6 @@ struct v4l2_ctrl_helper;
 struct v4l2_ctrl;
 struct video_device;
 struct v4l2_subdev;
-struct v4l2_event_subscription;
 struct v4l2_subscribed_event;
 struct v4l2_fh;
 
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 6da793f..7abeb39 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -33,41 +33,45 @@ struct v4l2_fh;
 struct v4l2_subscribed_event;
 struct video_device;
 
+/** struct v4l2_kevent - Internal kernel event struct.
+  * @list: List node for the v4l2_fh->available list.
+  * @sev:  Pointer to parent v4l2_subscribed_event.
+  * @event:The event itself.
+  */
 struct v4l2_kevent {
-   /* list node for the v4l2_fh->available list */
struct list_headlist;
-   /* pointer to parent v4l2_subscribed_event */
struct v4l2_subscribed_event *sev;
-   /* event itself */
struct v4l2_event   event;
 };
 
+/** struct v4l2_subscribed_event - Internal struct representing a subscribed 
event.
+  * @list: List node for the v4l2_fh->subscribed list.
+  * @type: Event type.
+  * @id:   Associated object ID (e.g. control ID). 0 if there isn't any.
+  * @flags:Copy of v4l2_event_subscription->flags.
+  * @fh:   Filehandle that subscribed to this event.
+  * @node: List node that hooks into the object's event list (if there is 
one).
+  * @replace:  Optional callback that can replace event 'old' with event 'new'.
+  * @merge:Optional callback that can merge event 'old' into event 'new'.
+  * @elems:The number of elements in the events array.
+  * @first:The index of the events containing the oldest available event.
+  * @in_use:   The number of queued events.
+  * @events:   An array of @elems events.
+  */
 struct v4l2_subscribed_event {
-   /* list node for the v4l2_fh->subscribed list */
struct list_headlist;
-   /* event type */
u32 type;
-   /* associated object ID (e.g. control ID) */
u32 id;
-   /* copy of v4l2_event_subscription->flags */
u32 flags;
-   /* filehandle that subscribed to this event */
struct v4l2_fh  *fh;
-   /* list node that hooks into the object's event list (if there is one) 
*/
struct list_headnode;
-   /* Optional callback that can replace event 'old' with event 'new'. */
void(*replace)(struct v4l2_event *old,
   const struct v4l2_event *new);
-   /* Optional callback that can merge event 'old' into event 'new'. */
void(*merge)(const struct v4l2_event *old,
 struct v4l2_event *new);
-   /* the number of elements in the events array */
unsignedelems;
-   /* the index of the events containing the oldest available event */
unsigned   

[RFCv2 PATCH 11/13] DocBook: update V4L Event Interface section.

[Hans Verkuil]

From: Hans Verkuil 

Starting with v3.1 the V4L2 API provides certain guarantees with respect to
events. Document these.

Signed-off-by: Hans Verkuil 
---
 Documentation/DocBook/media/v4l/dev-event.xml  |   30 ---
 .../DocBook/media/v4l/vidioc-subscribe-event.xml   |   15 +++--
 2 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/dev-event.xml 
b/Documentation/DocBook/media/v4l/dev-event.xml
index be5a98f..f14ae3f 100644
--- a/Documentation/DocBook/media/v4l/dev-event.xml
+++ b/Documentation/DocBook/media/v4l/dev-event.xml
@@ -1,9 +1,10 @@
   Event Interface
 
-  The V4L2 event interface provides means for user to get
+  The V4L2 event interface provides a means for a user to get
   immediately notified on certain conditions taking place on a device.
   This might include start of frame or loss of signal events, for
-  example.
+  example. Changes in the value or state of a V4L2 control can also be
+  reported through events.
   
 
   To receive events, the events the user is interested in first must
@@ -15,12 +16,31 @@
 
   The event subscriptions and event queues are specific to file
   handles. Subscribing an event on one file handle does not affect
-  other file handles.
-  
+  other file handles.
 
   The information on dequeueable events is obtained by using select or
   poll system calls on video devices. The V4L2 events use POLLPRI events on
-  poll system call and exceptions on select system call.  
+  poll system call and exceptions on select system call.
+
+  Starting with kernel 3.1 certain guarantees can be given with
+  regards to events:
+   
+ Each subscribed event has its own internal dedicated event 
queue.
+This means that flooding of one event type will not interfere with other
+event types.
+   
+   
+ If the internal event queue for a particular subscribed event
+becomes full, then the oldest event in that queue will be dropped.
+   
+   
+ Where applicable, certain event types can ensure that the 
payload
+of the oldest event that is about to be dropped will be merged with the payload
+of the next oldest event. Thus ensuring that no information is lost, but only 
an
+intermediate step leading up to that information. See the documentation for the
+event you want to subscribe to whether this is applicable for that event or 
not.
+   
+  
 
   

[RFCv2 PATCH 10/13] v4l2-framework.txt: update v4l2_event section.

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 Documentation/video4linux/v4l2-framework.txt |   51 ++
 1 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/Documentation/video4linux/v4l2-framework.txt 
b/Documentation/video4linux/v4l2-framework.txt
index 312a0e2..f8dcabf 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -897,14 +897,38 @@ V4L2 events
 The V4L2 events provide a generic way to pass events to user space.
 The driver must use v4l2_fh to be able to support V4L2 events.
 
-Useful functions:
+Events are defined by a type and an optional ID. The ID may refer to a V4L2
+object such as a control ID. If unused, then the ID is 0.
+
+When the user subscribes to an event the driver will allocate a number of
+kevent structs for that event. So every (type, ID) event tuple will have
+its own set of kevent structs. This guarantees that if a driver is generating
+lots of events of one type in a short time, then that will not overwrite
+events of another type.
+
+But if you get more events of one type than the number of kevents that were
+reserved, then the oldest event will be dropped and the new one added.
+
+Furthermore, the internal struct v4l2_subscribed_event has merge() and
+replace() callbacks which drivers can set. These callbacks are called when
+a new event is raised and there is no more room. The replace() callback
+allows you to replace the payload of the old event with that of the new event,
+merging any relevant data from the old payload into the new payload that
+replaces it. It is called when this event type has only one kevent struct
+allocated. The merge() callback allows you to merge the oldest event payload
+into that of the second-oldest event payload. It is called when there are two
+or more kevent structs allocated.
 
-- v4l2_event_alloc()
+This way no status information is lost, just the intermediate steps leading
+up to that state.
 
-  To use events, the driver must allocate events for the file handle. By
-  calling the function more than once, the driver may assure that at least n
-  events in total have been allocated. The function may not be called in
-  atomic context.
+A good example of these replace/merge callbacks is in v4l2-event.c:
+ctrls_replace() and ctrls_merge() callbacks for the control event.
+
+Note: these callbacks can be called from interrupt context, so they must be
+fast.
+
+Useful functions:
 
 - v4l2_event_queue()
 
@@ -916,7 +940,9 @@ Useful functions:
 
   The video_device->ioctl_ops->vidioc_subscribe_event must check the driver
   is able to produce events with specified event id. Then it calls
-  v4l2_event_subscribe() to subscribe the event.
+  v4l2_event_subscribe() to subscribe the event. The last argument is the
+  size of the event queue for this event. If it is 0, then the framework
+  will fill in a default value (this depends on the event type).
 
 - v4l2_event_unsubscribe()
 
@@ -931,14 +957,8 @@ Useful functions:
 
   Returns the number of pending events. Useful when implementing poll.
 
-Drivers do not initialise events directly. The events are initialised
-through v4l2_fh_init() if video_device->ioctl_ops->vidioc_subscribe_event is
-non-NULL. This *MUST* be performed in the driver's
-v4l2_file_operations->open() handler.
-
 Events are delivered to user space through the poll system call. The driver
-can use v4l2_fh->events->wait wait_queue_head_t as the argument for
-poll_wait().
+can use v4l2_fh->wait (a wait_queue_head_t) as the argument for poll_wait().
 
 There are standard and private events. New standard events must use the
 smallest available event type. The drivers must allocate their events from
@@ -948,5 +968,4 @@ The first event type in the class is reserved for future 
use, so the first
 available event type is 'class base + 1'.
 
 An example on how the V4L2 events may be used can be found in the OMAP
-3 ISP driver available at http://gitorious.org/omap3camera> as of
-writing this.
+3 ISP driver (drivers/media/video/omap3isp).
-- 
1.7.1

--
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

[RFCv2 PATCH 09/13] v4l2-framework.txt: updated v4l2_fh_init documentation.

[Hans Verkuil]

From: Hans Verkuil 

v4l2_fh_init now returns void instead of int, updated the doc.

Signed-off-by: Hans Verkuil 
---
 Documentation/video4linux/v4l2-framework.txt |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/Documentation/video4linux/v4l2-framework.txt 
b/Documentation/video4linux/v4l2-framework.txt
index cf21f7a..312a0e2 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -817,11 +817,7 @@ int my_open(struct file *file)
 
...
 
-   ret = v4l2_fh_init(&my_fh->fh, vfd);
-   if (ret) {
-   kfree(my_fh);
-   return ret;
-   }
+   v4l2_fh_init(&my_fh->fh, vfd);
 
...
 
@@ -844,7 +840,7 @@ int my_release(struct file *file)
 
 Below is a short description of the v4l2_fh functions used:
 
-int v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
+void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
 
   Initialise the file handle. This *MUST* be performed in the driver's
   v4l2_file_operations->open() handler.
-- 
1.7.1

--
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

[RFCv2 PATCH 08/13] v4l2-ctrls: v4l2_ctrl_handler_setup code simplification

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 040d5c9..627a1e4 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1410,26 +1410,21 @@ int v4l2_ctrl_handler_setup(struct v4l2_ctrl_handler 
*hdl)
int i;
 
/* Skip if this control was already handled by a cluster. */
-   if (ctrl->done)
+   /* Skip button controls and read-only controls. */
+   if (ctrl->done || ctrl->type == V4L2_CTRL_TYPE_BUTTON ||
+   (ctrl->flags & V4L2_CTRL_FLAG_READ_ONLY))
continue;
 
for (i = 0; i < master->ncontrols; i++) {
if (master->cluster[i]) {
cur_to_new(master->cluster[i]);
master->cluster[i]->is_new = 1;
+   master->cluster[i]->done = true;
}
}
-
-   /* Skip button controls and read-only controls. */
-   if (ctrl->type == V4L2_CTRL_TYPE_BUTTON ||
-   (ctrl->flags & V4L2_CTRL_FLAG_READ_ONLY))
-   continue;
ret = call_op(master, s_ctrl);
if (ret)
break;
-   for (i = 0; i < master->ncontrols; i++)
-   if (master->cluster[i])
-   master->cluster[i]->done = true;
}
mutex_unlock(&hdl->lock);
return ret;
-- 
1.7.1

--
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

[RFCv2 PATCH 07/13] v4l2-ctrls: split try_or_set_ext_ctrls()

[Hans Verkuil]

From: Hans Verkuil 

Split try_or_set_ext_ctrls() into a validate_ctrls() part ('Phase 1')
and merge the second part ('Phase 2') into try_set_ext_ctrls().

This makes a lot more sense and it also does the validation before
trying to try/set the controls.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c |   88 ++
 1 files changed, 41 insertions(+), 47 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 8fe4e47..040d5c9 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1800,8 +1800,8 @@ EXPORT_SYMBOL(v4l2_ctrl_g_ctrl);
 /* Core function that calls try/s_ctrl and ensures that the new value is
copied to the current value on a set.
Must be called with ctrl->handler->lock held. */
-static int try_or_set_control_cluster(struct v4l2_fh *fh,
-   struct v4l2_ctrl *master, bool set)
+static int try_or_set_cluster(struct v4l2_fh *fh,
+ struct v4l2_ctrl *master, bool set)
 {
bool update_flag;
int ret;
@@ -1843,23 +1843,18 @@ static int try_or_set_control_cluster(struct v4l2_fh 
*fh,
return 0;
 }
 
-/* Try or set controls. */
-static int try_or_set_ext_ctrls(struct v4l2_fh *fh,
-   struct v4l2_ctrl_handler *hdl,
-   struct v4l2_ext_controls *cs,
-   struct v4l2_ctrl_helper *helpers,
-   bool set)
+/* Validate controls. */
+static int validate_ctrls(struct v4l2_ext_controls *cs,
+ struct v4l2_ctrl_helper *helpers, bool set)
 {
-   unsigned i, j;
+   unsigned i;
int ret = 0;
 
-   /* Phase 1: validation */
cs->error_idx = cs->count;
for (i = 0; i < cs->count; i++) {
struct v4l2_ctrl *ctrl = helpers[i].ctrl;
 
-   if (!set)
-   cs->error_idx = i;
+   cs->error_idx = i;
 
if (ctrl->flags & V4L2_CTRL_FLAG_READ_ONLY)
return -EACCES;
@@ -1875,8 +1870,38 @@ static int try_or_set_ext_ctrls(struct v4l2_fh *fh,
if (ret)
return ret;
}
+   return 0;
+}
+
+/* Try or try-and-set controls */
+static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
+struct v4l2_ext_controls *cs,
+bool set)
+{
+   struct v4l2_ctrl_helper helper[4];
+   struct v4l2_ctrl_helper *helpers = helper;
+   unsigned i, j;
+   int ret;
+
+   cs->error_idx = cs->count;
+   cs->ctrl_class = V4L2_CTRL_ID2CLASS(cs->ctrl_class);
+
+   if (hdl == NULL)
+   return -EINVAL;
+
+   if (cs->count == 0)
+   return class_check(hdl, cs->ctrl_class);
 
-   /* Phase 2: set/try controls */
+   if (cs->count > ARRAY_SIZE(helper)) {
+   helpers = kmalloc(sizeof(helper[0]) * cs->count, GFP_KERNEL);
+   if (!helpers)
+   return -ENOMEM;
+   }
+   ret = prepare_ext_ctrls(hdl, cs, helpers);
+   if (!ret)
+   ret = validate_ctrls(cs, helpers, set);
+   if (ret && set)
+   cs->error_idx = cs->count;
for (i = 0; !ret && i < cs->count; i++) {
struct v4l2_ctrl *master;
u32 idx = i;
@@ -1901,50 +1926,19 @@ static int try_or_set_ext_ctrls(struct v4l2_fh *fh,
} while (!ret && idx);
 
if (!ret)
-   ret = try_or_set_control_cluster(fh, master, set);
+   ret = try_or_set_cluster(fh, master, set);
 
/* Copy the new values back to userspace. */
if (!ret) {
idx = i;
do {
ret = user_to_new(cs->controls + idx,
- helpers[idx].ctrl);
+   helpers[idx].ctrl);
idx = helpers[idx].next;
} while (!ret && idx);
}
v4l2_ctrl_unlock(master);
}
-   return ret;
-}
-
-/* Try or try-and-set controls */
-static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
-struct v4l2_ext_controls *cs,
-bool set)
-{
-   struct v4l2_ctrl_helper helper[4];
-   struct v4l2_ctrl_helper *helpers = helper;
-   int ret;
-
-   cs->error_idx = cs->count;
-   cs->ctrl_class = V4L2_CTRL_ID2CLASS(cs->ctrl_class);
-
-   if (hdl == NULL)
-   return -EINVAL;
-
-   if (cs->count == 0)
-   return class_check(hdl, cs->ctrl_class);
-
-   if (cs->count > ARRAY_SIZE(helper)) {
-   helpers = kmalloc(sizeof(helper[0]) * cs->c

[RFCv2 PATCH 05/13] v4l2-ctrls: don't initially set CH_VALUE for write-only controls

[Hans Verkuil]

From: Hans Verkuil 

When sending the SEND_INITIAL event for write-only controls the
V4L2_EVENT_CTRL_CH_VALUE flag should not be set. It's meaningless.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 63a44fd..1b0422e 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -2032,9 +2032,11 @@ void v4l2_ctrl_add_event(struct v4l2_ctrl *ctrl,
if (ctrl->type != V4L2_CTRL_TYPE_CTRL_CLASS &&
(sev->flags & V4L2_EVENT_SUB_FL_SEND_INITIAL)) {
struct v4l2_event ev;
+   u32 changes = V4L2_EVENT_CTRL_CH_FLAGS;
 
-   fill_event(&ev, ctrl, V4L2_EVENT_CTRL_CH_VALUE |
-   V4L2_EVENT_CTRL_CH_FLAGS);
+   if (!(ctrl->flags & V4L2_CTRL_FLAG_WRITE_ONLY))
+   changes |= V4L2_EVENT_CTRL_CH_VALUE;
+   fill_event(&ev, ctrl, changes);
v4l2_event_queue_fh(sev->fh, &ev);
}
v4l2_ctrl_unlock(ctrl);
-- 
1.7.1

--
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

[RFCv2 PATCH 06/13] v4l2-ctrls: improve discovery of controls of the same cluster

[Hans Verkuil]

From: Hans Verkuil 

The implementation of VIDIOC_G/S/TRY_EXT_CTRLS in the control framework has
to figure out which controls in the control list belong to the same cluster.
Since controls belonging to the same cluster need to be handled as a unit,
this is important information.

It did that by going over the controls in the list and for each control that
belonged to a multi-control cluster it would walk the remainder of the list
to try and find controls that belong to that same cluster.

This approach has two disadvantages:

1) it was a potentially quadratic algorithm (although highly unlikely that
it would ever be that bad in practice).
2) it took place with the control handler's lock held.

Since we want to make it possible in the future to change control values
from interrupt context, doing a lot of work while holding a lock is not a
good idea.

In the new code the algorithm is no longer quadratic but linear in the
number of controls in the list. Also, it now can be done beforehand.

Another change that was made was to so the try and set at the same time.
Before when S_TRY_EXT_CTRLS was called it would 'try' the controls first,
and then it would 'set' them. The idea was that any 'try' errors would
prevent the 'set' from happening, thus avoiding having partially set
control lists.

However, this caused more problems than it solved because between the 'try'
and the 'set' changes might have happened, so it had to try a second time,
and since actual controls with a try_ctrl op are very rare (and those that
we have just adjust values and do not return an error), I've decided to
drop that two-stage approach and just combine try and set.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c |  279 +++--
 include/media/v4l2-ctrls.h   |3 +
 2 files changed, 146 insertions(+), 136 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 1b0422e..8fe4e47 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -32,12 +32,14 @@
(has_op(master, op) ? master->ops->op(master) : 0)
 
 /* Internal temporary helper struct, one for each v4l2_ext_control */
-struct ctrl_helper {
+struct v4l2_ctrl_helper {
+   /* Pointer to the control reference of the master control */
+   struct v4l2_ctrl_ref *mref;
/* The control corresponding to the v4l2_ext_control ID field. */
struct v4l2_ctrl *ctrl;
-   /* Used internally to mark whether this control was already
-  processed. */
-   bool handled;
+   /* v4l2_ext_control index of the next control belonging to the
+  same cluster, or 0 if there isn't any. */
+   u32 next;
 };
 
 /* Small helper function to determine if the autocluster is set to manual
@@ -678,20 +680,6 @@ static int new_to_user(struct v4l2_ext_control *c,
return 0;
 }
 
-static int ctrl_to_user(struct v4l2_ext_control *c,
-  struct v4l2_ctrl *ctrl)
-{
-   if (ctrl->is_volatile)
-   return new_to_user(c, ctrl);
-   return cur_to_user(c, ctrl);
-}
-
-static int ctrl_is_volatile(struct v4l2_ext_control *c,
-  struct v4l2_ctrl *ctrl)
-{
-   return ctrl->is_volatile;
-}
-
 /* Copy the new value to the current value. */
 static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl,
bool update_inactive)
@@ -779,13 +767,11 @@ static int cluster_changed(struct v4l2_ctrl *master)
return diff;
 }
 
-/* Validate a new control */
-static int validate_new(struct v4l2_ctrl *ctrl)
+/* Validate integer-type control */
+static int validate_new_int(const struct v4l2_ctrl *ctrl, s32 *pval)
 {
-   s32 val = ctrl->val;
-   char *s = ctrl->string;
+   s32 val = *pval;
u32 offset;
-   size_t len;
 
switch (ctrl->type) {
case V4L2_CTRL_TYPE_INTEGER:
@@ -798,11 +784,11 @@ static int validate_new(struct v4l2_ctrl *ctrl)
offset = val - ctrl->minimum;
offset = ctrl->step * (offset / ctrl->step);
val = ctrl->minimum + offset;
-   ctrl->val = val;
+   *pval = val;
return 0;
 
case V4L2_CTRL_TYPE_BOOLEAN:
-   ctrl->val = !!ctrl->val;
+   *pval = !!val;
return 0;
 
case V4L2_CTRL_TYPE_MENU:
@@ -815,9 +801,28 @@ static int validate_new(struct v4l2_ctrl *ctrl)
 
case V4L2_CTRL_TYPE_BUTTON:
case V4L2_CTRL_TYPE_CTRL_CLASS:
-   ctrl->val64 = 0;
+   *pval = 0;
return 0;
 
+   default:
+   return -EINVAL;
+   }
+}
+
+/* Validate a new control */
+static int validate_new(const struct v4l2_ctrl *ctrl, struct v4l2_ext_control 
*c)
+{
+   char *s = c->string;
+   size_t len;
+
+   switch (ctrl->type) {
+   case V4L2_CTRL_TYPE_INTEGER:
+   case V4L2_CTRL_TYPE_BOOLEAN

[RFCv2 PATCH 04/13] v4l2-event: add optional merge and replace callbacks

[Hans Verkuil]

From: Hans Verkuil 

When the event queue for a subscribed event is full, then the oldest
event is dropped. It would be nice if the contents of that oldest
event could be merged with the next-oldest. That way no information is
lost, only intermediate steps are lost.

This patch adds optional replace() (called when only one kevent was allocated)
and merge() (called when more than one kevent was allocated) callbacks that
will be called to do this job.

These two callbacks are implemented for the V4L2_EVENT_CTRL event.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-event.c |   31 ++-
 include/media/v4l2-event.h   |6 ++
 2 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index 9e325dd..b1c19fc 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -113,6 +113,7 @@ static void __v4l2_event_queue_fh(struct v4l2_fh *fh, const 
struct v4l2_event *e
 {
struct v4l2_subscribed_event *sev;
struct v4l2_kevent *kev;
+   bool copy_payload = true;
 
/* Are we subscribed? */
sev = v4l2_event_subscribed(fh, ev->type, ev->id);
@@ -130,12 +131,23 @@ static void __v4l2_event_queue_fh(struct v4l2_fh *fh, 
const struct v4l2_event *e
sev->in_use--;
sev->first = sev_pos(sev, 1);
fh->navailable--;
+   if (sev->elems == 1) {
+   if (sev->replace) {
+   sev->replace(&kev->event, ev);
+   copy_payload = false;
+   }
+   } else if (sev->merge) {
+   struct v4l2_kevent *second_oldest =
+   sev->events + sev_pos(sev, 0);
+   sev->merge(&kev->event, &second_oldest->event);
+   }
}
 
/* Take one and fill it. */
kev = sev->events + sev_pos(sev, sev->in_use);
kev->event.type = ev->type;
-   kev->event.u = ev->u;
+   if (copy_payload)
+   kev->event.u = ev->u;
kev->event.id = ev->id;
kev->event.timestamp = *ts;
kev->event.sequence = fh->sequence;
@@ -184,6 +196,19 @@ int v4l2_event_pending(struct v4l2_fh *fh)
 }
 EXPORT_SYMBOL_GPL(v4l2_event_pending);
 
+static void ctrls_replace(struct v4l2_event *old, const struct v4l2_event *new)
+{
+   u32 old_changes = old->u.ctrl.changes;
+
+   old->u.ctrl = new->u.ctrl;
+   old->u.ctrl.changes |= old_changes;
+}
+
+static void ctrls_merge(const struct v4l2_event *old, struct v4l2_event *new)
+{
+   new->u.ctrl.changes |= old->u.ctrl.changes;
+}
+
 int v4l2_event_subscribe(struct v4l2_fh *fh,
 struct v4l2_event_subscription *sub, unsigned elems)
 {
@@ -210,6 +235,10 @@ int v4l2_event_subscribe(struct v4l2_fh *fh,
sev->flags = sub->flags;
sev->fh = fh;
sev->elems = elems;
+   if (ctrl) {
+   sev->replace = ctrls_replace;
+   sev->merge = ctrls_merge;
+   }
 
spin_lock_irqsave(&fh->vdev->fh_lock, flags);
found_ev = v4l2_event_subscribed(fh, sub->type, sub->id);
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 8d681e5..6da793f 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -55,6 +55,12 @@ struct v4l2_subscribed_event {
struct v4l2_fh  *fh;
/* list node that hooks into the object's event list (if there is one) 
*/
struct list_headnode;
+   /* Optional callback that can replace event 'old' with event 'new'. */
+   void(*replace)(struct v4l2_event *old,
+  const struct v4l2_event *new);
+   /* Optional callback that can merge event 'old' into event 'new'. */
+   void(*merge)(const struct v4l2_event *old,
+struct v4l2_event *new);
/* the number of elements in the events array */
unsignedelems;
/* the index of the events containing the oldest available event */
-- 
1.7.1

--
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

[RFCv2 PATCH 03/13] v4l2-event/ctrls/fh: allocate events per fh and per type instead of just per-fh

[Hans Verkuil]

From: Hans Verkuil 

The driver had to decide how many events to allocate when the v4l2_fh struct
was created. It was possible to add more events afterwards, but there was no
way to ensure that you wouldn't miss important events if the event queue
would fill up for that filehandle.

In addition, once there were no more free events, any new events were simply
dropped on the floor.

For the control event in particular this made life very difficult since
control status/value changes could just be missed if the number of allocated
events and the speed at which the application read events was too low to keep
up with the number of generated events. The application would have no idea
what the latest state was for a control since it could have missed the latest
control change.

So this patch makes some major changes in how events are allocated. Instead
of allocating events per-filehandle they are now allocated when subscribing an
event. So for that particular event type N events (determined by the driver)
are allocated. Those events are reserved for that particular event type.
This ensures that you will not miss events for a particular type altogether.

In addition, if there are N events in use and a new event is raised, then
the oldest event is dropped and the new one is added. So the latest event
is always available.

This can be further improved by adding the ability to merge the state of
two events together, ensuring that no data is lost at all. This will be
added in the next patch.

This also makes it possible to allow the user to determine the number of
events that will be allocated. This is not implemented at the moment, but
would be trivial.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/ivtv/ivtv-fileops.c |4 --
 drivers/media/video/ivtv/ivtv-ioctl.c   |4 +-
 drivers/media/video/omap3isp/ispccdc.c  |3 +-
 drivers/media/video/omap3isp/ispstat.c  |3 +-
 drivers/media/video/v4l2-ctrls.c|   18 --
 drivers/media/video/v4l2-event.c|   88 ---
 drivers/media/video/v4l2-fh.c   |4 +-
 drivers/media/video/v4l2-subdev.c   |7 ---
 drivers/media/video/vivi.c  |2 +-
 drivers/usb/gadget/uvc_v4l2.c   |   12 +
 include/media/v4l2-ctrls.h  |   19 ---
 include/media/v4l2-event.h  |   18 +-
 include/media/v4l2-fh.h |2 -
 include/media/v4l2-subdev.h |2 -
 14 files changed, 54 insertions(+), 132 deletions(-)

diff --git a/drivers/media/video/ivtv/ivtv-fileops.c 
b/drivers/media/video/ivtv/ivtv-fileops.c
index e507766..5796262 100644
--- a/drivers/media/video/ivtv/ivtv-fileops.c
+++ b/drivers/media/video/ivtv/ivtv-fileops.c
@@ -957,10 +957,6 @@ static int ivtv_serialized_open(struct ivtv_stream *s, 
struct file *filp)
return -ENOMEM;
}
v4l2_fh_init(&item->fh, s->vdev);
-   if (s->type == IVTV_DEC_STREAM_TYPE_YUV ||
-   s->type == IVTV_DEC_STREAM_TYPE_MPG) {
-   res = v4l2_event_alloc(&item->fh, 60);
-   }
if (res < 0) {
v4l2_fh_exit(&item->fh);
kfree(item);
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c 
b/drivers/media/video/ivtv/ivtv-ioctl.c
index a81b4be..99b2bdc 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -1444,13 +1444,11 @@ static int ivtv_subscribe_event(struct v4l2_fh *fh, 
struct v4l2_event_subscripti
switch (sub->type) {
case V4L2_EVENT_VSYNC:
case V4L2_EVENT_EOS:
-   break;
case V4L2_EVENT_CTRL:
-   return v4l2_ctrl_subscribe_fh(fh, sub, 0);
+   return v4l2_event_subscribe(fh, sub, 0);
default:
return -EINVAL;
}
-   return v4l2_event_subscribe(fh, sub);
 }
 
 static int ivtv_log_status(struct file *file, void *fh)
diff --git a/drivers/media/video/omap3isp/ispccdc.c 
b/drivers/media/video/omap3isp/ispccdc.c
index 39d501b..6766247 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -1691,7 +1691,7 @@ static int ccdc_subscribe_event(struct v4l2_subdev *sd, 
struct v4l2_fh *fh,
if (sub->type != V4L2_EVENT_OMAP3ISP_HS_VS)
return -EINVAL;
 
-   return v4l2_event_subscribe(fh, sub);
+   return v4l2_event_subscribe(fh, sub, OMAP3ISP_CCDC_NEVENTS);
 }
 
 static int ccdc_unsubscribe_event(struct v4l2_subdev *sd, struct v4l2_fh *fh,
@@ -2162,7 +2162,6 @@ static int ccdc_init_entities(struct isp_ccdc_device 
*ccdc)
sd->grp_id = 1 << 16;   /* group ID for isp subdevs */
v4l2_set_subdevdata(sd, ccdc);
sd->flags |= V4L2_SUBDEV_FL_HAS_EVENTS | V4L2_SUBDEV_FL_HAS_DEVNODE;
-   sd->nevents = OMAP3ISP_CCDC_NEVENTS;
 
pads[CCDC_PAD_SINK].flags = MEDIA_PAD_FL_SINK;
pads[CCDC_PAD_SOURCE_VP].flags = MEDIA_PAD_FL_SOURCE;
diff --git a/drivers/media/video/omap3isp/ispstat.c 
b/driv

[RFCv2 PATCH 02/13] v4l2-ctrls/event: remove struct v4l2_ctrl_fh, instead use v4l2_subscribed_event

[Hans Verkuil]

From: Hans Verkuil 

The v4l2_ctrl_fh struct connected v4l2_ctrl with v4l2_fh so the control
would know which filehandles subscribed to it. However, it is much easier
to use struct v4l2_subscribed_event directly for that and get rid of that
intermediate struct.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c |   50 ++---
 drivers/media/video/v4l2-event.c |   34 +
 include/media/v4l2-ctrls.h   |   17 +---
 include/media/v4l2-event.h   |9 +++
 4 files changed, 47 insertions(+), 63 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index f581910..079f952 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -581,15 +581,15 @@ static void fill_event(struct v4l2_event *ev, struct 
v4l2_ctrl *ctrl, u32 change
 static void send_event(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, u32 changes)
 {
struct v4l2_event ev;
-   struct v4l2_ctrl_fh *pos;
+   struct v4l2_subscribed_event *sev;
 
-   if (list_empty(&ctrl->fhs))
+   if (list_empty(&ctrl->ev_subs))
return;
fill_event(&ev, ctrl, changes);
 
-   list_for_each_entry(pos, &ctrl->fhs, node)
-   if (pos->fh != fh)
-   v4l2_event_queue_fh(pos->fh, &ev);
+   list_for_each_entry(sev, &ctrl->ev_subs, node)
+   if (sev->fh && sev->fh != fh)
+   v4l2_event_queue_fh(sev->fh, &ev);
 }
 
 /* Helper function: copy the current control value back to the caller */
@@ -867,7 +867,7 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
 {
struct v4l2_ctrl_ref *ref, *next_ref;
struct v4l2_ctrl *ctrl, *next_ctrl;
-   struct v4l2_ctrl_fh *ctrl_fh, *next_ctrl_fh;
+   struct v4l2_subscribed_event *sev, *next_sev;
 
if (hdl == NULL || hdl->buckets == NULL)
return;
@@ -881,10 +881,8 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
/* Free all controls owned by the handler */
list_for_each_entry_safe(ctrl, next_ctrl, &hdl->ctrls, node) {
list_del(&ctrl->node);
-   list_for_each_entry_safe(ctrl_fh, next_ctrl_fh, &ctrl->fhs, 
node) {
-   list_del(&ctrl_fh->node);
-   kfree(ctrl_fh);
-   }
+   list_for_each_entry_safe(sev, next_sev, &ctrl->ev_subs, node)
+   list_del(&sev->node);
kfree(ctrl);
}
kfree(hdl->buckets);
@@ -1084,7 +1082,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct 
v4l2_ctrl_handler *hdl,
}
 
INIT_LIST_HEAD(&ctrl->node);
-   INIT_LIST_HEAD(&ctrl->fhs);
+   INIT_LIST_HEAD(&ctrl->ev_subs);
ctrl->handler = hdl;
ctrl->ops = ops;
ctrl->id = id;
@@ -2027,41 +2025,31 @@ int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val)
 }
 EXPORT_SYMBOL(v4l2_ctrl_s_ctrl);
 
-void v4l2_ctrl_add_fh(struct v4l2_ctrl_handler *hdl,
-   struct v4l2_ctrl_fh *ctrl_fh,
-   struct v4l2_event_subscription *sub)
+void v4l2_ctrl_add_event(struct v4l2_ctrl *ctrl,
+   struct v4l2_subscribed_event *sev)
 {
-   struct v4l2_ctrl *ctrl = v4l2_ctrl_find(hdl, sub->id);
-
v4l2_ctrl_lock(ctrl);
-   list_add_tail(&ctrl_fh->node, &ctrl->fhs);
+   list_add_tail(&sev->node, &ctrl->ev_subs);
if (ctrl->type != V4L2_CTRL_TYPE_CTRL_CLASS &&
-   (sub->flags & V4L2_EVENT_SUB_FL_SEND_INITIAL)) {
+   (sev->flags & V4L2_EVENT_SUB_FL_SEND_INITIAL)) {
struct v4l2_event ev;
 
fill_event(&ev, ctrl, V4L2_EVENT_CTRL_CH_VALUE |
V4L2_EVENT_CTRL_CH_FLAGS);
-   v4l2_event_queue_fh(ctrl_fh->fh, &ev);
+   v4l2_event_queue_fh(sev->fh, &ev);
}
v4l2_ctrl_unlock(ctrl);
 }
-EXPORT_SYMBOL(v4l2_ctrl_add_fh);
+EXPORT_SYMBOL(v4l2_ctrl_add_event);
 
-void v4l2_ctrl_del_fh(struct v4l2_ctrl *ctrl, struct v4l2_fh *fh)
+void v4l2_ctrl_del_event(struct v4l2_ctrl *ctrl,
+   struct v4l2_subscribed_event *sev)
 {
-   struct v4l2_ctrl_fh *pos;
-
v4l2_ctrl_lock(ctrl);
-   list_for_each_entry(pos, &ctrl->fhs, node) {
-   if (pos->fh == fh) {
-   list_del(&pos->node);
-   kfree(pos);
-   break;
-   }
-   }
+   list_del(&sev->node);
v4l2_ctrl_unlock(ctrl);
 }
-EXPORT_SYMBOL(v4l2_ctrl_del_fh);
+EXPORT_SYMBOL(v4l2_ctrl_del_event);
 
 int v4l2_ctrl_subscribe_fh(struct v4l2_fh *fh,
struct v4l2_event_subscription *sub, unsigned n)
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index 70fa82d..dc68f60 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -213,7 +213,6 @@ int v4l2

[RFCv2 PATCH 01/13] v4l2-events/fh: merge v4l2_events into v4l2_fh

[Hans Verkuil]

From: Hans Verkuil 

Drivers that supported events used to be rare, but now that controls can also
raise events this will become much more common since almost all drivers have
controls.

This means that keeping struct v4l2_events as a separate struct make no more
sense. Merging it into struct v4l2_fh simplifies things substantially as it
is now an integral part of the filehandle struct.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/ivtv/ivtv-fileops.c |6 +-
 drivers/media/video/v4l2-ctrls.c|2 -
 drivers/media/video/v4l2-event.c|   93 --
 drivers/media/video/v4l2-fh.c   |   17 ++
 drivers/media/video/v4l2-subdev.c   |   10 +---
 drivers/media/video/vivi.c  |2 +-
 drivers/usb/gadget/uvc_v4l2.c   |   10 +---
 include/media/v4l2-event.h  |   11 
 include/media/v4l2-fh.h |   13 +++-
 9 files changed, 49 insertions(+), 115 deletions(-)

diff --git a/drivers/media/video/ivtv/ivtv-fileops.c 
b/drivers/media/video/ivtv/ivtv-fileops.c
index 75c0354..e507766 100644
--- a/drivers/media/video/ivtv/ivtv-fileops.c
+++ b/drivers/media/video/ivtv/ivtv-fileops.c
@@ -722,8 +722,8 @@ unsigned int ivtv_v4l2_dec_poll(struct file *filp, 
poll_table *wait)
 
/* If there are subscribed events, then only use the new event
   API instead of the old video.h based API. */
-   if (!list_empty(&id->fh.events->subscribed)) {
-   poll_wait(filp, &id->fh.events->wait, wait);
+   if (!list_empty(&id->fh.subscribed)) {
+   poll_wait(filp, &id->fh.wait, wait);
/* Turn off the old-style vsync events */
clear_bit(IVTV_F_I_EV_VSYNC_ENABLED, &itv->i_flags);
if (v4l2_event_pending(&id->fh))
@@ -761,7 +761,7 @@ unsigned int ivtv_v4l2_enc_poll(struct file *filp, 
poll_table * wait)
if (v4l2_event_pending(&id->fh))
res |= POLLPRI;
else
-   poll_wait(filp, &id->fh.events->wait, wait);
+   poll_wait(filp, &id->fh.wait, wait);
 
if (s->q_full.length || s->q_io.length)
return res | POLLIN | POLLRDNORM;
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index d084cea..f581910 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -2069,8 +2069,6 @@ int v4l2_ctrl_subscribe_fh(struct v4l2_fh *fh,
struct v4l2_ctrl_handler *hdl = fh->ctrl_handler;
int ret = 0;
 
-   if (!fh->events)
-   ret = v4l2_event_init(fh);
if (!ret) {
if (hdl->nr_of_refs * 2 > n)
n = hdl->nr_of_refs * 2;
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index 670f2f8..70fa82d 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -32,35 +32,11 @@
 
 static void v4l2_event_unsubscribe_all(struct v4l2_fh *fh);
 
-int v4l2_event_init(struct v4l2_fh *fh)
-{
-   fh->events = kzalloc(sizeof(*fh->events), GFP_KERNEL);
-   if (fh->events == NULL)
-   return -ENOMEM;
-
-   init_waitqueue_head(&fh->events->wait);
-
-   INIT_LIST_HEAD(&fh->events->free);
-   INIT_LIST_HEAD(&fh->events->available);
-   INIT_LIST_HEAD(&fh->events->subscribed);
-
-   fh->events->sequence = -1;
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(v4l2_event_init);
-
 int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
 {
-   struct v4l2_events *events = fh->events;
unsigned long flags;
 
-   if (!events) {
-   WARN_ON(1);
-   return -ENOMEM;
-   }
-
-   while (events->nallocated < n) {
+   while (fh->nallocated < n) {
struct v4l2_kevent *kev;
 
kev = kzalloc(sizeof(*kev), GFP_KERNEL);
@@ -68,8 +44,8 @@ int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
return -ENOMEM;
 
spin_lock_irqsave(&fh->vdev->fh_lock, flags);
-   list_add_tail(&kev->list, &events->free);
-   events->nallocated++;
+   list_add_tail(&kev->list, &fh->free);
+   fh->nallocated++;
spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
}
 
@@ -87,40 +63,31 @@ EXPORT_SYMBOL_GPL(v4l2_event_alloc);
 
 void v4l2_event_free(struct v4l2_fh *fh)
 {
-   struct v4l2_events *events = fh->events;
-
-   if (!events)
-   return;
-
-   list_kfree(&events->free, struct v4l2_kevent, list);
-   list_kfree(&events->available, struct v4l2_kevent, list);
+   list_kfree(&fh->free, struct v4l2_kevent, list);
+   list_kfree(&fh->available, struct v4l2_kevent, list);
v4l2_event_unsubscribe_all(fh);
-
-   kfree(events);
-   fh->events = NULL;
 }
 EXPORT_SYMBOL_GPL(v4l2_event_free);
 
 static int __v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event)
 {
-   struct v4l2_events

[RFCv2 PATCH 0/13] Allocate events per-event-type, v4l2-ctrls cleanup

[Hans Verkuil]

This is the second version of this patch series.

The only real change is in patch 4/13: the original merge callback has been
replaced with separate replace and merge callbacks. The original version
was hard to understand and had const issues as well.

The other changes are all documentation updates and small code cleanup
changes in the last five patches.

The original text from RFCv1 follows:

This patch series consists of two parts: the first four patches change the
way events are allocated and what to do when the event queue is full.

These first four patches are the most important ones to review. The big
change is that event allocation now happens when subscribing an event.
So you not only specify which event you want to subscribe to for a particular
filehandle, but also how many events should be reserved for that event type.
Currently the driver specifies the number of events to allocate, but later
this can be something that the application might want to set manually.

This ensures that for each event type you will never entirely miss all events
of a particular type. Currently this is a real possibility.

The other change is that instead of dropping the new event if there is no more
space available, the oldest event is dropped. This ensures that you get at
least the latest state. And optionally a merge function can be provided that
merges information of two events into one. This allows the control event to
require just one event: if a new event is raised, then the new and old one
can be merged and all state is preserved. Only the intermediate steps are
no longer available. This makes for very good behavior of events and is IMHO
a requirement for using the control event in a real production environment.

The second four patches reorganize the way extended controls are processed
in the control framework. This is the first step towards allowing control
changes from within interrupt handlers. The main purpose is to move as much
code as possible out of the critical sections. This reduces the size of
those sections, making it easier to eventually switch to spinlocks for
certain kinds of controls.

It's lots of internal churn, so it's probably not easy to review. There are
no real functional changes, however.

Regards,

Hans

--
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

Re: [RFCv3 PATCH 12/18] vb2_poll: don't start DMA, leave that to the first read().

[Mauro Carvalho Chehab]

Em 28-06-2011 04:33, Hans Verkuil escreveu:
> On Monday, June 27, 2011 23:52:37 Mauro Carvalho Chehab wrote:
>> Em 07-06-2011 12:05, Hans Verkuil escreveu:
>>> From: Hans Verkuil 
>>>
>>> The vb2_poll function would start read-DMA if called without any streaming
>>> in progress. This unfortunately does not work if the application just wants
>>> to poll for exceptions. This information of what the application is polling
>>> for is sadly unavailable in the driver.
>>>
>>> Andy Walls suggested to just return POLLIN | POLLRDNORM and let the first
>>> call to read() start the DMA. This initial read() call will return EAGAIN
>>> since no actual data is available yet, but it does start the DMA.
>>>
>>> Applications must handle EAGAIN in any case since there can be other reasons
>>> for EAGAIN as well.
>>>
>>> Signed-off-by: Hans Verkuil 
>>> ---
>>>  drivers/media/video/videobuf2-core.c |   17 +++--
>>>  1 files changed, 3 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/media/video/videobuf2-core.c 
>>> b/drivers/media/video/videobuf2-core.c
>>> index 6ba1461..ad75c95 100644
>>> --- a/drivers/media/video/videobuf2-core.c
>>> +++ b/drivers/media/video/videobuf2-core.c
>>> @@ -1372,27 +1372,16 @@ static int __vb2_cleanup_fileio(struct vb2_queue 
>>> *q);
>>>  unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table 
>>> *wait)
>>>  {
>>> unsigned long flags;
>>> -   unsigned int ret;
>>> struct vb2_buffer *vb = NULL;
>>>  
>>> /*
>>>  * Start file I/O emulator only if streaming API has not been used yet.
>>>  */
>>> if (q->num_buffers == 0 && q->fileio == NULL) {
>>> -   if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ)) {
>>> -   ret = __vb2_init_fileio(q, 1);
>>> -   if (ret)
>>> -   return POLLERR;
>>> -   }
>>> -   if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE)) {
>>> -   ret = __vb2_init_fileio(q, 0);
>>> -   if (ret)
>>> -   return POLLERR;
>>> -   /*
>>> -* Write to OUTPUT queue can be done immediately.
>>> -*/
>>> +   if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ))
>>> +   return POLLIN | POLLRDNORM;
>>> +   if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE))
>>> return POLLOUT | POLLWRNORM;
>>> -   }
>>> }
>>
>> There is one behavior change on this patchset:  __vb2_init_fileio() checks 
>> for some
>> troubles that may happen during device streaming initialization, returning 
>> POLLERR
>> if there is a problem there.
>>
>> By moving this code to be called only at read, it means the poll() will not 
>> fail
>> anymore, but the first read() will fail. The man page for read() doesn't 
>> tell that
>> -EBUSY or -ENOMEM could happen there. The same happens with V4L2 specs. So, 
>> it is
>> clearly violating kernel ABI.
>>
>> NACK.
> 
> Actually, almost nothing changes in the ABI. It's counterintuitive, but
> this is what happens:
> 
> 1) The poll() function in a driver does not actually return any error codes.
> It never did. It returns a poll mask, which is expected to be POLLERR in case
> of any error. All that it does is that select() returns if it waits for 
> reading
> or writing. Any actual error codes are never propagated. 

Yes, but POLLERR will return error on the vb2 cases that return -EBUSY or 
-ENOMEM.
This doesn't violate the ioctl ABI.

> This means BTW that
> our poll manual page is wrong (what a surprise), most of those error codes can
> never be returned.

True. The DocBook needs a fix. Posix describes it as:
http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html

> 
> 2) Suppose we try to start streaming in poll. If this works, then poll 
> returns,
> with POLLIN set, and the next read() will succeed (actually, it can return an
> error as well, but for other error conditions in case of e.g. hardware 
> errors).
> 
> The problem with this is of course that this will also start the streaming if
> all we wanted to wait for was an exception. That's not what we want at all.
> Ideally we could inspect in the driver what the caller wanted to wait for, but
> that information is not available, unfortunately.
> 
> 3) The other case is that we try to start streaming in poll and it fails.
> In that case any errors are lost and poll returns POLLERR (note that the 
> poll(2)
> manual page says that POLLERR is for output only, but clearly in the linux
> kernel it is accepted both input and output).

Posix doesn't impose such restriction.

> But for the select() call this POLLERR information is lost as well and the
> application will call read() anyway, which now will attempt to start the
> streaming (again after poll() tried it the first time) and this time it
> returns the actual error code.

The posix list of acceptable

Re: HVR-1250/CX23885 IR Rx

[Andy Walls]

Jarod Wilson  wrote:

>On Apr 10, 2011, at 7:08 PM, Andy Walls wrote:
>
>> On Sat, 2011-04-09 at 21:39 -0400, Jarod Wilson wrote:
>> 
 Jarod,
 
 The HVR-1850 uses a raw IR receiver in the CX23888 and older
>>> HVR-1250s use the raw IR receiver in the CX23885.  They both work
>for
>>> Rx (I need to tweak the Cx23885 rx watermark though), but I never
>>> found time to finish Tx (lack of kernel interface when I had time).
 
 If you obtain one of these I can answer any driver questions.
>>> 
>>> Quite some time back, I bought an HVR-1800 and an HVR-1250. I know
>one of
>>> them came with an mceusb transceiver and remote, as was pretty sure
>it was
>>> the 1800. For some reason, I didn't recall the 1250 coming with
>anything at
>>> all, but looking at dmesg output for it:
>>> 
>>> cx23885 driver version 0.0.2 loaded
>>> cx23885 :03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
>>> CORE cx23885[0]: subsystem: 0070:7911, board: Hauppauge
>WinTV-HVR1250 [card=3,autodetected]
>>> tveeprom 0-0050: Hauppauge model 79001, rev E3D9, serial# 4904656
>>> tveeprom 0-0050: MAC address is 00:0d:fe:4a:d6:d0
>>> tveeprom 0-0050: tuner model is Microtune MT2131 (idx 139, type 4)
>>> tveeprom 0-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88)
>>> tveeprom 0-0050: audio processor is CX23885 (idx 39)
>>> tveeprom 0-0050: decoder processor is CX23885 (idx 33)
>>> tveeprom 0-0050: has no radio, has IR receiver, has no IR
>transmitter
>>> 
>>> So it seems I do have hardware. However, its one of the two tuner
>cards in
>>> my "production" mythtv backend right now, making it a bit hard to do
>any
>>> experimenting with. If I can get it out of there, it looks like I
>just add
>>> an enable_885_ir=1, and I should be able to poke at it...
>> 
>> Yeah.  Igor's TeVii S470 CX23885 based card had interrupt storms when
>> enabled, so IR for '885 chips is disabled by default.  To
>investigate, I
>> tried to by an HVR-1250 with a CX23885, but instead got an HVR-1275
>with
>> a CX23888.  dandel, on IRC, did a pretty decent job in testing
>HVR-1250
>> operation and finding it works, despite climbing kernel
>> build/development learning curve at the time.
>...
>
>Finally got some time to play with my 1250, dug out its rx cable, turns
>out to
>be the same one I special-ordered to work on the 1150 Devin sent me.
>Oops.
>Anyway. First impressions, not so good. Got a panic on boot, somewhere
>in
>cx23885_video_irq, iirc, when booting with enable_885_ir=1 set.
>However, dmesg
>was somewhere in the middle of cx18 init of the HVR-1600 in the box.
>Dunno if
>there's any way that's actually directly related, but I yanked the
>1600. After
>doing that, the box managed to boot fine, but then while testing
>w/ir-keytable
>and an RC-6 remote, I got what I think was the same panic -- definitely
>the
>cx23885_video_irq bit in the trace, something about sleeping while
>atomic, IP
>at mwait_idle. (On the plus side, IR did seem to be working before
>that).
>
>Note also that this is a 2.6.32-based kernel with a 2.6.38-era backport
>of the
>driver code, because that's what was on this box. Was about to put it
>back into
>"production" use, but hey, its summer, there's nothing really for it to
>record
>for another few months, so I'll keep it out and throw it into another
>box with
>a newer kernel and serial console, etc., so I can further debug...
>
>
>-- 
>Jarod Wilson
>ja...@wilsonet.com

In a very early version of the CX23885 IR changes I made the mistake of 
performing I2C transactions in an interrupt handler.  That has been fixed in 
cx23885 for quite some time though.  It also required some I2C fixes in 
cx25840-core.c IIRC, which again, has been fixed for some time.

Regards,
Andy
--
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

Re: [RFCv3 PATCH 11/18] v4l2-ctrls: add v4l2_fh pointer to the set control functions.

[Mauro Carvalho Chehab]

Em 28-06-2011 03:22, Hans Verkuil escreveu:
> On Monday, June 27, 2011 23:20:07 Mauro Carvalho Chehab wrote:
>> Em 07-06-2011 12:05, Hans Verkuil escreveu:
>>> From: Hans Verkuil 
>>>
>>> When an application changes a control you want to generate an event.
>>> However, you want to avoid sending such an event back to the application
>>> (file handle) that caused the change.
>>
>> Why? 
>>
>> I can see two usecases for an event-triggered control change:
>>  1) when two applications are used, and one changed a value that could
>> affect the other;
>>  2) as a way to implement async changes.
>>
>> However, it seems, from your comments, that you're covering only case (1).
>>
>> There are several reasons why we need to support case (2):
>>
>> Some controls may be associated to a servo mechanism (like zoom, optical
>> focus, etc), or may require some time to happen (like charging a flash 
>> device).
>> So, it makes sense to have events back to the application that caused the 
>> change.
>>
>> Kernel should not assume that the application that requested a change on a 
>> control
>> doesn't want to receive the notification back when the event actually 
>> happened.
>> This way, both cases will be covered.
>>
>> Yet, I failed to see where, in the code, such restriction were imposed.
> 
> Async changes are triggered by the driver, not an application. Any changes
> made by the driver will be sent to all applications.
> 
> That said, I think I should add a flag like V4L2_EVENT_SUB_FL_NO_FEEDBACK
> to explicitly let applications decide.

Agreed. it makes the code more generic.
> 
> That's easy enough.
> 
> Regards,
> 
>   Hans

--
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

Re: [RFCv3 PATCH 08/18] v4l2-ctrls: add v4l2_ctrl_auto_cluster to simplify autogain/gain scenarios

[Mauro Carvalho Chehab]

Em 28-06-2011 03:08, Hans Verkuil escreveu:
> On Monday, June 27, 2011 22:57:34 Mauro Carvalho Chehab wrote:
>> Em 07-06-2011 12:05, Hans Verkuil escreveu:
>>> From: Hans Verkuil 
>>>
>>> It is a bit tricky to handle autogain/gain type scenerios correctly. Such
>>> controls need to be clustered and the V4L2_CTRL_FLAG_UPDATE should be set on
>>> the autofoo controls. In addition, the manual controls should be marked
>>> inactive when the automatic mode is on, and active when the manual mode is 
>>> on.
>>> This also requires specialized volatile handling.
>>>
>>> The chances of drivers doing all these things correctly are pretty remote.
>>> So a new v4l2_ctrl_auto_cluster function was added that takes care of these
>>> issues.
>>>
>>> Signed-off-by: Hans Verkuil 
>>> ---
>>>  drivers/media/video/v4l2-ctrls.c |   69 
>>> +++--
>>>  include/media/v4l2-ctrls.h   |   45 
>>>  2 files changed, 102 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/media/video/v4l2-ctrls.c 
>>> b/drivers/media/video/v4l2-ctrls.c
>>> index a46d5c1..c39ab0c 100644
>>> --- a/drivers/media/video/v4l2-ctrls.c
>>> +++ b/drivers/media/video/v4l2-ctrls.c
>>> @@ -39,6 +39,20 @@ struct ctrl_helper {
>>> bool handled;
>>>  };
>>>  
>>> +/* Small helper function to determine if the autocluster is set to manual
>>> +   mode. In that case the is_volatile flag should be ignored. */
>>> +static bool is_cur_manual(const struct v4l2_ctrl *master)
>>> +{
>>> +   return master->is_auto && master->cur.val == master->manual_mode_value;
>>> +}
>>> +
>>> +/* Same as above, but this checks the against the new value instead of the
>>> +   current value. */
>>> +static bool is_new_manual(const struct v4l2_ctrl *master)
>>> +{
>>> +   return master->is_auto && master->val == master->manual_mode_value;
>>> +}
>>> +
>>>  /* Returns NULL or a character pointer array containing the menu for
>>> the given control ID. The pointer array ends with a NULL pointer.
>>> An empty string signifies a menu entry that is invalid. This allows
>>> @@ -643,7 +657,7 @@ static int ctrl_is_volatile(struct v4l2_ext_control *c,
>>>  }
>>>  
>>>  /* Copy the new value to the current value. */
>>> -static void new_to_cur(struct v4l2_ctrl *ctrl)
>>> +static void new_to_cur(struct v4l2_ctrl *ctrl, bool update_inactive)
>>>  {
>>> if (ctrl == NULL)
>>> return;
>>> @@ -659,6 +673,11 @@ static void new_to_cur(struct v4l2_ctrl *ctrl)
>>> ctrl->cur.val = ctrl->val;
>>> break;
>>> }
>>> +   if (update_inactive) {
>>> +   ctrl->flags &= ~V4L2_CTRL_FLAG_INACTIVE;
>>> +   if (!is_cur_manual(ctrl->cluster[0]))
>>> +   ctrl->flags |= V4L2_CTRL_FLAG_INACTIVE;
>>> +   }
>>>  }
>>>  
>>>  /* Copy the current value to the new value */
>>> @@ -1166,7 +1185,7 @@ void v4l2_ctrl_cluster(unsigned ncontrols, struct 
>>> v4l2_ctrl **controls)
>>> int i;
>>>  
>>> /* The first control is the master control and it must not be NULL */
>>> -   BUG_ON(controls[0] == NULL);
>>> +   BUG_ON(ncontrols == 0 || controls[0] == NULL);
>>>  
>>> for (i = 0; i < ncontrols; i++) {
>>> if (controls[i]) {
>>> @@ -1177,6 +1196,28 @@ void v4l2_ctrl_cluster(unsigned ncontrols, struct 
>>> v4l2_ctrl **controls)
>>>  }
>>>  EXPORT_SYMBOL(v4l2_ctrl_cluster);
>>>  
>>> +void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl 
>>> **controls,
>>> +   u8 manual_val, bool set_volatile)
>>> +{
>>> +   struct v4l2_ctrl *master = controls[0];
>>> +   u32 flag;
>>> +   int i;
>>> +
>>> +   v4l2_ctrl_cluster(ncontrols, controls);
>>> +   WARN_ON(ncontrols <= 1);
>>> +   master->is_auto = true;
>>> +   master->manual_mode_value = manual_val;
>>
>> You'll have an overflow if manual_val is higher than 31 here.
>>
>>> +   master->flags |= V4L2_CTRL_FLAG_UPDATE;
>>> +   flag = is_cur_manual(master) ? 0 : V4L2_CTRL_FLAG_INACTIVE;
>>> +
>>> +   for (i = 1; i < ncontrols; i++)
>>> +   if (controls[i]) {
>>> +   controls[i]->is_volatile = set_volatile;
>>> +   controls[i]->flags |= flag;
>>> +   }
>>> +}
>>> +EXPORT_SYMBOL(v4l2_ctrl_auto_cluster);
>>> +
>>>  /* Activate/deactivate a control. */
>>>  void v4l2_ctrl_activate(struct v4l2_ctrl *ctrl, bool active)
>>>  {
>>> @@ -1595,7 +1636,7 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
>>> struct v4l2_ext_controls *cs
>>> ctrl_is_volatile);
>>>  
>>> /* g_volatile_ctrl will update the new control values */
>>> -   if (has_volatiles) {
>>> +   if (has_volatiles && !is_cur_manual(master)) {
>>> for (j = 0; j < master->ncontrols; j++)
>>> cur_to_new(master->cluster[j]);
>>> ret = call_op(master, g_volatile_ctrl);
>>> @@ -1633,7 +1674,7 @@ static int get_ctrl(struct v4l2_ctrl *ctrl, s32 *val)
>>>  
>>> 

Re: [PATCH] media: initial driver for ov5642 CMOS sensor

[Bastian Hecht]

2011/6/27 Laurent Pinchart :
> Hi Bastian,
>
> Thanks for the patch.
>
> On Friday 24 June 2011 12:57:36 Bastian Hecht wrote:
>> This is an initial driver release for the Omnivision 5642 CMOS sensor.
>>
>> Signed-off-by: Bastian Hecht 
>> ---
>>
>> diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
>> new file mode 100644
>> index 000..3cdae97
>> --- /dev/null
>> +++ b/drivers/media/video/ov5642.c
>> @@ -0,0 +1,1011 @@
>> +/*
>> + * Driver for OV5642 CMOS Image Sensor from Omnivision
>> + *
>> + * Copyright (C) 2011, Bastian Hecht 
>> + *
>> + * Based on Sony IMX074 Camera Driver
>> + * Copyright (C) 2010, Guennadi Liakhovetski 
>> + *
>> + * Based on Omnivision OV7670 Camera Driver
>> + * Copyright (C) 2006-7 Jonathan Corbet 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* OV5642 registers */
>> +#define REG_CHIP_ID_HIGH             0x300a
>> +#define REG_CHIP_ID_LOW                      0x300b
>> +
>> +#define REG_WINDOW_START_X_HIGH              0x3800
>> +#define REG_WINDOW_START_X_LOW               0x3801
>> +#define REG_WINDOW_START_Y_HIGH              0x3802
>> +#define REG_WINDOW_START_Y_LOW               0x3803
>> +#define REG_WINDOW_WIDTH_HIGH                0x3804
>> +#define REG_WINDOW_WIDTH_LOW         0x3805
>> +#define REG_WINDOW_HEIGHT_HIGH               0x3806
>> +#define REG_WINDOW_HEIGHT_LOW                0x3807
>> +#define REG_OUT_WIDTH_HIGH           0x3808
>> +#define REG_OUT_WIDTH_LOW            0x3809
>> +#define REG_OUT_HEIGHT_HIGH          0x380a
>> +#define REG_OUT_HEIGHT_LOW           0x380b
>> +#define REG_OUT_TOTAL_WIDTH_HIGH     0x380c
>> +#define REG_OUT_TOTAL_WIDTH_LOW              0x380d
>> +#define REG_OUT_TOTAL_HEIGHT_HIGH    0x380e
>> +#define REG_OUT_TOTAL_HEIGHT_LOW     0x380f
>> +
>> +/*
>> + * define standard resolution.
>> + * Works currently only for up to 720 lines
>> + * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
>> + */
>> +
>> +#define OV5642_WIDTH         1280
>> +#define OV5642_HEIGHT                720
>> +#define OV5642_TOTAL_WIDTH   3200
>> +#define OV5642_TOTAL_HEIGHT  2000
>> +#define OV5642_SENSOR_SIZE_X 2592
>> +#define OV5642_SENSOR_SIZE_Y 1944
>> +
>> +struct regval_list {
>> +     u16 reg_num;
>> +     u8 value;
>> +};
>> +
>> +static struct regval_list ov5642_default_regs_init[] = {
>> +     { 0x3103, 0x93 },
>> +     { 0x3008, 0x82 },
>> +     { 0x3017, 0x7f },
>> +     { 0x3018, 0xfc },
>> +     { 0x3810, 0xc2 },
>> +     { 0x3615, 0xf0 },
>> +     { 0x3000, 0x0  },
>> +     { 0x3001, 0x0  },
>> +     { 0x3002, 0x0  },
>> +     { 0x3003, 0x0  },
>> +     { 0x3004, 0xff },
>> +     { 0x3030, 0x2b },
>> +     { 0x3011, 0x8  },
>> +     { 0x3010, 0x10 },
>> +     { 0x3604, 0x60 },
>> +     { 0x3622, 0x60 },
>> +     { 0x3621, 0x9  },
>> +     { 0x3709, 0x0  },
>> +     { 0x4000, 0x21 },
>> +     { 0x401d, 0x22 },
>> +     { 0x3600, 0x54 },
>> +     { 0x3605, 0x4  },
>> +     { 0x3606, 0x3f },
>> +     { 0x3c01, 0x80 },
>> +     { 0x300d, 0x22 },
>> +     { 0x3623, 0x22 },
>> +     { 0x5000, 0x4f },
>> +     { 0x5020, 0x4  },
>> +     { 0x5181, 0x79 },
>> +     { 0x5182, 0x0  },
>> +     { 0x5185, 0x22 },
>> +     { 0x5197, 0x1  },
>> +     { 0x5500, 0xa  },
>> +     { 0x5504, 0x0  },
>> +     { 0x5505, 0x7f },
>> +     { 0x5080, 0x8  },
>> +     { 0x300e, 0x18 },
>> +     { 0x4610, 0x0  },
>> +     { 0x471d, 0x5  },
>> +     { 0x4708, 0x6  },
>> +     { 0x370c, 0xa0 },
>> +     { 0x5687, 0x94 },
>> +     { 0x501f, 0x0  },
>> +     { 0x5000, 0x4f },
>> +     { 0x5001, 0xcf },
>> +     { 0x4300, 0x30 },
>> +     { 0x4300, 0x30 },
>> +     { 0x460b, 0x35 },
>> +     { 0x471d, 0x0  },
>> +     { 0x3002, 0xc  },
>> +     { 0x3002, 0x0  },
>> +     { 0x4713, 0x3  },
>> +     { 0x471c, 0x50 },
>> +     { 0x4721, 0x2  },
>> +     { 0x4402, 0x90 },
>> +     { 0x460c, 0x22 },
>> +     { 0x3815, 0x44 },
>> +     { 0x3503, 0x7  },
>> +     { 0x3501, 0x73 },
>> +     { 0x3502, 0x80 },
>> +     { 0x350b, 0x0  },
>> +     { 0x3818, 0xc8 },
>> +     { 0x3824, 0x11 },
>> +     { 0x3a00, 0x78 },
>> +     { 0x3a1a, 0x4  },
>> +     { 0x3a13, 0x30 },
>> +     { 0x3a18, 0x0  },
>> +     { 0x3a19, 0x7c },
>> +     { 0x3a08, 0x12 },
>> +     { 0x3a09, 0xc0 },
>> +     { 0x3a0a, 0xf  },
>> +     { 0x3a0b, 0xa0 },
>> +     { 0x350c, 0x7  },
>> +     { 0x350d, 0xd0 },
>> +     { 0x3a0d, 0x8  },
>> +     { 0x3a0e, 0x6  },
>> +     { 0x3500, 0x0  },
>> +     { 0x3501, 0x0  },
>> +     { 0x3502, 0x0  },
>> +     { 0x350a, 0x0  },
>> +     { 0x350b, 0x0  },
>> +     { 0x3503, 0x0  },
>> +     { 0x3a0f, 0x3c },
>> +     { 0x3a10, 0x32 },
>> +     { 0x3a1b, 0x3c },
>> +     { 0x3a1e, 0x32 },
>> +     { 0x3a11, 0x80 },
>> +     { 0x3a1f, 0x20 },
>> +   

Re: [RFCv3 PATCH 12/18] vb2_poll: don't start DMA, leave that to the first read().

[Hans Verkuil]

On Tuesday, June 28, 2011 09:33:57 Hans Verkuil wrote:
> On Monday, June 27, 2011 23:52:37 Mauro Carvalho Chehab wrote:
> > Em 07-06-2011 12:05, Hans Verkuil escreveu:
> > > From: Hans Verkuil 
> > > 
> > > The vb2_poll function would start read-DMA if called without any streaming
> > > in progress. This unfortunately does not work if the application just 
> > > wants
> > > to poll for exceptions. This information of what the application is 
> > > polling
> > > for is sadly unavailable in the driver.
> > > 
> > > Andy Walls suggested to just return POLLIN | POLLRDNORM and let the first
> > > call to read() start the DMA. This initial read() call will return EAGAIN
> > > since no actual data is available yet, but it does start the DMA.
> > > 
> > > Applications must handle EAGAIN in any case since there can be other 
> > > reasons
> > > for EAGAIN as well.
> > > 
> > > Signed-off-by: Hans Verkuil 
> > > ---
> > >  drivers/media/video/videobuf2-core.c |   17 +++--
> > >  1 files changed, 3 insertions(+), 14 deletions(-)
> > > 
> > > diff --git a/drivers/media/video/videobuf2-core.c 
> > > b/drivers/media/video/videobuf2-core.c
> > > index 6ba1461..ad75c95 100644
> > > --- a/drivers/media/video/videobuf2-core.c
> > > +++ b/drivers/media/video/videobuf2-core.c
> > > @@ -1372,27 +1372,16 @@ static int __vb2_cleanup_fileio(struct vb2_queue 
> > > *q);
> > >  unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table 
> > > *wait)
> > >  {
> > >   unsigned long flags;
> > > - unsigned int ret;
> > >   struct vb2_buffer *vb = NULL;
> > >  
> > >   /*
> > >* Start file I/O emulator only if streaming API has not been used yet.
> > >*/
> > >   if (q->num_buffers == 0 && q->fileio == NULL) {
> > > - if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ)) {
> > > - ret = __vb2_init_fileio(q, 1);
> > > - if (ret)
> > > - return POLLERR;
> > > - }
> > > - if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE)) {
> > > - ret = __vb2_init_fileio(q, 0);
> > > - if (ret)
> > > - return POLLERR;
> > > - /*
> > > -  * Write to OUTPUT queue can be done immediately.
> > > -  */
> > > + if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ))
> > > + return POLLIN | POLLRDNORM;
> > > + if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE))
> > >   return POLLOUT | POLLWRNORM;
> > > - }
> > >   }
> > 
> > There is one behavior change on this patchset:  __vb2_init_fileio() checks 
> > for some
> > troubles that may happen during device streaming initialization, returning 
> > POLLERR
> > if there is a problem there.
> > 
> > By moving this code to be called only at read, it means the poll() will not 
> > fail
> > anymore, but the first read() will fail. The man page for read() doesn't 
> > tell that
> > -EBUSY or -ENOMEM could happen there. The same happens with V4L2 specs. So, 
> > it is
> > clearly violating kernel ABI.
> > 
> > NACK.
> 
> Actually, almost nothing changes in the ABI. It's counterintuitive, but
> this is what happens:
> 
> 1) The poll() function in a driver does not actually return any error codes.
> It never did. It returns a poll mask, which is expected to be POLLERR in case
> of any error. All that it does is that select() returns if it waits for 
> reading
> or writing. Any actual error codes are never propagated. This means BTW that
> our poll manual page is wrong (what a surprise), most of those error codes can
> never be returned.
> 
> 2) Suppose we try to start streaming in poll. If this works, then poll 
> returns,
> with POLLIN set, and the next read() will succeed (actually, it can return an
> error as well, but for other error conditions in case of e.g. hardware 
> errors).
> 
> The problem with this is of course that this will also start the streaming if
> all we wanted to wait for was an exception. That's not what we want at all.
> Ideally we could inspect in the driver what the caller wanted to wait for, but
> that information is not available, unfortunately.
> 
> 3) The other case is that we try to start streaming in poll and it fails.
> In that case any errors are lost and poll returns POLLERR (note that the 
> poll(2)
> manual page says that POLLERR is for output only, but clearly in the linux
> kernel it is accepted both input and output).
> 
> But for the select() call this POLLERR information is lost as well and the
> application will call read() anyway, which now will attempt to start the
> streaming (again after poll() tried it the first time) and this time it
> returns the actual error code.
> 
> Just try this with capture-example: start it in mmap mode, then try to run
> it in read mode from a second console. The EBUSY error comes from the read()
> command, not from select(). With or without t

RE: FW: OMAP 3 ISP

[Alex Gershgorin]

Hi Laurent,

I recently got the Zoom OMAP35xx Torpedo and began testing OMAP3ISP.
Currently I have a problem I can't solve.
See Message from booting Kernel:

Linux media interface: v0.10
Linux video capture interface: v2.00
omap3isp omap3isp: Revision 2.0 found
omap-iommu omap-iommu.0: isp: version 1.1
isp_register_subdev_group: Unable to register subdev

What could be the problem, why sub device can't pass a registration?

Thanks,

Alex Gershgorin


-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: 
Wednesday, May 25, 2011 1:02 PM
To: Alex Gershgorin
Cc: 'Sakari Ailus'; Michael Jones; 'linux-media@vger.kernel.org'; 
'age...@rambler.ru'
Subject: Re: FW: OMAP 3 ISP

Hi Alex,

On Wednesday 25 May 2011 11:58:58 Alex Gershgorin wrote:
> Hi Laurent,
>
> Unfortunately, at this point I have no Hardware platforms, but in the
> next week we should get Zoom OMAP35 Torpedo evaluation kit
> and then I can test it.
>
> I have already applied this patch on the last main line
> Kernel version (2.6.39) and continue to work on the platform device for
> Zoom OMAP35xx Torpedo.
>
> Thanks for this patch :-)

You're welcome. Please let me know if it works for you when you'll receive the
hardware. I will then push the patch to mainline.

--
Regards,

Laurent Pinchart


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6149 (20110524) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6245 (20110627) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

--
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

Re: [RFCv3 PATCH 12/18] vb2_poll: don't start DMA, leave that to the first read().

[Hans Verkuil]

On Monday, June 27, 2011 23:52:37 Mauro Carvalho Chehab wrote:
> Em 07-06-2011 12:05, Hans Verkuil escreveu:
> > From: Hans Verkuil 
> > 
> > The vb2_poll function would start read-DMA if called without any streaming
> > in progress. This unfortunately does not work if the application just wants
> > to poll for exceptions. This information of what the application is polling
> > for is sadly unavailable in the driver.
> > 
> > Andy Walls suggested to just return POLLIN | POLLRDNORM and let the first
> > call to read() start the DMA. This initial read() call will return EAGAIN
> > since no actual data is available yet, but it does start the DMA.
> > 
> > Applications must handle EAGAIN in any case since there can be other reasons
> > for EAGAIN as well.
> > 
> > Signed-off-by: Hans Verkuil 
> > ---
> >  drivers/media/video/videobuf2-core.c |   17 +++--
> >  1 files changed, 3 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/media/video/videobuf2-core.c 
> > b/drivers/media/video/videobuf2-core.c
> > index 6ba1461..ad75c95 100644
> > --- a/drivers/media/video/videobuf2-core.c
> > +++ b/drivers/media/video/videobuf2-core.c
> > @@ -1372,27 +1372,16 @@ static int __vb2_cleanup_fileio(struct vb2_queue 
> > *q);
> >  unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table 
> > *wait)
> >  {
> > unsigned long flags;
> > -   unsigned int ret;
> > struct vb2_buffer *vb = NULL;
> >  
> > /*
> >  * Start file I/O emulator only if streaming API has not been used yet.
> >  */
> > if (q->num_buffers == 0 && q->fileio == NULL) {
> > -   if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ)) {
> > -   ret = __vb2_init_fileio(q, 1);
> > -   if (ret)
> > -   return POLLERR;
> > -   }
> > -   if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE)) {
> > -   ret = __vb2_init_fileio(q, 0);
> > -   if (ret)
> > -   return POLLERR;
> > -   /*
> > -* Write to OUTPUT queue can be done immediately.
> > -*/
> > +   if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ))
> > +   return POLLIN | POLLRDNORM;
> > +   if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE))
> > return POLLOUT | POLLWRNORM;
> > -   }
> > }
> 
> There is one behavior change on this patchset:  __vb2_init_fileio() checks 
> for some
> troubles that may happen during device streaming initialization, returning 
> POLLERR
> if there is a problem there.
> 
> By moving this code to be called only at read, it means the poll() will not 
> fail
> anymore, but the first read() will fail. The man page for read() doesn't tell 
> that
> -EBUSY or -ENOMEM could happen there. The same happens with V4L2 specs. So, 
> it is
> clearly violating kernel ABI.
> 
> NACK.

Actually, almost nothing changes in the ABI. It's counterintuitive, but
this is what happens:

1) The poll() function in a driver does not actually return any error codes.
It never did. It returns a poll mask, which is expected to be POLLERR in case
of any error. All that it does is that select() returns if it waits for reading
or writing. Any actual error codes are never propagated. This means BTW that
our poll manual page is wrong (what a surprise), most of those error codes can
never be returned.

2) Suppose we try to start streaming in poll. If this works, then poll returns,
with POLLIN set, and the next read() will succeed (actually, it can return an
error as well, but for other error conditions in case of e.g. hardware errors).

The problem with this is of course that this will also start the streaming if
all we wanted to wait for was an exception. That's not what we want at all.
Ideally we could inspect in the driver what the caller wanted to wait for, but
that information is not available, unfortunately.

3) The other case is that we try to start streaming in poll and it fails.
In that case any errors are lost and poll returns POLLERR (note that the poll(2)
manual page says that POLLERR is for output only, but clearly in the linux
kernel it is accepted both input and output).

But for the select() call this POLLERR information is lost as well and the
application will call read() anyway, which now will attempt to start the
streaming (again after poll() tried it the first time) and this time it
returns the actual error code.

Just try this with capture-example: start it in mmap mode, then try to run
it in read mode from a second console. The EBUSY error comes from the read()
command, not from select(). With or without this patch, capture-example
behaves exactly the same.

The only ABI change I see is with poll(2) and epoll(7) where POLLERR is no
longer returned. Since this isn't documented at all anyway (and the poll(2)
manual page is actually unclear about whether