[PATCH v1 2/5] dt-bindings: soc: hpe: Add hpe,gxp-plreg

[Krzysztof Kozlowski]

On 25/10/2022 15:39, Verdun, Jean-Marie wrote:
> Hi Krzysztof,
> 
> I think what we try to do is to introduce an abstraction layer between the interfaces and the drivers, as our CPLD interfaces are platform dependents. I mean the Power On control could be at address 0x09 on one platform or 0x119 on another one. We would like to find a way to avoid to have to change the driver code, but just feeding the driver with relevant datas, which could be into a platform dependent include file or through the proposed solution that Nick is promoting.
> 
> If the CPLD memory address space was consistent between platform and generation that would be great but unfortunately that is not the case that is why we try to break down the dependency into the driver code and retrieve the data from another place.
> 
> JM
> ________________________________
> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Sent: Tuesday, October 25, 2022 12:33 PM
> To: Hawkins, Nick <nick.hawkins at hpe.com>
> Cc: Verdun, Jean-Marie <verdun at hpe.com>; krzysztof.kozlowski+dt at linaro.org <krzysztof.kozlowski+dt at linaro.org>; linux at armlinux.org.uk <linux at armlinux.org.uk>; devicetree at vger.kernel.org <devicetree at vger.kernel.org>; linux-kernel at vger.kernel.org <linux-kernel at vger.kernel.org>; linux-arm-kernel at lists.infradead.org <linux-arm-kernel at lists.infradead.org>; Rob Herring <robh+dt at kernel.org>
> Subject: Re: [PATCH v1 2/5] dt-bindings: soc: hpe: Add hpe,gxp-plreg
> 
> On 25/10/2022 15:26, Hawkins, Nick wrote:
>>
>>> I don't know exactly what type of devices you represent in that plreg, but in general the fan device would be the respective plreg. The same with other pieces like hwmon, power supply.
>> We were primarily representing the registers that translate to the CPLD input/outputs from our platforms as well as handling the interrupts associated with those inputs/outputs.
> 
> So basically each register (or set of registers) is a device? How is it
> different than any other multi-functional device? Why do you want to
> model it differently?

How is it different, I am asking?

> 
>> When you say "would be the respective plreg" do you mean that each device/controller would need to perform the actions plreg does individually? In that case how should we get information for that register/memory region and interrupts from the dts? Could it be something like this:
>>
>> plreg: plreg at d1000000 {
>>       compatible = "hpe,gxp-plreg";
>>       reg = <0xd1000000 0xFF>;
>>       interrupts = <26>;
>>       interrupt-parent = <&vic0>;
>> };
>>
>> fanctrl: fanctrl at c1000c00 {
>>       compatible = "hpe,gxp-fan-ctrl";
>>       reg = <0xc1000c00 0x200>;
>>       plreg_handle = <&plreg>;
>> };
>>
> 
> No, rather these are one node.
> 
> You insist to represent this all as programmable logic, but why? CPLD,
> FPGA, ASIC, dedicated IC - all are just implementations and for us
> what's matter are the interfaces, inputs and outputs.


And seriously... this is not a chat. Take a bit of time to answer these
questions instead of replying immediately with a same response as yesterday.

Best regards,
Krzysztof