On June 20, 2014 9:58:19 PM EDT, Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx> wrote: >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 cx23888-ir cx18-av cx18-gpio I have a nonreleased one that uses SPI as well if you need an example of that. Regards, Andy -- 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
