Messages in this thread | | | Date | Fri, 20 Jan 2023 10:28:48 +0530 | Subject | Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel | From | Aradhya Bhatia <> |
| |
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@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@ti.com> >>>> + - Thierry Reding <thierry.reding@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@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@0 { >>> ..... >>> -> dual-lvds-odd-pixels <- >>> } >>> >>> port@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
| |