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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
