On Sunday 11 January 2009 14:46:29 Andy Walls wrote: > > > > I'm very interested in how easy it is for you to convert cx18 > > > > to v4l2_subdev. Please let me know anything that is unclear or > > > > that can be improved in the documentation or code! > > Hans, > > Converting cx18 to use a v4l2_device object was easy enough. There's > not a lot to do, because on it's own it doesn't do to much. At this > early stage, without the v4l2_subdev work done, it's simply one more > piece of kernel rigamarole with which to deal, along with struct > pci_dev, struct device, struct video_dev. > > As I begin the conversion process to v4l2_subdev, I realize it's not > the straightforward hack for which I was hoping. A clear first step > in the porting process needs to be to answer design questions: > > 1. What are the v4l2_subdev's for this family of capture devices? > (This is actually harder to answer than I thought.) tuner, cs5345 and cx18-av (the digitizer core). Probably gpio as well; this was very useful with ivtv. > 2. Do I need to write any bridge specific v42l_subdev's? For the av core and gpio, yes. Note that the reasons for doing this are technical (it makes the code easier), rather than compulsory as is the case for the external i2c devices. You can take a peek at ivtv-gpio.c to see how to make a bridge-specific subdev. It's trivial. > 3. What functions do all the needed v4l2_subdev's perform? It's just a layer on top of i2c devices, making it easier to load and initialize them and to call them (and of course v4l2_subdev is no longer i2c-specific). The functionality didn't change at all so subdevs perform exactly the same functions that they did before. > 4. What functions will I need from all the functions a > chip/v4l2_subdev provides? Again, nothing changed here. The ioctl command maps to the corresponding function, that's all. > 5. How will I manage the subdevs to get at just the particular subdev > functions I need for any given task? There are roughly three approaches: 1) Just call them all using v4l2_device_call_all(). Usually this works best and I think this might be all you need for cx18. If a subdev doesn't support the function then it is just skipped. 2) You can assign some non-zero value to the grp_id of a subdev and pass that value with v4l2_device_call_all() to call only subdevs with that grp_id. 3) You can store v4l2_subdev pointer somewhere and use that with v4l2_subdev_call(). Note that I recommend making some handy variants of v4l2_device_call_all() that use the cx18 pointer as their first argument. It makes life a bit easier. > 6. Do I try to deal with the DTV subdevices on my hybrid cards now, > or wait until later? No. For now v4l2 sub-devices only deal with V4L2 devices and not with DVB devices. Nothing changes on the DVB side. > These are all up front design questions that I would have done on a > professional project with a full up front design. What I found with > trying to iteratively hack was that decisions come up at many > junctures with porting this framework to cx18. I suspect the > framework will be great for maintenance activities once in place, but > initial porting of existing drivers probably requires an above > average level of discipline. > > I will elaborate on how I encountered the design questions above, > later today (I've got to head to out soon). I'll also propose what I > think is some guidance to answer question 1 at least. (For highly > integrated devices with loose internal couplings in places, like > CX23418, it's not as simple as a "chip" or "something connected to > I2C, GPIO or other bus lines".) I'd forgotten about the av-core of the cx23418 that needs to be converted to v4l2_subdev. Basically the same work that I did with the cx25840 i2c driver. That makes it more work than I realized. Note that this is unique to cx18, I don't think other bridge drivers need this. In general one could say that any a/v encoder/decoder/muxer/tuner device is a candidate for v4l2_subdev, whether it is connected through GPIO, I2C or part of an integrated device. This is true in particular if the same command should be handled by more than one device. E.g. VIDIOC_S_STD is typically a command that needs to be sent to multiple subdevs (a/v digitizers, tuner), and so it makes sense to view the digitizer part of the cx23418 as a subdev as well. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
