Hi Sakari, On Tue, 2020-06-02 at 12:56 +0300, Sakari Ailus wrote: > Hi Dongchun, > > On Tue, Jun 02, 2020 at 02:15:01PM +0800, Dongchun Zhu wrote: > > Hi Tomasz, Sakari, > > > > On Mon, 2020-06-01 at 20:18 +0200, Tomasz Figa wrote: > > > On Mon, Jun 1, 2020 at 4:35 AM Dongchun Zhu <dongchun.zhu@xxxxxxxxxxxx> wrote: > > > > > > > > Hi Tomasz, > > > > > > > > On Fri, 2020-05-29 at 15:43 +0200, Tomasz Figa wrote: > > > > > On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu <dongchun.zhu@xxxxxxxxxxxx> wrote: > > > > > > > > > > > > Hi Sakari, > > > > > > > > > > > > On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote: > > > > > > > Hi Dongchun, > > > > > > > > > > > > > > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote: > > > > > > > > Hi Sakari, Rob, > > > > > > > > > > > > > > > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote: > > > > > > > > > Hi Rob, Dongchun, > > > > > > > > > > > > > > > > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote: > > > > > > > > > > > > > + properties: > > > > > > > > > > > > > + endpoint: > > > > > > > > > > > > > + type: object > > > > > > > > > > > > > + additionalProperties: false > > > > > > > > > > > > > + > > > > > > > > > > > > > + properties: > > > > > > > > > > > > > > > > > > > > > > Actually I wonder whether we need to declare 'clock-lanes' here? > > > > > > > > > > > > > > > > > > > > Yes, if you are using it. > > > > > > > > > > > > > > > > > > Dongchun, can you confirm the chip has a single data and a single clock > > > > > > > > > lane and that it does not support lane reordering? > > > > > > > > > > > > > > > > > > > > > > > > > From the datasheet, 'MIPI inside the OV02A10 provides one single > > > > > > > > uni-directional clock lane and one bi-directional data lane solution for > > > > > > > > communication links between components inside a mobile device. > > > > > > > > The data lane has full support for HS(uni-directional) and > > > > > > > > LP(bi-directional) data transfer mode.' > > > > > > > > > > > > > > > > The sensor doesn't support lane reordering, so 'clock-lanes' property > > > > > > > > would not be added in next release. > > > > > > > > > > > > > > > > > So if there's nothing to convey to the driver, also the data-lanes should > > > > > > > > > be removed IMO. > > > > > > > > > > > > > > > > > > > > > > > > > However, 'data-lanes' property may still be required. > > > > > > > > It is known that either data-lanes or clock-lanes is an array of > > > > > > > > physical data lane indexes. Position of an entry determines the logical > > > > > > > > lane number, while the value of an entry indicates physical lane, e.g., > > > > > > > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming > > > > > > > > the clock lane is on hardware lane 0. > > > > > > > > > > > > > > > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not > > > > > > > > support lane reordering, so here we shall use 'data-lanes = <1>' as > > > > > > > > there is only a clock lane for OV02A10. > > > > > > > > > > > > > > > > Reminder: > > > > > > > > If 'data-lanes' property is not present, the driver would assume > > > > > > > > four-lane operation. This means for one-lane or two-lane operation, this > > > > > > > > property must be present and set to the right physical lane indexes. > > > > > > > > If the hardware does not support lane reordering, monotonically > > > > > > > > incremented values shall be used from 0 or 1 onwards, depending on > > > > > > > > whether or not there is also a clock lane. > > > > > > > > > > > > > > How can the driver use four lanes, considering the device only supports a > > > > > > > single lane?? > > > > > > > > > > > > > > > > > > > I understood your meaning. > > > > > > If we omit the property 'data-lanes', the sensor should work still. > > > > > > But then what's the meaning of the existence of 'data-lanes'? > > > > > > If this property 'data-lanes' is always optional, then why dt-bindings > > > > > > provide the interface? > > > > > > > > > > > > In the meantime, if omitting 'data-lanes' for one sensor(transmitter) > > > > > > that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2) > > > > > > shall enable four-lane configuration, which may increase consumption of > > > > > > both power and resource in the process of IIC communication. > > > > > > > > > > Wouldn't the receiver still have the data-lanes property under its > > > > > endpoint node, telling it how many lanes and in which order should be > > > > > used? > > > > > > > > > > > > > The MIPI receiver(RX) shall use > > > > v4l2_async_notifier_add_fwnode_remote_subdev() API to parse the property > > > > "data-lanes" under sensor output port. > > > > > > That's not true. The MIPI receiver driver parses its own port node > > > corresponding to the sensor. Also quoting the documentation [1]: > > > > > > "An endpoint subnode of a device contains all properties needed for > > > _configuration of this device_ for data exchange with other device. In most > > > cases properties at the peer 'endpoint' nodes will be identical, however they > > > might need to be different when there is any signal modifications on the bus > > > between two devices, e.g. there are logic signal inverters on the lines." > > > > > > In this case, there is such a signal modification if the sensor has a > > > 1-lane bus and the receiver more lines, so the data-lanes properties > > > would be different on both sides. > > > > > > [1] https://elixir.bootlin.com/linux/v5.7/source/Documentation/devicetree/bindings/media/video-interfaces.txt > > > > > > > Sorry for the misunderstanding. > > After doing some experiments about the data-lanes property under sensor > > i2c node, we found the API > > v4l2_async_notifier_add_fwnode_remote_subdev() that MIPI receiver driver > > used indeed parses the data-lanes under its own port node. > > > > Sorry make a mistake for the use case of sensor data-lanes previously. > > Now We may encounter one new question for this patch. > > In practice we haven't used the data-lanes under sensor i2c node > > anywhere, if sensor driver itself doesn't parse that. > > > > But there is still one reason to keep the exactly right data-lanes in > > DT. That is, the data-lanes under sensor i2c node could be used as a > > reference for MIPI receiver driver. > > Just as Tomasz said, 'The MIPI receiver driver parses its own port node > > corresponding to the sensor'. > > > > Sakari, Tomasz, what's your opinions about the present of data-lanes > > under sensor node or not? > > The receiver driver doesn't parse the properties in the sensor > (transmitter) device's endpoint. If that property provides no information > to the receiver, as is the case here, it should be omitted. > Understood. Fixed in next release.
