Hi Benoit, On Tue, Mar 05, 2019 at 08:34:09AM -0600, Benoit Parrot wrote: > Sakari, > > Thank you for the patch. > > Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> wrote on Tue [2019-Mar-05 16:02:24 +0200]: > > ti-vpe driver parsed the remote endpoints for properties but ignored the > > local ones. Fix this by parsing the local endpoint properties instead. > > I am not sure I understand the logic here. For CSI2 sensor as far as I > understand the lane mapping (clock and data) is driven from the sensor > side. The bridge driver (in this case CAL) needs to setup the receiver side > based on what the sensor (aka remote endpoint) can provide. > > I failed to see how this fixes things here. > > Are you suggesting that sensor relevant properties be set (and effectively > duplicated) on the bridge/receiver side? Yes. The endpoint configuration in general is local to the device and should not be accessed from other device drivers. The lane mapping, for instance, is specific to a given device --- and may differ even between for two connected endpoints. It's used to reorder the PHY lanes (if the device supports that). Same goes for the clock lane. See e.g. arch/arm/boot/dts/omap3-n9.dts . > > Some sensor can and do handle multiple data lanes configuration so the > sensor driver also needs to use those properties at probe time, duplicating > the lane data is just asking for a mismatch to happen, no? It's a different configuration on the sensor side. We currently have no checks in place to verify that the two would match. I haven't heard of this would have really been a problem though. The frame descriptors should be used for runtime configuration. Niklas and more recently Jacopo have been working on that. -- Kind regards, Sakari Ailus sakari.ailus@xxxxxxxxxxxxxxx
