On Mon, Aug 24, 2009 at 01:57:44PM +0200, Laurent Pinchart wrote: > Hi Greg, > > while working on video input support for embedded platforms a few developers > including myself ran independently into a Linux device model issue. We all > came up with hackish solutions that we are not very happy with, and we'd like > to fix this in a clean way. > > The problem comes from devices sitting on multiple busses, a situation > commonly found with video sensors connected to an embedded System on Chip > (SoC). The sensor is controlled through an I2C bus and sends video data on a > parallel video bus, connected to a camera controller usually referred as an > Image Signal Processor (ISP), Video Processing Front End (VPFE), CCD > Controller (CCDC) or simply a bridge. > > The bridge and the I2C master controller on the SoC are completely independent > from each other. The I2C master controller is not dedicated to the video > function and is often used to communication with non-video I2C devices. > > Unfortunately, on the sensor side, I2C and video bus are not independent. The > I2C slave controller usually requires an external clock to be present, and the > clock is usually provided on the video bus by the SoC bridge. > > As the bridge and I2C master live their own life in the Linux device tree, > they are initialized, suspended, resumed and destroyed independently. The > sensor being an I2C slave device, Linux initializes it after the I2C master > device is initialized, but doesn't ensure that the bridge is initialized first > as well. A similar problem occurs during suspend/resume, as the I2C slave > needs to be suspended before and resumed after the video bridge. > > Have you ever encountered such a situation before ? No, not really. > Is there a clean way for a device to have multiple parents, or do you > have plans for such a possibility in the future ? I do not know of any future plans to support something like this in the driver core code, sorry. > I would be willing to give an implementation a try if you can provide > me with some guidelines. Hm, I really don't know of any guidelines I can provide, as I've never thought about this before :) I really don't know what to suggest at the moment, sorry. greg k-h -- 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
