[PATCH 02/10] dt-bindings: display: imx: Add i.MX8qxp Display Controller display engine

[Krzysztof Kozlowski]

On 08/07/2024 16:52, Maxime Ripard wrote:
> On Mon, Jul 08, 2024 at 04:04:21PM GMT, Krzysztof Kozlowski wrote:
>> On 08/07/2024 08:40, Liu Ying wrote:
>>>>> +
>>>>> +  "^framegen@[0-9a-f]+$":
>>>>> +    type: object
>>>>> +    additionalProperties: true
>>>>> +
>>>>> +    properties:
>>>>> +      compatible:
>>>>> +        const: fsl,imx8qxp-dc-framegen
>>>>> +
>>>>> +  "^gammacor@[0-9a-f]+$":
>>>>
>>>> This looks like you are organizing bindings per your driver architecture.
>>>
>>> As I mentioned in cover letter, this series addresses Maxime's
>>> comment for the previous series - split the display controller
>>> into multiple internal devices.  Maxime insisted on doing this.
>>
>> But these are not separate devices. Look:
>> 1. parent DC:
>> reg = <0x56180000 0x40000>;
>>
>> 2. child interrupt controller:
>> reg = <0x56180040 0x60>;
>>
>> That address is within parent.
>>
>> 3. Then we go to things like:
>> reg = <0x5618b400 0x14>, <0x5618b800 0x1c00>;
>>
>> Still within parent's range and just few words in address range. That's
>> a clear indication that you choose few registers and call it a "device".
> 
> That's never really been a metric though?
> 
> If not, one could just create a "soc" device node covering the entire
> register map, and since it would overlap despite clearly defined
> features, you would claim it's a single device?

Since I do not create such one-address-soc devices, I claim I have
separate devices in the SoC. Here is not the case: there is a device
covering entire address space.

Soc is a good example, because components/blocks of the SoC are being
re-used among different SoCs. Is the case here?

BTW, it could be that some of the sub-devices here are worth to be
devices, I agree.

Best regards,
Krzysztof