[RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel
Aradhya Bhatia
a-bhatia1 at ti.com
Thu Jan 19 20:58:48 PST 2023
Hi Tomi,
Thank you for taking a look at the patches!
On 17-Jan-23 18:08, Tomi Valkeinen wrote:
> On 09/01/2023 18:21, Aradhya Bhatia wrote:
>> Hi Angelo,
>>
>> Thanks for taking a look at the patches!
>>
>> On 03-Jan-23 17:21, AngeloGioacchino Del Regno wrote:
>>> Il 03/01/23 07:46, Aradhya Bhatia ha scritto:
>>>> Dual-link LVDS interfaces have 2 links, with even pixels traveling on
>>>> one link, and odd pixels on the other. These panels are also generic in
>>>> nature, with no documented constraints, much like their single-link
>>>> counterparts, "panel-lvds".
>>>>
>>>> Add a new compatible, "panel-dual-lvds", and a dt-binding document for
>>>> these panels.
>>>>
>>>> Signed-off-by: Aradhya Bhatia <a-bhatia1 at ti.com>
>>>> ---
>>>> .../display/panel/panel-dual-lvds.yaml | 157
>>>> ++++++++++++++++++
>>>> MAINTAINERS | 1 +
>>>> 2 files changed, 158 insertions(+)
>>>> create mode 100644
>>>> Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>>> new file mode 100644
>>>> index 000000000000..88a7aa2410be
>>>> --- /dev/null
>>>> +++
>>>> b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>>> @@ -0,0 +1,157 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/display/panel/panel-dual-lvds.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Generic Dual-Link LVDS Display Panel
>>>> +
>>>> +maintainers:
>>>> + - Aradhya Bhatia <a-bhatia1 at ti.com>
>>>> + - Thierry Reding <thierry.reding at gmail.com>
>>>> +
>>>> +description: |
>>>> + A dual-LVDS interface is a dual-link connection with the even pixels
>>>> + traveling on one link, and the odd pixels traveling on the other.
>>>> +
>>>> +allOf:
>>>> + - $ref: panel-common.yaml#
>>>> + - $ref: /schemas/display/lvds.yaml/#
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + oneOf:
>>>> + - items:
>>>> + - enum:
>>>> + - lincolntech,lcd185-101ct
>>>> + - microtips,13-101hieb0hf0-s
>>>> + - const: panel-dual-lvds
>>>> + - const: panel-dual-lvds
>>>> +
>>>> + ports:
>>>> + $ref: /schemas/graph.yaml#/properties/ports
>>>> +
>>>> + properties:
>>>> + port at 0:
>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>> + unevaluatedProperties: false
>>>> + description: The sink for first set of LVDS pixels.
>>>> +
>>>> + properties:
>>>> + dual-lvds-odd-pixels:
>>>> + type: boolean
>>>> +
>>>> + dual-lvds-even-pixels:
>>>> + type: boolean
>>>> +
>>>> + oneOf:
>>>> + - required: [dual-lvds-odd-pixels]
>>>
>>> One question: why do we need a "panel-dual-lvds" compatible?
>>> A Dual-LVDS panel is a LVDS panel using two ports, hence still a
>>> panel-lvds.
>>>
>>> If you're doing this to clearly distinguish, for human readability purposes,
>>> single-link vs dual-link panels, I think that this would still be clear even
>>> if we use panel-lvds alone because dual-link panels, as you wrote in this
>>> binding, does *require* two ports, with "dual-lvds-{odd,even}-pixels" properties.
>>
>> Yes, while they are both LVDS based panels the extra LVDS sink in these
>> panels, and the capability to decode and display the 2 sets of signals
>> are enough hardware differences that warrant for an addition of a new
>> compatible.
>>
>>>
>>> So... the devicetree node would look like this:
>>>
>>> panel {
>>> compatible = "vendor,panel", "panel-lvds";
>>> ....
>>> ports {
>>> port at 0 {
>>> .....
>>> -> dual-lvds-odd-pixels <-
>>> }
>>>
>>> port at 1 {
>>> .....
>>> -> dual-lvds-even-pixels <-
>>> };
>>> };
>>> };
>>>
>>>> + - required: [dual-lvds-even-pixels]
>>>
>>> ...Though, if you expect dual-lvds panels to get other quirks in the future,
>>> that's a whole different story and you may actually need the panel-dual-lvds
>>> compatible.
>>
>> Yes, exactly. Even while being non-smart, there are going to be more
>> quirks in future. And it would be better if they have their own
>> compatible/binding, and are not getting appended in an ever-growing
>> if-else ladder. :)
>
> I can imagine a panel which you can use with a single LVDS link if the
> clock is high enough, or two LVDS links if the clock has to be lower. Is
> that a dual-lvds panel? =)
Hmm, I can see what you are saying here.
If one wants to run a dual-link panel, with 1 link (given enough clock
frequency), then the bindings here will *not* allow for a single port
with the odd/even properties absent.
In such a case, the compatible will indeed need to be changed to
"panel-lvds".
While it does feel a tad bit odd, I believe it is still worth
maintaining the clarity and HW differences between the single and dual
link panels. :)
>
> But probably that situation is no different than a panel that can work
> with DSI or DPI input.
>
> Still, I'm agree with Angelo in that a new compatible string for dual
> link lvds feels a bit odd. That said, it's possible the panel-lvds > bindings might get rather confusing. So I don't have a strong feeling
here.
Regards
Aradhya
More information about the linux-riscv
mailing list