- 27 Jul, 2011 40 commits
-
-
Hans de Goede authored
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-François Moine authored
In the webcam 041e:405f, the LED is inverted. Signed-off-by: Jean-François Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-François Moine authored
The sensor of some webcams could not be detected due to timing problems in sensor register reading. This patch adds bridge register readings before sensor register reading. Signed-off-by: Jean-François Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Stefan Richter authored
Mauro Carvalho Chehab wrote: > I'm validating if all drivers are behaving equally with respect to the > error codes returned to userspace, and double-checking with the API. > > On almost all places, -EFAULT code is used only to indicate when > copy_from_user/copy_to_user fails. However, firedtv uses a lot of > -EFAULT, where it seems to me that other error codes should be used > instead (like -EIO for bus transfer errors and -EINVAL/-ERANGE for > invalid/out of range parameters). This concerns only the CI (CAM) related code of firedtv of which I know little. Let's just pass through the error returns of lower level I/O code where applicable, and -EACCES (permission denied) when a seemingly valid but negative FCP response or an unknown-to-firedtv CA message is received. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Henrik Kurelid <henrik@kurelid.se> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Those drivers are not relying at the V4L2 core to handle the ioctl's. So, we need to manually patch them every time a change goes to the core. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-By: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Currently, -EINVAL is used to return either when an IOCTL is not implemented, or if the ioctl was not implemented. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
While here, removes the bogus EINTERNAL error codes. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Move generic stuff into gen-errors.xml, and remove them from DVB API. While here, removes two bogus error codes that aren't supported or used on Linux: EINTERNAL and ENOSIGNAL. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
When a device (or their PCI structs) are not found, the error should be -ENODEV. -EFAULT is reserved for errors while copying arguments from/to userspace. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Remove generic errors from ioctl() descriptions. For other ioctl's, there's no generic section. So, just keep whatever is there. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Remove generic errors from ioctl() descriptions. For other ioctl's, there's no generic section. So, just keep whatever is there. Also remove the EINTERNAL error code, as no DVB driver returns it, and this error code is not defined on POSIX or on Linux. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Just like the V4L, MC and LIRC API's, point to the generic error chapter for ioctl's. This will allow moving generic error codes to just one place inside all media API's. A latter patch will remove the generic errors from each specific ioctl. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
data from/to userspace. Don't mix it with I2C bus error (-EIO). Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Add a reference for the generic error code chapter to LIRC ioctl description. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
V4L ioctl function descripton also has a generic error chapter. Remove it, as it is now obsoleted by a general, multi-API generic error descriptions. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
The EBUSY is already described as a generic error condition, with a similar text. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Instead of having their own generic error codes at the MC API, move its section to the generic one and be sure that all media ioctl's will point to it. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Be sure that all VIDIOC_* ioctl are using the return error macro, and aren't specifying generic error codes internally. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
There are several errors reported by V4L that aren't described. They can occur on almost all ioctl's. Instead of adding them into each ioctl, create a new chapter. For V4L, the new chapter will automatically be listed on all places, as there's a macro used everywhere there. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jonathan Corbet authored
Scatter/gather DMA mode works nicely on this platform and is clearly the best way of doing things. Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jonathan Corbet authored
The core Marvell camera driver can now do scatter/gather DMA on controllers which support that functionality. Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
Normally no control events will go to the filehandle that called the VIDIOC_S_CTRL/VIDIOC_S_EXT_CTRLS ioctls. This is to prevent a feedback loop. This can now be overridden by setting the new V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK flag. Based on suggestions from Mauro Carvalho Chehab <mchehab@redhat.com> and Laurent Pinchart <laurent.pinchart@ideasonboard.com>. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
It's getting confusing who is linking to what, so add an overview at the start of the header. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
Thanks to Laurent Pinchart <laurent.pinchart@ideasonboard.com>. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
Starting with v3.1 the V4L2 API provides certain guarantees with respect to events. Document these. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
v4l2_fh_init now returns void instead of int, updated the doc. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
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 <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
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 <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
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 <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
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 <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
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 <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
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 <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
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 <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andrew Chew authored
On suspend, remember whether we are streaming or not, and at what frame format, so that on resume, we can start streaming again. Signed-off-by: Andrew Chew <achew@nvidia.com> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andrew Chew authored
This is to avoid needing a forward declaration when ov9740_s_power() (in the subsequent patch) calls ov9740_s_fmt(). Signed-off-by: Andrew Chew <achew@nvidia.com> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andrew Chew authored
Derive resolution-dependent register settings programmatically. Signed-off-by: Andrew Chew <achew@nvidia.com> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-