[PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Tomi Valkeinen]

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 at 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