Re: [GIT PATCH FOR 2.6.40] uvcvideo patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Mauro,

Thanks for handling the pull request.

On Friday 20 May 2011 17:32:45 Mauro Carvalho Chehab wrote:
> Em 15-05-2011 04:48, Laurent Pinchart escreveu:
> > Hi Mauro,
> > 
> > The following changes since commit 
f9b51477fe540fb4c65a05027fdd6f2ecce4db3b:
> >   [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09
> >   05:47:20 +0200)
> > 
> > are available in the git repository at:
> >   git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next
> > 
> > They replace the git pull request I've sent on Thursday with the same
> > subject.
> > 
> > Bob Liu (2):
> >       Revert "V4L/DVB: v4l2-dev: remove get_unmapped_area"
> >       uvcvideo: Add support for NOMMU arch
> 
> IMO, such fixes should happen inside the arch bits, and not on each driver.
> If this fix is needed for uvc video, the same fix should probably needed
> to all other USB drivers, in order to work on NOMMU arch.
> 
> For now, I'm accepting this as a workaround, but please work on a generic
> solution for it.

A fix at the arch/ level isn't possible, as drivers need to implement the 
get_unmapped_area file operation in order to support NOMMU architectures. The 
proper fix is of course to port uvcvideo to videobuf2, and implement support 
for NOMMU in videobuf2. Modifications to individual drivers will still be 
needed to fill the get_unmapped_area operation pointer with a videobuf2 
handler though.

> > Hans de Goede (2):
> >       v4l: Add M420 format definition
> >       uvcvideo: Add M420 format support
> 
> OK.
> 
> > Laurent Pinchart (4):
> >       v4l: Release module if subdev registration fails
> >       uvcvideo: Register a v4l2_device
> >       uvcvideo: Register subdevices for each entity
> >       uvcvideo: Connect video devices to media entities
> 
> We've discussed already about using the media controller for uvcvideo, but
> I can't remember anymore what where your aguments in favor of merging it
> (and, even if I've remembered it right now, the #irc channel log is not
> the proper way to document the rationale to apply a patch).
> 
> The thing is: it is clear that SoC embedded devices need the media
> controller, as they have IP blocks that do weird things, and userspace may
> need to access those, as it is not possible to control such IP blocks
> using the V4L2 API.
> 
> However, I have serious concerns about media_controller API usage on
> generic drivers, as it is required that all drivers should be fully
> configurable via V4L2 API alone, otherwise we'll have regressions, as no
> generic applications use the media_controller.

> In other words, if you have enough arguments about why we should add
> media_controller support at the uvcvideo, please clearly provide them at
> the patch descriptions, as this is not obvious. It would equally important
> do document, at the uvcvideo doc, what kind of information is provided via
> the media_controller and why an userspace application should care to use
> it.

First of all, the uvcvideo driver doesn't require application to use the media 
controller API to operate. All configuration is handled through a V4L2 video 
device node, and these patches do not modify that. No change is required to 
applications to use the uvcvideo driver.

There's however a reason why I want to add support for the media controller 
API to the uvcvideo driver (I wouldn't have submitted the patches otherwise 
:-)). UVC-compliant devices are modeled as a connected graph of entities 
(called terminals and units in the UVC world). The device topology can be 
arbitrarily complex (or simple, which is fortunately often the case) and is 
exported by the device to the host through USB descriptors. The uvcvideo 
driver parses the descriptor, creates an internal representation of the device 
internal topology, and maps V4L2 operations to the various entities that the 
device contains.

The UVC specification standardizes a couple of entities (camera terminal, 
processing unit, ...) and allows device vendors to create vendor-specific 
entities called extension units (XUs in short). Those XUs are usually used to 
expose controls that are not standardized by UVC to the host. These controls 
can be anything from an activity LED to a firmware update system. The uvcvideo 
tries to map those XU controls to V4L2 controls when it makes sense (and when 
the controls are documented by the device manufacturer, which is unfortunately 
often not the case). If an XU control can't be mapped to a V4L2 control, it 
can be accessed through uvcvideo-specific (documented) ioctls.

In order to access those XU controls, device-specific applications (such as a 
firmware update application for instance) need to know what XUs are present in 
the device and possibly how they are connected. That information can't be 
exported through V4L2. That's why I'm adding media controller support to the 
uvcvideo driver.

The media controller has been designed to export the device internal topology 
to userspace and to make it configurable. That makes it an ideal candidate for 
the task at hand, which is exporting the device internal topology to 
userspace. The uvcvideo driver doesn't allow applications to configure the 
device through the media controller API, so there will be no change for V4L2-
only applications.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux