On Wed, Mar 23, 2022 at 10:38:19PM +0200, Laurent Pinchart wrote: > Hi Maxime, > > (CC'ing Sakari) > > Thank you for the patch. > > On Wed, Mar 23, 2022 at 04:48:23PM +0100, Maxime Ripard wrote: > > MIPI-DSI devices, if they are controlled through the bus itself, have to > > be described as a child node of the controller they are attached to. > > > > Thus, there's no requirement on the controller having an OF-Graph output > > port to model the data stream: it's assumed that it would go from the > > parent to the child. > > > > However, some bridges controlled through the DSI bus still require an > > input OF-Graph port, thus requiring a controller with an OF-Graph output > > port. This prevents those bridges from being used with the controllers > > that do not have one without any particular reason to. > > > > Let's drop that requirement. > > I'm sure this won't come as a surprise, I'm very much opposed to this > change, for two reasons. > > First, ports are part of the hardware, even if they're not connected. It > thus simplifies handling in drivers if they're always present. > > Then, and that's the most important reason, I think it's a mistake not > to model the DSI data connection using OF graph unconditionally, even > when the DSI sink device is also controlled through the DSI bus (using > DCS) and is in that case a child of the DSI source device in the DT > hierarchy. That's the way we do for any other device though. You never addressed that comment, but it's very much the same that occurs for i2c or spi controllers and their device. They all get their data from the parent bus. I don't see you advocate for using OF-Graph for those devices. > The device tree describes a control hierarchy between devices. OF graph > overlays on top of that a data transfer graph. The two are different > concepts, and the fact that DSI can sometimes be used as a control bus > doesn't change the concept. Using OF graph unconditionally to describe > the data connections for DSI leads to less variation in the device tree > structure, and thus less complexity in the implementation. We're > suffering from the fact we haven't made it a requirement in the first > place, which can't be fixed due to ABI breakage constraints, but let's > not acknowledge it as a good idea. Honestly, it doesn't matter one bit. We have a huge discrepancy here today, and only a couple of bridges have that arbitrary restriction. The situation you don't want to acknowledge is the de-facto standard, by the generic binding and by what all the bridges and panels are implementing. Even panel-simple-dsi is doing it. So it's very much there already. What I'm trying to address here is that some controllers that do everything right can't be used because that restriction is completely arbitrary and in opposition to the consensus. And they can't be used *today*. If we want to change that consensus, fine, but we should still have one. Having some bridges enforcing custom rules for no reason is very much unacceptable. And changing that consensus won't happen overtime, we'll have to take care of the backward compatibility, etc. So it won't fix the issue that we can't use any bridge with any controller any time soon. Maxime
Attachment:
signature.asc
Description: PGP signature
