Messages in this thread | | | Date | Mon, 20 Mar 2023 12:15:20 +0200 | From | Sakari Ailus <> | Subject | Re: [PATCH v2] media: i2c: ov5640: Implement get_mbus_config |
| |
Hi Laurent,
On Mon, Mar 20, 2023 at 11:55:14AM +0200, Laurent Pinchart wrote: > On Mon, Mar 20, 2023 at 11:37:33AM +0200, Sakari Ailus wrote: > > Hi Laurent, > > > > On Mon, Mar 20, 2023 at 11:26:02AM +0200, Laurent Pinchart wrote: > > > In a (simplified) nutshell, > > > > > > ---------+ +----------+ +---------+ +-----+ +-----+ > > > | Camera | --> | CSI-2 RX | --> | CSI2IPU | --> | Mux | --> | IPU | > > > | Sensor | | | | Gasket | | | | | > > > ---------+ +----------+ +---------+ +-----+ +-----+ > > > > Thank you, this is helpful. > > > > I suppose the mux here at least won't actively do anything to the data. So > > presumably its endpoint won't contain the active configuration, but its > > superset. > > > > > > > > All those blocks, except for the gasket, have a node in DT. > > > > > > The IPU driver needs to know the number of CSI-2 data lanes, which is > > > encoded in the data-lanes DT property present in both the sensor output > > > endpoint and the CSI-2 RX input endpoint, but not the other endpoints in > > > the pipeline. > > > > This doesn't yet explain why the sensor would need to implement > > get_mbus_config if its bus configuration remains constant. > > If I recall correctly, the IPU driver calls .g_mbus_config() on the > camera sensor to get the number of lanes, as it can't get it from its > own endpoint. That's a hack, and as Jacopo proposed, calling > .g_mbus_config() on the CSI-2 RX would be better, as the CSI-2 RX driver > can then get the value from its own endpoint, without requiring all > sensor drivers to implement .g_mbus_config().
The g_mbus_config op could be implemented by the CSI2IPU and mux, by simply requesting the information from the upstream sub-device. No hacks would be needed.
-- Kind regrads,
Sakari Ailus
| |