Hi Maxime,
On 24/03/2022 16:23, Maxime Ripard wrote:
On Thu, Mar 24, 2022 at 03:43:42PM +0200, Laurent Pinchart wrote:
On Thu, Mar 24, 2022 at 09:18:19AM +0100, Maxime Ripard wrote:
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.
Those are different, there's no data stream independent of the control
communications.
Fine, then you have Ethernet PHYs, or any MMIO device that does DMA.
Have those devices had the need for OF graphs? For display and capture
we have a clear need. I don't think we should sometimes use OF graphs
and sometimes not, but rather use them consistently at least in any new
driver.
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.
It's here, and I think we should move away from it for new DSI sinks.
I'd like OF graph to be used consistently for new drivers. We can't
change existing DT bindings and drivers to drop support for the
non-OF-graph description due to ABI stability, but we can avoid
repeating the mistake going forward.
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.
I don't think that's the issue at hand here. You can still use a
non-OF-graph DT event if the nodes for the two bridges affected by this
patch define a port@0. It can just be left unconnected.
I do agree it will cause some DT bindings for DCS-based DSI sinks to
have ports will others won't. If your concern is that all DT bindings
should be coherent, would you be OK with a patch that makes the sink
port mandatory in all DT bindings for DSI bridges and panels (and fixes
the mainline DT sources accordingly to make sure they validate) ? The
port would not be connected of course (at least when used with DSI
source drivers that don't use OF graph today). That would make DT
bindings coherent, and would be a first step towards using OF graph
everywhere.
I'm trying to fix a (recent) mistake/cargo-cult in new bindings. That
discussion is not going to be fairly controversial and I don't see how
that can be solved quickly. So, as a second step, why not. But this one
needs to come first.
I feel like I don't quite understand the problem and the discussion.
What's the problem this fixes? DT validation? Why not just fix the dts
files which use these devices (although I didn't see any in mainline),
by adding the port nodes?
Or is the argument that we should also support "implicit ports" when the
control and data busses are the same?
Tomi
