Hi Sam, On 19/01/24 1:00 am, Sam Ravnborg wrote: > [You don't often get email from sam@xxxxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Hi Dharma et al. > > On Thu, Jan 18, 2024 at 02:56:09PM +0530, Dharma Balasubiramani wrote: >> Converted the text bindings to YAML and validated them individually using following commands >> >> $ make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ >> $ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ >> >> changelogs are available in respective patches. >> >> Dharma Balasubiramani (3): >> dt-bindings: display: convert Atmel's HLCDC to DT schema >> dt-bindings: atmel,hlcdc: convert pwm bindings to json-schema >> dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format > > I know this is a bit late to ask - sorry in advance. > > The binding describes the single IP block as a multi functional device, > but it is a single IP block that includes the display controller and a > simple pwm that can be used for contrast or backlight. yes. > > If we ignore the fact that the current drivers for hlcdc uses an mfd > abstraction, is this then the optimal way to describe the HW? > > > In one of my stale git tree I converted atmel lcdc to DT, and here Are you referring the "bindings/display/atmel,lcdc.txt"? > I used: > > + "#pwm-cells": > + description: > + This PWM chip use the default 3 cells bindings > + defined in ../../pwm/pwm.yaml. > + const: 3 > + > + clocks: > + maxItems: 2 > + > + clock-names: > + maxItems: 2 > + items: > + - const: lcdc_clk > + - const: hclk > > This proved to be a simple way to describe the HW. > > To make the DT binding backward compatible you likely need to add a few > compatible that otherwise would have been left out - but that should do > the trick. again you mean the compatibles from atmel,lcdc binding? > > The current atmel hlcdc driver that is split in three is IMO an > over-engineering, and the driver could benefit merging it all in one. > And the binding should not prevent this. could you please confirm if my understanding is correct: you want a unified display binding that encompasses the properties of the two subdevices (display controller and pwm), eliminating the need to reference them in additional bindings? > > Sam -- With Best Regards, Dharma B.
