On 09/24/2013 06:19 PM, Guennadi Liakhovetski wrote: > Hi Hans > > On Tue, 24 Sep 2013, Hans Verkuil wrote: > >> Shouldn't the interrupt_service_routine() op be implemented as well? >> Usually these drivers will generate interrupts if e.g. the format changes. > > Should it? AFAIU, .interrupt_service_routine() is a subde operation to be > called by a bridge driver, when it gets an interrupt for the respective > subdevice: > > interrupt_service_routine: Called by the bridge chip's interrupt service > handler, when an interrupt status has be raised due to this subdev, > typo ^^ > > so that this subdev can handle the details. It may schedule work to be > performed later. It must not sleep. *Called from an IRQ context*. Hmm, I have serious doubts whether the "It must not sleep. *Called from an IRQ context*." part is correct. I have to check that. I think it is actually the opposite, especially since most i2c drivers will have to do i2c accesses which can always sleep. > > In this case the device does indeed have 2 interrupt output lines, but I > don't think they would be connected to dedicated bridge inputs, rather to > GPIOs, so, the driver can implement an ISR itself, when it decides to > implement support for those interrupts. That's another option. But this driver implements neither option, which is unusual. Regards, Hans -- 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
