linux-kernel - Re: [PATCH v2] v4l2_device/v4l2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200811302134.07166.david-b@pacbell.net>
Date:	Sun, 30 Nov 2008 21:34:06 -0800
From:	David Brownell <david-b@...bell.net>
To:	Hans Verkuil <hverkuil@...all.nl>, Andy Walls <awalls@...ix.net>
Cc:	Linux and Kernel Video <video4linux-list@...hat.com>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"davinci-linux-open-source@...ux.davincidsp.com" 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] v4l2_device/v4l2_subdev: final (?) version

On Sunday 30 November 2008, Hans Verkuil wrote:
> > On a more philosophical note is GPIO really a single subdev or a
> > collection of independent serial & discrete buses to a collection of
> > subdevs?  In cx18 depending on the board, GPIO can reset chips,
> > change audio mux paths, change the state of LED's, and in the future
> > be used as a serial line (if I ever get that soft-UART to the IR
> > blaster implemented).
> 
> Definitely a collection of subdevs. Usually each chip driven by GPIO 
> would have its own subdev. So ivtv implements an audio muxer subdev, 
> but it might also have additional subdevs for other chips connected to 
> the GPIO lines. I haven't explored all the possibilities yet, but I 
> suspect that this can be a quite powerful solution.

Right.  GPIO is basically a glue tech ... the focus should be what's
being glued (the various subdevs, and their parents), not on the glue.
I think a standardized set of GPIO calls, and gpiolib, makes that a
lot easier nowadays; though maybe not always painless.

Keeping to the V4L2 topic:  I figure there will be some issues there
to sort out.  For example, it might be important to collect key
resources like GPIOs and regulators before setting up the various I2C
clients that rely on those for proper operation, or other parts of a
complex V4L2 "assembly" (to coin a term).  I understand that in some
cases those GPIOs are provided through I2C-based expanders... such
sequencing issues will become clearer as the $SUBJECT work matures.
(I'd expect the v4l2_device would manage such stuff.)

One widely accessible OMAP example:  the beagleboard.org hardware uses
a GPIO to enable its DVI output, and a regulator that must be enabled
for S-Video output.  Both should be disabled when their output channel
is not in use -- software doesn't handle that yet though! -- and I'd
expect an OMAP3 v4l2_device would understand such board-specific setup
issues.  (Support for that isn't yet in mainline though.)

- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/