Hello, I'm in the process of adding support for a new video decoder. However in this case it's an IP block on a USB bridge as opposed to the typical case which is an I2C device. Changing registers for the subdev is the same mechanism as changing registers in the rest of the bridge (a specific region of registers is allocated for the video decoder).
Doing a subdev driver seems like the logical approach to keep the video decoder related routines separate from the rest of the bridge. It also allows the reuse of the code if we find other cases where the IP block is present in other devices. However I'm not really sure what the mechanics are for creating a subdev that isn't really an I2C device. I think we've had similar cases with the Conexant parts where the Mako was actually a block on the main bridge (i.e. cx23885/7/8, cx231xx). But in that case the cx25840 subdev just issues I2C commands and leverages the fact that you can talk to the parts over I2C even though they're really on-chip. Are there any other cases today where we have a subdev that uses traditional register access routines provided by the bridge driver to read/write the video decoder registers? In this case I would want to reuse the register read/write routines provided by the bridge, which ultimately are send as USB control messages. Any suggestions welcome (and in particular if you can point me to an example case where this is already being done). Thanks in advance, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
