On June 21, 2014 7:17:07 AM EDT, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote: >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 I should mention that cx23888-ir and cx23885-ir both bring up interesting issues with IRQ handling and reuse. Regarding interrupts: cx23888-ir does all its interrupt handling work in the hard IRQ context; because it can, but it shouldn't. cx23885-ir uses a work queue to defer interrupt handling work, but that's not optimal for RT, as you can't tune concurrency managed work queue handler priorities for your work items. Both should really be using a threaded IRQ handler. That makes deferring work easy and tuning RT priority easy. Regarding resue: Both are using the same watermark level for triggering interrupts even though response times for direct vs. I2c connected is different. Also the IRQ mask registers between the block versions are inverted. These sorts of things amount in code reuse pains. 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
