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@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx 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.
