[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dc8181d9-c7c9-4817-96f1-84a1b64575d6@microchip.com>
Date: Thu, 29 Feb 2024 06:25:56 +0000
From: <Dharma.B@...rochip.com>
To: <krzysztof.kozlowski@...aro.org>, <maarten.lankhorst@...ux.intel.com>,
<mripard@...nel.org>, <tzimmermann@...e.de>, <airlied@...il.com>,
<daniel@...ll.ch>, <robh+dt@...nel.org>, <krzysztof.kozlowski+dt@...aro.org>,
<conor+dt@...nel.org>, <Nicolas.Ferre@...rochip.com>,
<alexandre.belloni@...tlin.com>, <claudiu.beznea@...on.dev>
CC: <dri-devel@...ts.freedesktop.org>, <devicetree@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dt-bindings: display: atmel,lcdc: convert to dtschema
On 28/02/24 3:53 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On 28/02/2024 11:18, Dharma.B@...rochip.com wrote:
>> On 28/02/24 12:43 pm, Krzysztof Kozlowski wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On 28/02/2024 07:59, Dharma.B@...rochip.com wrote:
>>>>
>>>>>
>>>>> I don't know what's this exactly, but if embedded display then maybe
>>>>> could be part of this device node. If some other display, then maybe you
>>>>> need another schema, with compatible? But first I would check how others
>>>>> are doing this.
>>>>
>>>> Okay, then I think the driver also needs to be modified, currently the
>>>> driver parses the phandle and looks for these properties. Also the
>>>> corresponding dts files.
>>>
>>> Driver does not have to be modified in my proposal. You would still have
>>> phandle.
>>
>> If I understand correctly, I could define the dt bindings as below
>>
>> display:
>> $ref: /schemas/types.yaml#/definitions/phandle
>> description: A phandle pointing to the display node.
>>
>> panel:
>> $ref: panel/panel-common.yaml#
>> properties:
>>
>
> So these are standard panel bindings? Then the node should live outside
> of lcdc. If current driver needs to poke inside panel and panel could be
> anything, then probably you need peripheral-props-like approach. :/
Thank you so much, so can I use something like this
display:
$ref: /schemas/types.yaml#/definitions/phandle
description: A phandle pointing to the display node.
patternProperties:
"^panel":
type: object
properties:
atmel,dmacon:
atmel,lcdcon2:
:
:
required:
- atmel,dmacon
- atmel,lcdcon2
- atmel,guard-time
- bits-per-pixel
additionalProperties: false
I tested it by removing the required property in the panel node and it
flagged it as an issue.
>
> Best regards,
> Krzysztof
>
--
With Best Regards,
Dharma B.
Powered by blists - more mailing lists