[2/5] dt-bindings: mfd: syscon: Add ti,am62-ddr-pmctrl

Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
register in the wkup-conf register space of am62a and am62p. This
register controls DDR power management.

Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
---
 Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
 1 file changed, 2 insertions(+)

On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
> register in the wkup-conf register space of am62a and am62p. This
> register controls DDR power management.
> 
> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> ---
>  Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
> > Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
> > register in the wkup-conf register space of am62a and am62p. This
> > register controls DDR power management.
> > 
> > Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> > ---
> >  Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
> 
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Un-acked, I missed the point that you really speak in commit msg about
register and you really treat one register is a device. I assumed you
only need that register from this device, but no. That obviously is not
what this device is. Device is not a single register among 10000 others.
IOW, You do not have 10000 devices there.

So:

NAK

Best regards,
Krzysztof

Hi Krzysztof,

On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
> > On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
> > > Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
> > > register in the wkup-conf register space of am62a and am62p. This
> > > register controls DDR power management.
> > > 
> > > Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> > > ---
> > >  Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
> > >  1 file changed, 2 insertions(+)
> > 
> > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> Un-acked, I missed the point that you really speak in commit msg about
> register and you really treat one register is a device. I assumed you
> only need that register from this device, but no. That obviously is not
> what this device is. Device is not a single register among 10000 others.
> IOW, You do not have 10000 devices there.

Do I understand you correctly that the whole register range of the
wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
should be considered a single syscon device?

Unfortunately wkup_conf is modeled as a simple-bus with currently 5
subnodes defined of which 4 of them consist of a single register. Most
of them are syscon as well. So I think I can't change the simple-bus
back to syscon.

For the DDR pmctrl, this really only consist of a single register, the
registers surrounding this pmctrl are not related as far as I can tell.

What do you suggest how I can solve this?

Best
Markus
> 
> So:
> 
> NAK
> 
> Best regards,
> Krzysztof
>

On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
> Hi Krzysztof,
> 
> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
>>>> register in the wkup-conf register space of am62a and am62p. This
>>>> register controls DDR power management.
>>>>
>>>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>
>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>
>> Un-acked, I missed the point that you really speak in commit msg about
>> register and you really treat one register is a device. I assumed you
>> only need that register from this device, but no. That obviously is not
>> what this device is. Device is not a single register among 10000 others.
>> IOW, You do not have 10000 devices there.
> 
> Do I understand you correctly that the whole register range of the
> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
> should be considered a single syscon device?

I don't have the datasheets (and not my task to actually check this),
but you should probably follow datasheet. I assume it describes what is
the device, more or less.

I assume entire wkup_conf is considered a device.

> 
> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
> subnodes defined of which 4 of them consist of a single register. Most
> of them are syscon as well. So I think I can't change the simple-bus
> back to syscon.

Huh... Maybe TI folks will help us understand why such design was chosen.

> 
> For the DDR pmctrl, this really only consist of a single register, the
> registers surrounding this pmctrl are not related as far as I can tell.

DDR pmctrl does not fit definition of syscon then. Syscon is a
*collection* of miscellaneous registers. Most likely the entire block is
that collection and someone decided - oh but I want syscon per each
register. Awesome. And then what if someone wants two registers, but
there are spread apart and in the middle is someone else?

| ddr pmctrl 1 | something else | ddr pmctrl 2 |

Two syscons?

And what if you have three registers? What if four? You see where it is
getting at?


> 
> What do you suggest how I can solve this?

I have no clue how the device actually looks like, so tricky to give
answer, but I could imagine total node rework, calling everything
syscon+mfd. This would still be backwards compatible.

Or adding one new block covering remaining parts of the device, so at
least people stop adding 1000 new syscons per each register, because
there will be just one.

Best regards,
Krzysztof

On 1/24/25 10:48 AM, Krzysztof Kozlowski wrote:
> On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
>> Hi Krzysztof,
>>
>> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
>>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
>>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
>>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
>>>>> register in the wkup-conf register space of am62a and am62p. This
>>>>> register controls DDR power management.
>>>>>
>>>>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
>>>>> ---
>>>>>   Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>>>>>   1 file changed, 2 insertions(+)
>>>>
>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>
>>> Un-acked, I missed the point that you really speak in commit msg about
>>> register and you really treat one register is a device. I assumed you
>>> only need that register from this device, but no. That obviously is not
>>> what this device is. Device is not a single register among 10000 others.
>>> IOW, You do not have 10000 devices there.
>>
>> Do I understand you correctly that the whole register range of the
>> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
>> should be considered a single syscon device?
> 
> I don't have the datasheets (and not my task to actually check this),
> but you should probably follow datasheet. I assume it describes what is
> the device, more or less.
> 
> I assume entire wkup_conf is considered a device.
> 
>>
>> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
>> subnodes defined of which 4 of them consist of a single register. Most
>> of them are syscon as well. So I think I can't change the simple-bus
>> back to syscon.
> 
> Huh... Maybe TI folks will help us understand why such design was chosen.
> 

Many of the devices inside the wkup_conf are already modeled as such.
Clocks and muxes for instance already have drivers and bindings, this
is nothing new to TI.

If we just use a blank "syscon" over the entire region we would end up
with drivers that use phandles to the top level wkup_conf node and
poke directly the registers they need from that space.

Would you rather have

some-device {
	ti,epwm_tbclk = <&wkup_conf>;
}

or

some-device {
	clocks = <&epwm_tbclk 0>;
}

with that epwm_tbclk being a proper clock node inside wkup_conf?
I would much prefer the second, even though the clock node
only uses a single register. And in the first case, we would need
to have the offset into the wkup_conf space hard-coded in the
driver for each new SoC. Eventually all that data would need to be
put in tables and we end up back to machine board files..

I'm not saying every magic number in all drivers should
be offloaded into DT, but there is a line somewhere between
that and having the DT simply contain the SoC's name compatible
and all other data going into the kernel. That line might be a
personal preference, so my question back is: what is wrong
if we do want "1000 new syscons per each register" for our
SoCs DT?

(and the number is not 1000, scanning the kernel I can see
the largest wkup_conf region node we have today has a grand
total number sub-nodes of 6)

Andrew

>>
>> For the DDR pmctrl, this really only consist of a single register, the
>> registers surrounding this pmctrl are not related as far as I can tell.
> 
> DDR pmctrl does not fit definition of syscon then. Syscon is a
> *collection* of miscellaneous registers. Most likely the entire block is
> that collection and someone decided - oh but I want syscon per each
> register. Awesome. And then what if someone wants two registers, but
> there are spread apart and in the middle is someone else?
> 
> | ddr pmctrl 1 | something else | ddr pmctrl 2 |
> 
> Two syscons?
> 
> And what if you have three registers? What if four? You see where it is
> getting at?
> 
> 
>>
>> What do you suggest how I can solve this?
> 
> I have no clue how the device actually looks like, so tricky to give
> answer, but I could imagine total node rework, calling everything
> syscon+mfd. This would still be backwards compatible.
> 
> Or adding one new block covering remaining parts of the device, so at
> least people stop adding 1000 new syscons per each register, because
> there will be just one.
> 
> Best regards,
> Krzysztof
>

On 24/01/2025 23:35, Andrew Davis wrote:
> On 1/24/25 10:48 AM, Krzysztof Kozlowski wrote:
>> On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
>>> Hi Krzysztof,
>>>
>>> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
>>>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
>>>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
>>>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
>>>>>> register in the wkup-conf register space of am62a and am62p. This
>>>>>> register controls DDR power management.
>>>>>>
>>>>>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
>>>>>> ---
>>>>>>   Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>>>>>>   1 file changed, 2 insertions(+)
>>>>>
>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>
>>>> Un-acked, I missed the point that you really speak in commit msg about
>>>> register and you really treat one register is a device. I assumed you
>>>> only need that register from this device, but no. That obviously is not
>>>> what this device is. Device is not a single register among 10000 others.
>>>> IOW, You do not have 10000 devices there.
>>>
>>> Do I understand you correctly that the whole register range of the
>>> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
>>> should be considered a single syscon device?
>>
>> I don't have the datasheets (and not my task to actually check this),
>> but you should probably follow datasheet. I assume it describes what is
>> the device, more or less.
>>
>> I assume entire wkup_conf is considered a device.
>>
>>>
>>> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
>>> subnodes defined of which 4 of them consist of a single register. Most
>>> of them are syscon as well. So I think I can't change the simple-bus
>>> back to syscon.
>>
>> Huh... Maybe TI folks will help us understand why such design was chosen.
>>
> 
> Many of the devices inside the wkup_conf are already modeled as such.
> Clocks and muxes for instance already have drivers and bindings, this
> is nothing new to TI.
> 
> If we just use a blank "syscon" over the entire region we would end up
> with drivers that use phandles to the top level wkup_conf node and
> poke directly the registers they need from that space.
> 
> Would you rather have
> 
> some-device {
> 	ti,epwm_tbclk = <&wkup_conf>;
> }
> 
> or
> 
> some-device {
> 	clocks = <&epwm_tbclk 0>;
> }

How is this comparable? These are clocks. You would have clocks property
in both cases.


> 
> with that epwm_tbclk being a proper clock node inside wkup_conf?
> I would much prefer the second, even though the clock node
> only uses a single register. And in the first case, we would need
> to have the offset into the wkup_conf space hard-coded in the
> driver for each new SoC. Eventually all that data would need to be
> put in tables and we end up back to machine board files..
> 
> I'm not saying every magic number in all drivers should
> be offloaded into DT, but there is a line somewhere between
> that and having the DT simply contain the SoC's name compatible

That's not the question here.

> and all other data going into the kernel. That line might be a
> personal preference, so my question back is: what is wrong
> if we do want "1000 new syscons per each register" for our
> SoCs DT?

Because it is false representation of hardware. You do not have 1000
devices. You have only one device.


> 
> (and the number is not 1000, scanning the kernel I can see
> the largest wkup_conf region node we have today has a grand
> total number sub-nodes of 6)

But what is being added here is device per each register, not per feature.


Best regards,
Krzysztof

Hi Krzysztof,

On Mon, Jan 27, 2025 at 01:09:49PM +0100, Krzysztof Kozlowski wrote:
> On 24/01/2025 23:35, Andrew Davis wrote:
> > On 1/24/25 10:48 AM, Krzysztof Kozlowski wrote:
> >> On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
> >>> Hi Krzysztof,
> >>>
> >>> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
> >>>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
> >>>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
> >>>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
> >>>>>> register in the wkup-conf register space of am62a and am62p. This
> >>>>>> register controls DDR power management.
> >>>>>>
> >>>>>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> >>>>>> ---
> >>>>>>   Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
> >>>>>>   1 file changed, 2 insertions(+)
> >>>>>
> >>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> >>>>
> >>>> Un-acked, I missed the point that you really speak in commit msg about
> >>>> register and you really treat one register is a device. I assumed you
> >>>> only need that register from this device, but no. That obviously is not
> >>>> what this device is. Device is not a single register among 10000 others.
> >>>> IOW, You do not have 10000 devices there.
> >>>
> >>> Do I understand you correctly that the whole register range of the
> >>> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
> >>> should be considered a single syscon device?
> >>
> >> I don't have the datasheets (and not my task to actually check this),
> >> but you should probably follow datasheet. I assume it describes what is
> >> the device, more or less.
> >>
> >> I assume entire wkup_conf is considered a device.
> >>
> >>>
> >>> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
> >>> subnodes defined of which 4 of them consist of a single register. Most
> >>> of them are syscon as well. So I think I can't change the simple-bus
> >>> back to syscon.
> >>
> >> Huh... Maybe TI folks will help us understand why such design was chosen.
> >>
> > 
> > Many of the devices inside the wkup_conf are already modeled as such.
> > Clocks and muxes for instance already have drivers and bindings, this
> > is nothing new to TI.
> > 
> > If we just use a blank "syscon" over the entire region we would end up
> > with drivers that use phandles to the top level wkup_conf node and
> > poke directly the registers they need from that space.
> > 
> > Would you rather have
> > 
> > some-device {
> > 	ti,epwm_tbclk = <&wkup_conf>;
> > }
> > 
> > or
> > 
> > some-device {
> > 	clocks = <&epwm_tbclk 0>;
> > }
> 
> How is this comparable? These are clocks. You would have clocks property
> in both cases.
> 
> 
> > 
> > with that epwm_tbclk being a proper clock node inside wkup_conf?
> > I would much prefer the second, even though the clock node
> > only uses a single register. And in the first case, we would need
> > to have the offset into the wkup_conf space hard-coded in the
> > driver for each new SoC. Eventually all that data would need to be
> > put in tables and we end up back to machine board files..
> > 
> > I'm not saying every magic number in all drivers should
> > be offloaded into DT, but there is a line somewhere between
> > that and having the DT simply contain the SoC's name compatible
> 
> That's not the question here.
> 
> > and all other data going into the kernel. That line might be a
> > personal preference, so my question back is: what is wrong
> > if we do want "1000 new syscons per each register" for our
> > SoCs DT?
> 
> Because it is false representation of hardware. You do not have 1000
> devices. You have only one device.
> 
> 
> > 
> > (and the number is not 1000, scanning the kernel I can see
> > the largest wkup_conf region node we have today has a grand
> > total number sub-nodes of 6)
> 
> But what is being added here is device per each register, not per feature.

The register layout is like this:

0x8010 - 0x803c contains 4 clockselect registers
0x80d0 is the DDR16SS_PMCTRL regsiter
0x8190 - 0x8600 contains another 7 clockselect registers

I see the feature here in the block being clockselect registers. But the
ddr-pmctrl register doesn't fit into this so I opted to describe this
single register as one node as it looked to me like one feature. Of
course I would have preferred this to be different but it is not. Would
you prefer the clockselect registers and the pmctrl register to be
described as one syscon?

Best
Markus

On 07/02/2025 15:40, Markus Schneider-Pargmann wrote:
> Hi Krzysztof,
> 
> On Mon, Jan 27, 2025 at 01:09:49PM +0100, Krzysztof Kozlowski wrote:
>> On 24/01/2025 23:35, Andrew Davis wrote:
>>> On 1/24/25 10:48 AM, Krzysztof Kozlowski wrote:
>>>> On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
>>>>> Hi Krzysztof,
>>>>>
>>>>> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
>>>>>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
>>>>>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
>>>>>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
>>>>>>>> register in the wkup-conf register space of am62a and am62p. This
>>>>>>>> register controls DDR power management.
>>>>>>>>
>>>>>>>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
>>>>>>>> ---
>>>>>>>>   Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>>>>>>>>   1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>>>
>>>>>> Un-acked, I missed the point that you really speak in commit msg about
>>>>>> register and you really treat one register is a device. I assumed you
>>>>>> only need that register from this device, but no. That obviously is not
>>>>>> what this device is. Device is not a single register among 10000 others.
>>>>>> IOW, You do not have 10000 devices there.
>>>>>
>>>>> Do I understand you correctly that the whole register range of the
>>>>> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
>>>>> should be considered a single syscon device?
>>>>
>>>> I don't have the datasheets (and not my task to actually check this),
>>>> but you should probably follow datasheet. I assume it describes what is
>>>> the device, more or less.
>>>>
>>>> I assume entire wkup_conf is considered a device.
>>>>
>>>>>
>>>>> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
>>>>> subnodes defined of which 4 of them consist of a single register. Most
>>>>> of them are syscon as well. So I think I can't change the simple-bus
>>>>> back to syscon.
>>>>
>>>> Huh... Maybe TI folks will help us understand why such design was chosen.
>>>>
>>>
>>> Many of the devices inside the wkup_conf are already modeled as such.
>>> Clocks and muxes for instance already have drivers and bindings, this
>>> is nothing new to TI.
>>>
>>> If we just use a blank "syscon" over the entire region we would end up
>>> with drivers that use phandles to the top level wkup_conf node and
>>> poke directly the registers they need from that space.
>>>
>>> Would you rather have
>>>
>>> some-device {
>>> 	ti,epwm_tbclk = <&wkup_conf>;
>>> }
>>>
>>> or
>>>
>>> some-device {
>>> 	clocks = <&epwm_tbclk 0>;
>>> }
>>
>> How is this comparable? These are clocks. You would have clocks property
>> in both cases.
>>
>>
>>>
>>> with that epwm_tbclk being a proper clock node inside wkup_conf?
>>> I would much prefer the second, even though the clock node
>>> only uses a single register. And in the first case, we would need
>>> to have the offset into the wkup_conf space hard-coded in the
>>> driver for each new SoC. Eventually all that data would need to be
>>> put in tables and we end up back to machine board files..
>>>
>>> I'm not saying every magic number in all drivers should
>>> be offloaded into DT, but there is a line somewhere between
>>> that and having the DT simply contain the SoC's name compatible
>>
>> That's not the question here.
>>
>>> and all other data going into the kernel. That line might be a
>>> personal preference, so my question back is: what is wrong
>>> if we do want "1000 new syscons per each register" for our
>>> SoCs DT?
>>
>> Because it is false representation of hardware. You do not have 1000
>> devices. You have only one device.
>>
>>
>>>
>>> (and the number is not 1000, scanning the kernel I can see
>>> the largest wkup_conf region node we have today has a grand
>>> total number sub-nodes of 6)
>>
>> But what is being added here is device per each register, not per feature.
> 
> The register layout is like this:

The register layout of what? How is the device called? Is datasheet
available anywhere?

> 
> 0x8010 - 0x803c contains 4 clockselect registers
> 0x80d0 is the DDR16SS_PMCTRL regsiter
> 0x8190 - 0x8600 contains another 7 clockselect registers
> 
> I see the feature here in the block being clockselect registers. But the
> ddr-pmctrl register doesn't fit into this so I opted to describe this
> single register as one node as it looked to me like one feature. Of
> course I would have preferred this to be different but it is not. Would
> you prefer the clockselect registers and the pmctrl register to be
> described as one syscon?
No, because all the time you speak register=device and all the time I
was explaining that this is not correct. Device is the collection of
registers. I already said it - entire block is the syscon, not one
register in the middle, not 2 registers in the middle, not even 4+7
registers in the middle.


Best regards,
Krzysztof

On Sun, Feb 09, 2025 at 01:21:27PM +0100, Krzysztof Kozlowski wrote:
> On 07/02/2025 15:40, Markus Schneider-Pargmann wrote:
> > Hi Krzysztof,
> > 
> > On Mon, Jan 27, 2025 at 01:09:49PM +0100, Krzysztof Kozlowski wrote:
> >> On 24/01/2025 23:35, Andrew Davis wrote:
> >>> On 1/24/25 10:48 AM, Krzysztof Kozlowski wrote:
> >>>> On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
> >>>>> Hi Krzysztof,
> >>>>>
> >>>>> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
> >>>>>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
> >>>>>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
> >>>>>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
> >>>>>>>> register in the wkup-conf register space of am62a and am62p. This
> >>>>>>>> register controls DDR power management.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> >>>>>>>> ---
> >>>>>>>>   Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
> >>>>>>>>   1 file changed, 2 insertions(+)
> >>>>>>>
> >>>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> >>>>>>
> >>>>>> Un-acked, I missed the point that you really speak in commit msg about
> >>>>>> register and you really treat one register is a device. I assumed you
> >>>>>> only need that register from this device, but no. That obviously is not
> >>>>>> what this device is. Device is not a single register among 10000 others.
> >>>>>> IOW, You do not have 10000 devices there.
> >>>>>
> >>>>> Do I understand you correctly that the whole register range of the
> >>>>> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
> >>>>> should be considered a single syscon device?
> >>>>
> >>>> I don't have the datasheets (and not my task to actually check this),
> >>>> but you should probably follow datasheet. I assume it describes what is
> >>>> the device, more or less.
> >>>>
> >>>> I assume entire wkup_conf is considered a device.
> >>>>
> >>>>>
> >>>>> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
> >>>>> subnodes defined of which 4 of them consist of a single register. Most
> >>>>> of them are syscon as well. So I think I can't change the simple-bus
> >>>>> back to syscon.
> >>>>
> >>>> Huh... Maybe TI folks will help us understand why such design was chosen.
> >>>>
> >>>
> >>> Many of the devices inside the wkup_conf are already modeled as such.
> >>> Clocks and muxes for instance already have drivers and bindings, this
> >>> is nothing new to TI.
> >>>
> >>> If we just use a blank "syscon" over the entire region we would end up
> >>> with drivers that use phandles to the top level wkup_conf node and
> >>> poke directly the registers they need from that space.
> >>>
> >>> Would you rather have
> >>>
> >>> some-device {
> >>> 	ti,epwm_tbclk = <&wkup_conf>;
> >>> }
> >>>
> >>> or
> >>>
> >>> some-device {
> >>> 	clocks = <&epwm_tbclk 0>;
> >>> }
> >>
> >> How is this comparable? These are clocks. You would have clocks property
> >> in both cases.
> >>
> >>
> >>>
> >>> with that epwm_tbclk being a proper clock node inside wkup_conf?
> >>> I would much prefer the second, even though the clock node
> >>> only uses a single register. And in the first case, we would need
> >>> to have the offset into the wkup_conf space hard-coded in the
> >>> driver for each new SoC. Eventually all that data would need to be
> >>> put in tables and we end up back to machine board files..
> >>>
> >>> I'm not saying every magic number in all drivers should
> >>> be offloaded into DT, but there is a line somewhere between
> >>> that and having the DT simply contain the SoC's name compatible
> >>
> >> That's not the question here.
> >>
> >>> and all other data going into the kernel. That line might be a
> >>> personal preference, so my question back is: what is wrong
> >>> if we do want "1000 new syscons per each register" for our
> >>> SoCs DT?
> >>
> >> Because it is false representation of hardware. You do not have 1000
> >> devices. You have only one device.
> >>
> >>
> >>>
> >>> (and the number is not 1000, scanning the kernel I can see
> >>> the largest wkup_conf region node we have today has a grand
> >>> total number sub-nodes of 6)
> >>
> >> But what is being added here is device per each register, not per feature.
> > 
> > The register layout is like this:
> 
> The register layout of what? How is the device called? Is datasheet
> available anywhere?

Yes, it is available here: https://www.ti.com/de/lit/pdf/spruj16

14 Registers
14.2 Device Configuration Registers
14.2.1 CTRL_MMR Registers
14.2.1.1 General Purpose Control Registers
14.2.1.1.3 WKUP_CTRL_MMR0 Registers

Each domain has their own set of general purpose control registers,
CTRL_MMR for the main domain, MCU_CTRL_MMR0 for the MCU domain,
WKUP_CTRL_MMR0 for the wakeup domain.

So I understand this to just be a collection of general purpose control
registers. If you go by feature, then many of the registers can be
grouped into units with a specific purpose or controlling a specific
device which are also grouped by the offsets they represent. I assume
this is why the other nodes in this wkup_conf node were created. Also in
my opinion this makes the relation between the original device and this
general purpose control registers better understandable.

For this patch the ddr-pmctrl regsiter is just a single register, but it
has the purpose of controlling the DDR device power management.

The other patch I posted is a collection of registers for the
CANUART_WAKE functionality. CANUART here is a group of devices CAN and
UART devices. Thes also have a specific purpose for a specific part of
the SoC.

Best
Markus

> 
> > 
> > 0x8010 - 0x803c contains 4 clockselect registers
> > 0x80d0 is the DDR16SS_PMCTRL regsiter
> > 0x8190 - 0x8600 contains another 7 clockselect registers
> > 
> > I see the feature here in the block being clockselect registers. But the
> > ddr-pmctrl register doesn't fit into this so I opted to describe this
> > single register as one node as it looked to me like one feature. Of
> > course I would have preferred this to be different but it is not. Would
> > you prefer the clockselect registers and the pmctrl register to be
> > described as one syscon?
> No, because all the time you speak register=device and all the time I
> was explaining that this is not correct. Device is the collection of
> registers. I already said it - entire block is the syscon, not one
> register in the middle, not 2 registers in the middle, not even 4+7
> registers in the middle.
> 
> 
> Best regards,
> Krzysztof

On 10/02/2025 11:35, Markus Schneider-Pargmann wrote:
> On Sun, Feb 09, 2025 at 01:21:27PM +0100, Krzysztof Kozlowski wrote:
>> On 07/02/2025 15:40, Markus Schneider-Pargmann wrote:
>>> Hi Krzysztof,
>>>
>>> On Mon, Jan 27, 2025 at 01:09:49PM +0100, Krzysztof Kozlowski wrote:
>>>> On 24/01/2025 23:35, Andrew Davis wrote:
>>>>> On 1/24/25 10:48 AM, Krzysztof Kozlowski wrote:
>>>>>> On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
>>>>>>> Hi Krzysztof,
>>>>>>>
>>>>>>> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
>>>>>>>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
>>>>>>>>>> register in the wkup-conf register space of am62a and am62p. This
>>>>>>>>>> register controls DDR power management.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
>>>>>>>>>> ---
>>>>>>>>>>   Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>>>>>>>>>>   1 file changed, 2 insertions(+)
>>>>>>>>>
>>>>>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>>>>>
>>>>>>>> Un-acked, I missed the point that you really speak in commit msg about
>>>>>>>> register and you really treat one register is a device. I assumed you
>>>>>>>> only need that register from this device, but no. That obviously is not
>>>>>>>> what this device is. Device is not a single register among 10000 others.
>>>>>>>> IOW, You do not have 10000 devices there.
>>>>>>>
>>>>>>> Do I understand you correctly that the whole register range of the
>>>>>>> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
>>>>>>> should be considered a single syscon device?
>>>>>>
>>>>>> I don't have the datasheets (and not my task to actually check this),
>>>>>> but you should probably follow datasheet. I assume it describes what is
>>>>>> the device, more or less.
>>>>>>
>>>>>> I assume entire wkup_conf is considered a device.
>>>>>>
>>>>>>>
>>>>>>> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
>>>>>>> subnodes defined of which 4 of them consist of a single register. Most
>>>>>>> of them are syscon as well. So I think I can't change the simple-bus
>>>>>>> back to syscon.
>>>>>>
>>>>>> Huh... Maybe TI folks will help us understand why such design was chosen.
>>>>>>
>>>>>
>>>>> Many of the devices inside the wkup_conf are already modeled as such.
>>>>> Clocks and muxes for instance already have drivers and bindings, this
>>>>> is nothing new to TI.
>>>>>
>>>>> If we just use a blank "syscon" over the entire region we would end up
>>>>> with drivers that use phandles to the top level wkup_conf node and
>>>>> poke directly the registers they need from that space.
>>>>>
>>>>> Would you rather have
>>>>>
>>>>> some-device {
>>>>> 	ti,epwm_tbclk = <&wkup_conf>;
>>>>> }
>>>>>
>>>>> or
>>>>>
>>>>> some-device {
>>>>> 	clocks = <&epwm_tbclk 0>;
>>>>> }
>>>>
>>>> How is this comparable? These are clocks. You would have clocks property
>>>> in both cases.
>>>>
>>>>
>>>>>
>>>>> with that epwm_tbclk being a proper clock node inside wkup_conf?
>>>>> I would much prefer the second, even though the clock node
>>>>> only uses a single register. And in the first case, we would need
>>>>> to have the offset into the wkup_conf space hard-coded in the
>>>>> driver for each new SoC. Eventually all that data would need to be
>>>>> put in tables and we end up back to machine board files..
>>>>>
>>>>> I'm not saying every magic number in all drivers should
>>>>> be offloaded into DT, but there is a line somewhere between
>>>>> that and having the DT simply contain the SoC's name compatible
>>>>
>>>> That's not the question here.
>>>>
>>>>> and all other data going into the kernel. That line might be a
>>>>> personal preference, so my question back is: what is wrong
>>>>> if we do want "1000 new syscons per each register" for our
>>>>> SoCs DT?
>>>>
>>>> Because it is false representation of hardware. You do not have 1000
>>>> devices. You have only one device.
>>>>
>>>>
>>>>>
>>>>> (and the number is not 1000, scanning the kernel I can see
>>>>> the largest wkup_conf region node we have today has a grand
>>>>> total number sub-nodes of 6)
>>>>
>>>> But what is being added here is device per each register, not per feature.
>>>
>>> The register layout is like this:
>>
>> The register layout of what? How is the device called? Is datasheet
>> available anywhere?
> 
> Yes, it is available here: https://www.ti.com/de/lit/pdf/spruj16
> 
> 14 Registers
> 14.2 Device Configuration Registers
> 14.2.1 CTRL_MMR Registers
> 14.2.1.1 General Purpose Control Registers
> 14.2.1.1.3 WKUP_CTRL_MMR0 Registers
> 
> Each domain has their own set of general purpose control registers,
> CTRL_MMR for the main domain, MCU_CTRL_MMR0 for the MCU domain,
> WKUP_CTRL_MMR0 for the wakeup domain.


So according to the doc you have only one device - CTRL_MMR. All other
splits are superficial.

> 
> So I understand this to just be a collection of general purpose control
> registers. If you go by feature, then many of the registers can be
> grouped into units with a specific purpose or controlling a specific
> device which are also grouped by the offsets they represent. I assume

It could work if you have distinctive groups, but here:
1. You do not have this grouped, you just judge by yourself "oh, that's
group A, that's B".
2. Group per one register is not that.

For me this is one big block and even CLKSEL is spread all over so
cannot be really made distinctive.

> this is why the other nodes in this wkup_conf node were created. Also in

The other nodes represent some sort of fake or totally arbitrary
grouping. That's abuse of the syscon.

> my opinion this makes the relation between the original device and this
> general purpose control registers better understandable.
> 
> For this patch the ddr-pmctrl regsiter is just a single register, but it
> has the purpose of controlling the DDR device power management.

Sure, but that is NOT syscon. One register of entire block is not system
controller. The entire block is system controller.



Best regards,
Krzysztof

On 2/12/25 1:35 PM, Krzysztof Kozlowski wrote:
> On 10/02/2025 11:35, Markus Schneider-Pargmann wrote:
>> On Sun, Feb 09, 2025 at 01:21:27PM +0100, Krzysztof Kozlowski wrote:
>>> On 07/02/2025 15:40, Markus Schneider-Pargmann wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On Mon, Jan 27, 2025 at 01:09:49PM +0100, Krzysztof Kozlowski wrote:
>>>>> On 24/01/2025 23:35, Andrew Davis wrote:
>>>>>> On 1/24/25 10:48 AM, Krzysztof Kozlowski wrote:
>>>>>>> On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
>>>>>>>> Hi Krzysztof,
>>>>>>>>
>>>>>>>> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
>>>>>>>>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
>>>>>>>>>>> register in the wkup-conf register space of am62a and am62p. This
>>>>>>>>>>> register controls DDR power management.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
>>>>>>>>>>> ---
>>>>>>>>>>>    Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>>>>>>>>>>>    1 file changed, 2 insertions(+)
>>>>>>>>>>
>>>>>>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>>>>>>
>>>>>>>>> Un-acked, I missed the point that you really speak in commit msg about
>>>>>>>>> register and you really treat one register is a device. I assumed you
>>>>>>>>> only need that register from this device, but no. That obviously is not
>>>>>>>>> what this device is. Device is not a single register among 10000 others.
>>>>>>>>> IOW, You do not have 10000 devices there.
>>>>>>>>
>>>>>>>> Do I understand you correctly that the whole register range of the
>>>>>>>> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
>>>>>>>> should be considered a single syscon device?
>>>>>>>
>>>>>>> I don't have the datasheets (and not my task to actually check this),
>>>>>>> but you should probably follow datasheet. I assume it describes what is
>>>>>>> the device, more or less.
>>>>>>>
>>>>>>> I assume entire wkup_conf is considered a device.
>>>>>>>
>>>>>>>>
>>>>>>>> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
>>>>>>>> subnodes defined of which 4 of them consist of a single register. Most
>>>>>>>> of them are syscon as well. So I think I can't change the simple-bus
>>>>>>>> back to syscon.
>>>>>>>
>>>>>>> Huh... Maybe TI folks will help us understand why such design was chosen.
>>>>>>>
>>>>>>
>>>>>> Many of the devices inside the wkup_conf are already modeled as such.
>>>>>> Clocks and muxes for instance already have drivers and bindings, this
>>>>>> is nothing new to TI.
>>>>>>
>>>>>> If we just use a blank "syscon" over the entire region we would end up
>>>>>> with drivers that use phandles to the top level wkup_conf node and
>>>>>> poke directly the registers they need from that space.
>>>>>>
>>>>>> Would you rather have
>>>>>>
>>>>>> some-device {
>>>>>> 	ti,epwm_tbclk = <&wkup_conf>;
>>>>>> }
>>>>>>
>>>>>> or
>>>>>>
>>>>>> some-device {
>>>>>> 	clocks = <&epwm_tbclk 0>;
>>>>>> }
>>>>>
>>>>> How is this comparable? These are clocks. You would have clocks property
>>>>> in both cases.
>>>>>
>>>>>
>>>>>>
>>>>>> with that epwm_tbclk being a proper clock node inside wkup_conf?
>>>>>> I would much prefer the second, even though the clock node
>>>>>> only uses a single register. And in the first case, we would need
>>>>>> to have the offset into the wkup_conf space hard-coded in the
>>>>>> driver for each new SoC. Eventually all that data would need to be
>>>>>> put in tables and we end up back to machine board files..
>>>>>>
>>>>>> I'm not saying every magic number in all drivers should
>>>>>> be offloaded into DT, but there is a line somewhere between
>>>>>> that and having the DT simply contain the SoC's name compatible
>>>>>
>>>>> That's not the question here.
>>>>>
>>>>>> and all other data going into the kernel. That line might be a
>>>>>> personal preference, so my question back is: what is wrong
>>>>>> if we do want "1000 new syscons per each register" for our
>>>>>> SoCs DT?
>>>>>
>>>>> Because it is false representation of hardware. You do not have 1000
>>>>> devices. You have only one device.
>>>>>
>>>>>
>>>>>>
>>>>>> (and the number is not 1000, scanning the kernel I can see
>>>>>> the largest wkup_conf region node we have today has a grand
>>>>>> total number sub-nodes of 6)
>>>>>
>>>>> But what is being added here is device per each register, not per feature.
>>>>
>>>> The register layout is like this:
>>>
>>> The register layout of what? How is the device called? Is datasheet
>>> available anywhere?
>>
>> Yes, it is available here: https://www.ti.com/de/lit/pdf/spruj16
>>
>> 14 Registers
>> 14.2 Device Configuration Registers
>> 14.2.1 CTRL_MMR Registers
>> 14.2.1.1 General Purpose Control Registers
>> 14.2.1.1.3 WKUP_CTRL_MMR0 Registers
>>
>> Each domain has their own set of general purpose control registers,
>> CTRL_MMR for the main domain, MCU_CTRL_MMR0 for the MCU domain,
>> WKUP_CTRL_MMR0 for the wakeup domain.
> 
> 
> So according to the doc you have only one device - CTRL_MMR. All other
> splits are superficial.
> 

It is not one device, it is a collection of devices under one labeled
bus range. Some items here are full normal devices, already modeled by DT
as stand-alone devices, for instance our chipid, efuse, clock controller,
etc. even our pinmux is part of this bus range.

They are grouped as we have one set for each domain (MAIN, WKUP, MCU).

All other splits are not superficial, if we go down that path then
the whole SoC is one "device". We could simply have the whole address
bus be one node and have Linux hard-code offsets in the drivers, we
end up back at board files..

DT should break things into logically distinct and reusable units
so we don't have to store that in the kernel. That is what we do
here, even if some units end up being very small.

>>
>> So I understand this to just be a collection of general purpose control
>> registers. If you go by feature, then many of the registers can be
>> grouped into units with a specific purpose or controlling a specific
>> device which are also grouped by the offsets they represent. I assume
> 
> It could work if you have distinctive groups, but here:
> 1. You do not have this grouped, you just judge by yourself "oh, that's
> group A, that's B".
> 2. Group per one register is not that.
> 
> For me this is one big block and even CLKSEL is spread all over so
> cannot be really made distinctive.
> 
>> this is why the other nodes in this wkup_conf node were created. Also in
> 
> The other nodes represent some sort of fake or totally arbitrary
> grouping. That's abuse of the syscon.
> 

They are grouped by function.

>> my opinion this makes the relation between the original device and this
>> general purpose control registers better understandable.
>>
>> For this patch the ddr-pmctrl regsiter is just a single register, but it
>> has the purpose of controlling the DDR device power management.
> 
> Sure, but that is NOT syscon. One register of entire block is not system
> controller. The entire block is system controller.
> 

The whole block cannot be a system controller as there are regular
devices inside this range. If we made the whole region a syscon and
also left the device nodes inside, then we would have overlapping
register owners, one register would be controlled by two or more
drivers. How would we synchronize mappings, access, updates, etc.
Any one register should belong to exactly one device.

Is your issue the name "system controller", as yes I agree some of
these regions are not "system controllers".

Would it work better if we didn't call this "ti,am62-ddr-pmctrl"
node a "syscon"? That can be done, we just would add a normal
binding doc for it, instead of trying to reuse the generic
bindings/mfd/syscon.yaml file.

Andrew

> 
> 
> Best regards,
> Krzysztof

On 09/04/2025 19:39, Andrew Davis wrote:
> On 2/12/25 1:35 PM, Krzysztof Kozlowski wrote:
>> On 10/02/2025 11:35, Markus Schneider-Pargmann wrote:
>>> On Sun, Feb 09, 2025 at 01:21:27PM +0100, Krzysztof Kozlowski wrote:
>>>> On 07/02/2025 15:40, Markus Schneider-Pargmann wrote:
>>>>> Hi Krzysztof,
>>>>>
>>>>> On Mon, Jan 27, 2025 at 01:09:49PM +0100, Krzysztof Kozlowski wrote:
>>>>>> On 24/01/2025 23:35, Andrew Davis wrote:
>>>>>>> On 1/24/25 10:48 AM, Krzysztof Kozlowski wrote:
>>>>>>>> On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
>>>>>>>>> Hi Krzysztof,
>>>>>>>>>
>>>>>>>>> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
>>>>>>>>>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
>>>>>>>>>>>> register in the wkup-conf register space of am62a and am62p. This
>>>>>>>>>>>> register controls DDR power management.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>>    Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>>>>>>>>>>>>    1 file changed, 2 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>>>>>>>
>>>>>>>>>> Un-acked, I missed the point that you really speak in commit msg about
>>>>>>>>>> register and you really treat one register is a device. I assumed you
>>>>>>>>>> only need that register from this device, but no. That obviously is not
>>>>>>>>>> what this device is. Device is not a single register among 10000 others.
>>>>>>>>>> IOW, You do not have 10000 devices there.
>>>>>>>>>
>>>>>>>>> Do I understand you correctly that the whole register range of the
>>>>>>>>> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
>>>>>>>>> should be considered a single syscon device?
>>>>>>>>
>>>>>>>> I don't have the datasheets (and not my task to actually check this),
>>>>>>>> but you should probably follow datasheet. I assume it describes what is
>>>>>>>> the device, more or less.
>>>>>>>>
>>>>>>>> I assume entire wkup_conf is considered a device.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
>>>>>>>>> subnodes defined of which 4 of them consist of a single register. Most
>>>>>>>>> of them are syscon as well. So I think I can't change the simple-bus
>>>>>>>>> back to syscon.
>>>>>>>>
>>>>>>>> Huh... Maybe TI folks will help us understand why such design was chosen.
>>>>>>>>
>>>>>>>
>>>>>>> Many of the devices inside the wkup_conf are already modeled as such.
>>>>>>> Clocks and muxes for instance already have drivers and bindings, this
>>>>>>> is nothing new to TI.
>>>>>>>
>>>>>>> If we just use a blank "syscon" over the entire region we would end up
>>>>>>> with drivers that use phandles to the top level wkup_conf node and
>>>>>>> poke directly the registers they need from that space.
>>>>>>>
>>>>>>> Would you rather have
>>>>>>>
>>>>>>> some-device {
>>>>>>> 	ti,epwm_tbclk = <&wkup_conf>;
>>>>>>> }
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> some-device {
>>>>>>> 	clocks = <&epwm_tbclk 0>;
>>>>>>> }
>>>>>>
>>>>>> How is this comparable? These are clocks. You would have clocks property
>>>>>> in both cases.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> with that epwm_tbclk being a proper clock node inside wkup_conf?
>>>>>>> I would much prefer the second, even though the clock node
>>>>>>> only uses a single register. And in the first case, we would need
>>>>>>> to have the offset into the wkup_conf space hard-coded in the
>>>>>>> driver for each new SoC. Eventually all that data would need to be
>>>>>>> put in tables and we end up back to machine board files..
>>>>>>>
>>>>>>> I'm not saying every magic number in all drivers should
>>>>>>> be offloaded into DT, but there is a line somewhere between
>>>>>>> that and having the DT simply contain the SoC's name compatible
>>>>>>
>>>>>> That's not the question here.
>>>>>>
>>>>>>> and all other data going into the kernel. That line might be a
>>>>>>> personal preference, so my question back is: what is wrong
>>>>>>> if we do want "1000 new syscons per each register" for our
>>>>>>> SoCs DT?
>>>>>>
>>>>>> Because it is false representation of hardware. You do not have 1000
>>>>>> devices. You have only one device.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> (and the number is not 1000, scanning the kernel I can see
>>>>>>> the largest wkup_conf region node we have today has a grand
>>>>>>> total number sub-nodes of 6)
>>>>>>
>>>>>> But what is being added here is device per each register, not per feature.
>>>>>
>>>>> The register layout is like this:
>>>>
>>>> The register layout of what? How is the device called? Is datasheet
>>>> available anywhere?
>>>
>>> Yes, it is available here: https://www.ti.com/de/lit/pdf/spruj16
>>>
>>> 14 Registers
>>> 14.2 Device Configuration Registers
>>> 14.2.1 CTRL_MMR Registers
>>> 14.2.1.1 General Purpose Control Registers
>>> 14.2.1.1.3 WKUP_CTRL_MMR0 Registers
>>>
>>> Each domain has their own set of general purpose control registers,
>>> CTRL_MMR for the main domain, MCU_CTRL_MMR0 for the MCU domain,
>>> WKUP_CTRL_MMR0 for the wakeup domain.
>>
>>
>> So according to the doc you have only one device - CTRL_MMR. All other
>> splits are superficial.
>>
> 
> It is not one device, it is a collection of devices under one labeled
> bus range. Some items here are full normal devices, already modeled by DT
> as stand-alone devices, for instance our chipid, efuse, clock controller,
> etc. even our pinmux is part of this bus range.
> 
> They are grouped as we have one set for each domain (MAIN, WKUP, MCU).
> 
> All other splits are not superficial, if we go down that path then
> the whole SoC is one "device". We could simply have the whole address
> bus be one node and have Linux hard-code offsets in the drivers, we
> end up back at board files..
> 
> DT should break things into logically distinct and reusable units
> so we don't have to store that in the kernel. That is what we do
> here, even if some units end up being very small.
> 
>>>
>>> So I understand this to just be a collection of general purpose control
>>> registers. If you go by feature, then many of the registers can be
>>> grouped into units with a specific purpose or controlling a specific
>>> device which are also grouped by the offsets they represent. I assume
>>
>> It could work if you have distinctive groups, but here:
>> 1. You do not have this grouped, you just judge by yourself "oh, that's
>> group A, that's B".
>> 2. Group per one register is not that.
>>
>> For me this is one big block and even CLKSEL is spread all over so
>> cannot be really made distinctive.
>>
>>> this is why the other nodes in this wkup_conf node were created. Also in
>>
>> The other nodes represent some sort of fake or totally arbitrary
>> grouping. That's abuse of the syscon.
>>
> 
> They are grouped by function.

Not really - other DTS sent just few days ago created each entry per one
register.

> 
>>> my opinion this makes the relation between the original device and this
>>> general purpose control registers better understandable.
>>>
>>> For this patch the ddr-pmctrl regsiter is just a single register, but it
>>> has the purpose of controlling the DDR device power management.
>>
>> Sure, but that is NOT syscon. One register of entire block is not system
>> controller. The entire block is system controller.
>>
> 
> The whole block cannot be a system controller as there are regular
> devices inside this range. If we made the whole region a syscon and

That's still system controller. It's nothing special here.

> also left the device nodes inside, then we would have overlapping
> register owners, one register would be controlled by two or more

No, owner is the parent device always.

> drivers. How would we synchronize mappings, access, updates, etc.
> Any one register should belong to exactly one device.

regmap synchronizes everything. There is no problem here, at all.

> 
> Is your issue the name "system controller", as yes I agree some of
> these regions are not "system controllers".
> 
> Would it work better if we didn't call this "ti,am62-ddr-pmctrl"
> node a "syscon"? That can be done, we just would add a normal
> binding doc for it, instead of trying to reuse the generic
> bindings/mfd/syscon.yaml file.

You still do not have multiple subnodes, one per each register or even
few registers.

Best regards,
Krzysztof

On 4/15/25 12:17 AM, Krzysztof Kozlowski wrote:
> On 09/04/2025 19:39, Andrew Davis wrote:
>> On 2/12/25 1:35 PM, Krzysztof Kozlowski wrote:
>>> On 10/02/2025 11:35, Markus Schneider-Pargmann wrote:
>>>> On Sun, Feb 09, 2025 at 01:21:27PM +0100, Krzysztof Kozlowski wrote:
>>>>> On 07/02/2025 15:40, Markus Schneider-Pargmann wrote:
>>>>>> Hi Krzysztof,
>>>>>>
>>>>>> On Mon, Jan 27, 2025 at 01:09:49PM +0100, Krzysztof Kozlowski wrote:
>>>>>>> On 24/01/2025 23:35, Andrew Davis wrote:
>>>>>>>> On 1/24/25 10:48 AM, Krzysztof Kozlowski wrote:
>>>>>>>>> On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
>>>>>>>>>> Hi Krzysztof,
>>>>>>>>>>
>>>>>>>>>> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>>>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>>>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
>>>>>>>>>>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
>>>>>>>>>>>>> register in the wkup-conf register space of am62a and am62p. This
>>>>>>>>>>>>> register controls DDR power management.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>     Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>>>>>>>>>>>>>     1 file changed, 2 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>>>>>>>>
>>>>>>>>>>> Un-acked, I missed the point that you really speak in commit msg about
>>>>>>>>>>> register and you really treat one register is a device. I assumed you
>>>>>>>>>>> only need that register from this device, but no. That obviously is not
>>>>>>>>>>> what this device is. Device is not a single register among 10000 others.
>>>>>>>>>>> IOW, You do not have 10000 devices there.
>>>>>>>>>>
>>>>>>>>>> Do I understand you correctly that the whole register range of the
>>>>>>>>>> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
>>>>>>>>>> should be considered a single syscon device?
>>>>>>>>>
>>>>>>>>> I don't have the datasheets (and not my task to actually check this),
>>>>>>>>> but you should probably follow datasheet. I assume it describes what is
>>>>>>>>> the device, more or less.
>>>>>>>>>
>>>>>>>>> I assume entire wkup_conf is considered a device.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
>>>>>>>>>> subnodes defined of which 4 of them consist of a single register. Most
>>>>>>>>>> of them are syscon as well. So I think I can't change the simple-bus
>>>>>>>>>> back to syscon.
>>>>>>>>>
>>>>>>>>> Huh... Maybe TI folks will help us understand why such design was chosen.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Many of the devices inside the wkup_conf are already modeled as such.
>>>>>>>> Clocks and muxes for instance already have drivers and bindings, this
>>>>>>>> is nothing new to TI.
>>>>>>>>
>>>>>>>> If we just use a blank "syscon" over the entire region we would end up
>>>>>>>> with drivers that use phandles to the top level wkup_conf node and
>>>>>>>> poke directly the registers they need from that space.
>>>>>>>>
>>>>>>>> Would you rather have
>>>>>>>>
>>>>>>>> some-device {
>>>>>>>> 	ti,epwm_tbclk = <&wkup_conf>;
>>>>>>>> }
>>>>>>>>
>>>>>>>> or
>>>>>>>>
>>>>>>>> some-device {
>>>>>>>> 	clocks = <&epwm_tbclk 0>;
>>>>>>>> }
>>>>>>>
>>>>>>> How is this comparable? These are clocks. You would have clocks property
>>>>>>> in both cases.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> with that epwm_tbclk being a proper clock node inside wkup_conf?
>>>>>>>> I would much prefer the second, even though the clock node
>>>>>>>> only uses a single register. And in the first case, we would need
>>>>>>>> to have the offset into the wkup_conf space hard-coded in the
>>>>>>>> driver for each new SoC. Eventually all that data would need to be
>>>>>>>> put in tables and we end up back to machine board files..
>>>>>>>>
>>>>>>>> I'm not saying every magic number in all drivers should
>>>>>>>> be offloaded into DT, but there is a line somewhere between
>>>>>>>> that and having the DT simply contain the SoC's name compatible
>>>>>>>
>>>>>>> That's not the question here.
>>>>>>>
>>>>>>>> and all other data going into the kernel. That line might be a
>>>>>>>> personal preference, so my question back is: what is wrong
>>>>>>>> if we do want "1000 new syscons per each register" for our
>>>>>>>> SoCs DT?
>>>>>>>
>>>>>>> Because it is false representation of hardware. You do not have 1000
>>>>>>> devices. You have only one device.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> (and the number is not 1000, scanning the kernel I can see
>>>>>>>> the largest wkup_conf region node we have today has a grand
>>>>>>>> total number sub-nodes of 6)
>>>>>>>
>>>>>>> But what is being added here is device per each register, not per feature.
>>>>>>
>>>>>> The register layout is like this:
>>>>>
>>>>> The register layout of what? How is the device called? Is datasheet
>>>>> available anywhere?
>>>>
>>>> Yes, it is available here: https://www.ti.com/de/lit/pdf/spruj16
>>>>
>>>> 14 Registers
>>>> 14.2 Device Configuration Registers
>>>> 14.2.1 CTRL_MMR Registers
>>>> 14.2.1.1 General Purpose Control Registers
>>>> 14.2.1.1.3 WKUP_CTRL_MMR0 Registers
>>>>
>>>> Each domain has their own set of general purpose control registers,
>>>> CTRL_MMR for the main domain, MCU_CTRL_MMR0 for the MCU domain,
>>>> WKUP_CTRL_MMR0 for the wakeup domain.
>>>
>>>
>>> So according to the doc you have only one device - CTRL_MMR. All other
>>> splits are superficial.
>>>
>>
>> It is not one device, it is a collection of devices under one labeled
>> bus range. Some items here are full normal devices, already modeled by DT
>> as stand-alone devices, for instance our chipid, efuse, clock controller,
>> etc. even our pinmux is part of this bus range.
>>
>> They are grouped as we have one set for each domain (MAIN, WKUP, MCU).
>>
>> All other splits are not superficial, if we go down that path then
>> the whole SoC is one "device". We could simply have the whole address
>> bus be one node and have Linux hard-code offsets in the drivers, we
>> end up back at board files..
>>
>> DT should break things into logically distinct and reusable units
>> so we don't have to store that in the kernel. That is what we do
>> here, even if some units end up being very small.
>>
>>>>
>>>> So I understand this to just be a collection of general purpose control
>>>> registers. If you go by feature, then many of the registers can be
>>>> grouped into units with a specific purpose or controlling a specific
>>>> device which are also grouped by the offsets they represent. I assume
>>>
>>> It could work if you have distinctive groups, but here:
>>> 1. You do not have this grouped, you just judge by yourself "oh, that's
>>> group A, that's B".
>>> 2. Group per one register is not that.
>>>
>>> For me this is one big block and even CLKSEL is spread all over so
>>> cannot be really made distinctive.
>>>
>>>> this is why the other nodes in this wkup_conf node were created. Also in
>>>
>>> The other nodes represent some sort of fake or totally arbitrary
>>> grouping. That's abuse of the syscon.
>>>
>>
>> They are grouped by function.
> 
> Not really - other DTS sent just few days ago created each entry per one
> register.
> 
>>
>>>> my opinion this makes the relation between the original device and this
>>>> general purpose control registers better understandable.
>>>>
>>>> For this patch the ddr-pmctrl regsiter is just a single register, but it
>>>> has the purpose of controlling the DDR device power management.
>>>
>>> Sure, but that is NOT syscon. One register of entire block is not system
>>> controller. The entire block is system controller.
>>>
>>
>> The whole block cannot be a system controller as there are regular
>> devices inside this range. If we made the whole region a syscon and
> 
> That's still system controller. It's nothing special here.
> 
>> also left the device nodes inside, then we would have overlapping
>> register owners, one register would be controlled by two or more
> 
> No, owner is the parent device always.

Which parent device? That is my point, if the top level node for the
whole CTRL_MMR region is made into one big syscon, then a big regmap
is made that covers the whole region. All the child devices also make
regmaps covering their device range. Now these registers under the child
device belong to two different regmaps. No synchronization is done as
these are not the same regmap, regmap only handles this for multiple
access to registers within the same regmap.

Let's take a real example, here is part of AM62A CTRL_MMR node.

main_conf: bus@100000 {
	compatible = "simple-bus";
	#address-cells = <1>;
	#size-cells = <1>;
	ranges = <0x00 0x00 0x00100000 0x20000>;

	phy_gmii_sel: phy@4044 {
		compatible = "ti,am654-phy-gmii-sel";
		reg = <0x4044 0x8>;
		#phy-cells = <1>;
	};

	...
};

If we turn "main_conf" into a syscon, then who "owns" 0x4044?
Both the top level syscon and phy_gmii_sel nodes would build
a different regmap instance that contains those same registers.

Bit of back story, this is actually how I got involved in sorting
out this "syscon" stuff for our devices. I built a checker into
the regmap framework core that would detect when multiple regmaps
are created that contain overlapping registers.

I found several bugs this way and want to push the check upstream at
some point. But first I wanted to fix the biggest cause of warnings,
which was from syscon being used as described above.

> 
>> drivers. How would we synchronize mappings, access, updates, etc.
>> Any one register should belong to exactly one device.
> 
> regmap synchronizes everything. There is no problem here, at all.
> 
>>
>> Is your issue the name "system controller", as yes I agree some of
>> these regions are not "system controllers".
>>
>> Would it work better if we didn't call this "ti,am62-ddr-pmctrl"
>> node a "syscon"? That can be done, we just would add a normal
>> binding doc for it, instead of trying to reuse the generic
>> bindings/mfd/syscon.yaml file.
> 
> You still do not have multiple subnodes, one per each register or even
> few registers.

If this ddr-pmctrl device is not modeled as a syscon device, then who
says it has to be more than a few (3?) registers in size? This seems like
a rather arbitrary rule, and completely unfeasible for several whole
classes of devices that only have/need a few registers to work them.

Andrew

> 
> Best regards,
> Krzysztof

On 4/21/25 12:03 PM, Andrew Davis wrote:

...

> Which parent device? That is my point, if the top level node for the
> whole CTRL_MMR region is made into one big syscon, then a big regmap
> is made that covers the whole region. All the child devices also make
> regmaps covering their device range. Now these registers under the child
> device belong to two different regmaps. No synchronization is done as
> these are not the same regmap, regmap only handles this for multiple
> access to registers within the same regmap.
> 

Why does the child device have to create a new/separate regmap? Can it not use
something like syscon_regmap_lookup_by_phandle_args() to get the regmap from
the "syscon" node along with 1 or more args specifying the one or few registers
out of the full range that are assigned to that specific child node? This way,
all child nodes would be using the same shared regmap.

(And yes, I know technically they don't need to be child nodes - just using that
terminology to be consistent with the previous discussion.)

On 4/22/25 11:12 AM, David Lechner wrote:
> On 4/21/25 12:03 PM, Andrew Davis wrote:
> 
> ...
> 
>> Which parent device? That is my point, if the top level node for the
>> whole CTRL_MMR region is made into one big syscon, then a big regmap
>> is made that covers the whole region. All the child devices also make
>> regmaps covering their device range. Now these registers under the child
>> device belong to two different regmaps. No synchronization is done as
>> these are not the same regmap, regmap only handles this for multiple
>> access to registers within the same regmap.
>>
> 
> Why does the child device have to create a new/separate regmap? Can it not use
> something like syscon_regmap_lookup_by_phandle_args() to get the regmap from
> the "syscon" node along with 1 or more args specifying the one or few registers
> out of the full range that are assigned to that specific child node? This way,
> all child nodes would be using the same shared regmap.
> 
> (And yes, I know technically they don't need to be child nodes - just using that
> terminology to be consistent with the previous discussion.)

Yes, this can be done, and is done for a couple drivers today. The issue is most
drivers do not expect to be a child node of a syscon nor fetch a regmap with
syscon_regmap_lookup_*() functions. The vast majority drivers do the normal thing,
which is platform_get_resource() and similar, that gets the memory from the standard
"reg" property inside their own node.

We have then two options, retrofit all the existing drivers we might use with
support for fetching syscon regmaps (some drivers do not use regmap in the
first place, so we would also have to add regmap support first). Or we do what
we are doing here, which is to have these devices not use overlapping register
regions (which has the minor side effect of sometimes causing some nodes to
cover only small range of registers, which seems to be a problem?).

We went for the latter option, and it has been working fine for all our
new devices. And we are fixing the same for some of our older devices, we
are actually almost done with that too (if we could get this patch and maybe
two others in we would be completely converted).

Andrew

On 21/04/2025 19:03, Andrew Davis wrote:
> On 4/15/25 12:17 AM, Krzysztof Kozlowski wrote:
>> On 09/04/2025 19:39, Andrew Davis wrote:
>>> On 2/12/25 1:35 PM, Krzysztof Kozlowski wrote:
>>>> On 10/02/2025 11:35, Markus Schneider-Pargmann wrote:
>>>>> On Sun, Feb 09, 2025 at 01:21:27PM +0100, Krzysztof Kozlowski wrote:
>>>>>> On 07/02/2025 15:40, Markus Schneider-Pargmann wrote:
>>>>>>> Hi Krzysztof,
>>>>>>>
>>>>>>> On Mon, Jan 27, 2025 at 01:09:49PM +0100, Krzysztof Kozlowski wrote:
>>>>>>>> On 24/01/2025 23:35, Andrew Davis wrote:
>>>>>>>>> On 1/24/25 10:48 AM, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
>>>>>>>>>>> Hi Krzysztof,
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>>>>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>>>>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
>>>>>>>>>>>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
>>>>>>>>>>>>>> register in the wkup-conf register space of am62a and am62p. This
>>>>>>>>>>>>>> register controls DDR power management.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>     Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>>>>>>>>>>>>>>     1 file changed, 2 insertions(+)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>>>>>>>>>
>>>>>>>>>>>> Un-acked, I missed the point that you really speak in commit msg about
>>>>>>>>>>>> register and you really treat one register is a device. I assumed you
>>>>>>>>>>>> only need that register from this device, but no. That obviously is not
>>>>>>>>>>>> what this device is. Device is not a single register among 10000 others.
>>>>>>>>>>>> IOW, You do not have 10000 devices there.
>>>>>>>>>>>
>>>>>>>>>>> Do I understand you correctly that the whole register range of the
>>>>>>>>>>> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
>>>>>>>>>>> should be considered a single syscon device?
>>>>>>>>>>
>>>>>>>>>> I don't have the datasheets (and not my task to actually check this),
>>>>>>>>>> but you should probably follow datasheet. I assume it describes what is
>>>>>>>>>> the device, more or less.
>>>>>>>>>>
>>>>>>>>>> I assume entire wkup_conf is considered a device.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
>>>>>>>>>>> subnodes defined of which 4 of them consist of a single register. Most
>>>>>>>>>>> of them are syscon as well. So I think I can't change the simple-bus
>>>>>>>>>>> back to syscon.
>>>>>>>>>>
>>>>>>>>>> Huh... Maybe TI folks will help us understand why such design was chosen.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Many of the devices inside the wkup_conf are already modeled as such.
>>>>>>>>> Clocks and muxes for instance already have drivers and bindings, this
>>>>>>>>> is nothing new to TI.
>>>>>>>>>
>>>>>>>>> If we just use a blank "syscon" over the entire region we would end up
>>>>>>>>> with drivers that use phandles to the top level wkup_conf node and
>>>>>>>>> poke directly the registers they need from that space.
>>>>>>>>>
>>>>>>>>> Would you rather have
>>>>>>>>>
>>>>>>>>> some-device {
>>>>>>>>> 	ti,epwm_tbclk = <&wkup_conf>;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> or
>>>>>>>>>
>>>>>>>>> some-device {
>>>>>>>>> 	clocks = <&epwm_tbclk 0>;
>>>>>>>>> }
>>>>>>>>
>>>>>>>> How is this comparable? These are clocks. You would have clocks property
>>>>>>>> in both cases.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> with that epwm_tbclk being a proper clock node inside wkup_conf?
>>>>>>>>> I would much prefer the second, even though the clock node
>>>>>>>>> only uses a single register. And in the first case, we would need
>>>>>>>>> to have the offset into the wkup_conf space hard-coded in the
>>>>>>>>> driver for each new SoC. Eventually all that data would need to be
>>>>>>>>> put in tables and we end up back to machine board files..
>>>>>>>>>
>>>>>>>>> I'm not saying every magic number in all drivers should
>>>>>>>>> be offloaded into DT, but there is a line somewhere between
>>>>>>>>> that and having the DT simply contain the SoC's name compatible
>>>>>>>>
>>>>>>>> That's not the question here.
>>>>>>>>
>>>>>>>>> and all other data going into the kernel. That line might be a
>>>>>>>>> personal preference, so my question back is: what is wrong
>>>>>>>>> if we do want "1000 new syscons per each register" for our
>>>>>>>>> SoCs DT?
>>>>>>>>
>>>>>>>> Because it is false representation of hardware. You do not have 1000
>>>>>>>> devices. You have only one device.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> (and the number is not 1000, scanning the kernel I can see
>>>>>>>>> the largest wkup_conf region node we have today has a grand
>>>>>>>>> total number sub-nodes of 6)
>>>>>>>>
>>>>>>>> But what is being added here is device per each register, not per feature.
>>>>>>>
>>>>>>> The register layout is like this:
>>>>>>
>>>>>> The register layout of what? How is the device called? Is datasheet
>>>>>> available anywhere?
>>>>>
>>>>> Yes, it is available here: https://www.ti.com/de/lit/pdf/spruj16
>>>>>
>>>>> 14 Registers
>>>>> 14.2 Device Configuration Registers
>>>>> 14.2.1 CTRL_MMR Registers
>>>>> 14.2.1.1 General Purpose Control Registers
>>>>> 14.2.1.1.3 WKUP_CTRL_MMR0 Registers
>>>>>
>>>>> Each domain has their own set of general purpose control registers,
>>>>> CTRL_MMR for the main domain, MCU_CTRL_MMR0 for the MCU domain,
>>>>> WKUP_CTRL_MMR0 for the wakeup domain.
>>>>
>>>>
>>>> So according to the doc you have only one device - CTRL_MMR. All other
>>>> splits are superficial.
>>>>
>>>
>>> It is not one device, it is a collection of devices under one labeled
>>> bus range. Some items here are full normal devices, already modeled by DT
>>> as stand-alone devices, for instance our chipid, efuse, clock controller,
>>> etc. even our pinmux is part of this bus range.
>>>
>>> They are grouped as we have one set for each domain (MAIN, WKUP, MCU).
>>>
>>> All other splits are not superficial, if we go down that path then
>>> the whole SoC is one "device". We could simply have the whole address
>>> bus be one node and have Linux hard-code offsets in the drivers, we
>>> end up back at board files..
>>>
>>> DT should break things into logically distinct and reusable units
>>> so we don't have to store that in the kernel. That is what we do
>>> here, even if some units end up being very small.
>>>
>>>>>
>>>>> So I understand this to just be a collection of general purpose control
>>>>> registers. If you go by feature, then many of the registers can be
>>>>> grouped into units with a specific purpose or controlling a specific
>>>>> device which are also grouped by the offsets they represent. I assume
>>>>
>>>> It could work if you have distinctive groups, but here:
>>>> 1. You do not have this grouped, you just judge by yourself "oh, that's
>>>> group A, that's B".
>>>> 2. Group per one register is not that.
>>>>
>>>> For me this is one big block and even CLKSEL is spread all over so
>>>> cannot be really made distinctive.
>>>>
>>>>> this is why the other nodes in this wkup_conf node were created. Also in
>>>>
>>>> The other nodes represent some sort of fake or totally arbitrary
>>>> grouping. That's abuse of the syscon.
>>>>
>>>
>>> They are grouped by function.
>>
>> Not really - other DTS sent just few days ago created each entry per one
>> register.
>>
>>>
>>>>> my opinion this makes the relation between the original device and this
>>>>> general purpose control registers better understandable.
>>>>>
>>>>> For this patch the ddr-pmctrl regsiter is just a single register, but it
>>>>> has the purpose of controlling the DDR device power management.
>>>>
>>>> Sure, but that is NOT syscon. One register of entire block is not system
>>>> controller. The entire block is system controller.
>>>>
>>>
>>> The whole block cannot be a system controller as there are regular
>>> devices inside this range. If we made the whole region a syscon and
>>
>> That's still system controller. It's nothing special here.
>>
>>> also left the device nodes inside, then we would have overlapping
>>> register owners, one register would be controlled by two or more
>>
>> No, owner is the parent device always.
> 
> Which parent device? That is my point, if the top level node for the
> whole CTRL_MMR region is made into one big syscon, then a big regmap
> is made that covers the whole region. All the child devices also make

Children take the parent regmap or you do not have even the children.
Actually the second point is what we talk here: you created fake devices
per each register and these are supposed to be squashed into the parent.
I am repeating this 3rd time or more.


> regmaps covering their device range. Now these registers under the child
> device belong to two different regmaps. No synchronization is done as
> these are not the same regmap, regmap only handles this for multiple
> access to registers within the same regmap.
> 
> Let's take a real example, here is part of AM62A CTRL_MMR node.
> 
> main_conf: bus@100000 {
> 	compatible = "simple-bus";
> 	#address-cells = <1>;
> 	#size-cells = <1>;
> 	ranges = <0x00 0x00 0x00100000 0x20000>;
> 
> 	phy_gmii_sel: phy@4044 {
> 		compatible = "ti,am654-phy-gmii-sel";
> 		reg = <0x4044 0x8>;
> 		#phy-cells = <1>;
> 	};
> 
> 	...
> };
> 
> If we turn "main_conf" into a syscon, then who "owns" 0x4044?
> Both the top level syscon and phy_gmii_sel nodes would build
> a different regmap instance that contains those same registers.

Two registers is hardly a separate device.

> 
> Bit of back story, this is actually how I got involved in sorting
> out this "syscon" stuff for our devices. I built a checker into
> the regmap framework core that would detect when multiple regmaps
> are created that contain overlapping registers.
> 
> I found several bugs this way and want to push the check upstream at
> some point. But first I wanted to fix the biggest cause of warnings,
> which was from syscon being used as described above.
> 
>>
>>> drivers. How would we synchronize mappings, access, updates, etc.
>>> Any one register should belong to exactly one device.
>>
>> regmap synchronizes everything. There is no problem here, at all.
>>
>>>
>>> Is your issue the name "system controller", as yes I agree some of
>>> these regions are not "system controllers".
>>>
>>> Would it work better if we didn't call this "ti,am62-ddr-pmctrl"
>>> node a "syscon"? That can be done, we just would add a normal
>>> binding doc for it, instead of trying to reuse the generic
>>> bindings/mfd/syscon.yaml file.
>>
>> You still do not have multiple subnodes, one per each register or even
>> few registers.
> 
> If this ddr-pmctrl device is not modeled as a syscon device, then who
> says it has to be more than a few (3?) registers in size? This seems like
> a rather arbitrary rule, and completely unfeasible for several whole
> classes of devices that only have/need a few registers to work them.

What does the syscon description say? Collection of registers, a set of
miscellaneous registers. Registers in plural. Do not use syscon for
other purposes.

It is not arbitrary. It is written in binding description.

Best regards,
Krzysztof

On 4/23/25 7:07 AM, Krzysztof Kozlowski wrote:
> On 21/04/2025 19:03, Andrew Davis wrote:
>> On 4/15/25 12:17 AM, Krzysztof Kozlowski wrote:
>>> On 09/04/2025 19:39, Andrew Davis wrote:
>>>> On 2/12/25 1:35 PM, Krzysztof Kozlowski wrote:
>>>>> On 10/02/2025 11:35, Markus Schneider-Pargmann wrote:
>>>>>> On Sun, Feb 09, 2025 at 01:21:27PM +0100, Krzysztof Kozlowski wrote:
>>>>>>> On 07/02/2025 15:40, Markus Schneider-Pargmann wrote:
>>>>>>>> Hi Krzysztof,
>>>>>>>>
>>>>>>>> On Mon, Jan 27, 2025 at 01:09:49PM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>> On 24/01/2025 23:35, Andrew Davis wrote:
>>>>>>>>>> On 1/24/25 10:48 AM, Krzysztof Kozlowski wrote:
>>>>>>>>>>> On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
>>>>>>>>>>>> Hi Krzysztof,
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>>>>>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>>>>>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
>>>>>>>>>>>>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
>>>>>>>>>>>>>>> register in the wkup-conf register space of am62a and am62p. This
>>>>>>>>>>>>>>> register controls DDR power management.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>      Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>>>>>>>>>>>>>>>      1 file changed, 2 insertions(+)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Un-acked, I missed the point that you really speak in commit msg about
>>>>>>>>>>>>> register and you really treat one register is a device. I assumed you
>>>>>>>>>>>>> only need that register from this device, but no. That obviously is not
>>>>>>>>>>>>> what this device is. Device is not a single register among 10000 others.
>>>>>>>>>>>>> IOW, You do not have 10000 devices there.
>>>>>>>>>>>>
>>>>>>>>>>>> Do I understand you correctly that the whole register range of the
>>>>>>>>>>>> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
>>>>>>>>>>>> should be considered a single syscon device?
>>>>>>>>>>>
>>>>>>>>>>> I don't have the datasheets (and not my task to actually check this),
>>>>>>>>>>> but you should probably follow datasheet. I assume it describes what is
>>>>>>>>>>> the device, more or less.
>>>>>>>>>>>
>>>>>>>>>>> I assume entire wkup_conf is considered a device.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
>>>>>>>>>>>> subnodes defined of which 4 of them consist of a single register. Most
>>>>>>>>>>>> of them are syscon as well. So I think I can't change the simple-bus
>>>>>>>>>>>> back to syscon.
>>>>>>>>>>>
>>>>>>>>>>> Huh... Maybe TI folks will help us understand why such design was chosen.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Many of the devices inside the wkup_conf are already modeled as such.
>>>>>>>>>> Clocks and muxes for instance already have drivers and bindings, this
>>>>>>>>>> is nothing new to TI.
>>>>>>>>>>
>>>>>>>>>> If we just use a blank "syscon" over the entire region we would end up
>>>>>>>>>> with drivers that use phandles to the top level wkup_conf node and
>>>>>>>>>> poke directly the registers they need from that space.
>>>>>>>>>>
>>>>>>>>>> Would you rather have
>>>>>>>>>>
>>>>>>>>>> some-device {
>>>>>>>>>> 	ti,epwm_tbclk = <&wkup_conf>;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> or
>>>>>>>>>>
>>>>>>>>>> some-device {
>>>>>>>>>> 	clocks = <&epwm_tbclk 0>;
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> How is this comparable? These are clocks. You would have clocks property
>>>>>>>>> in both cases.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> with that epwm_tbclk being a proper clock node inside wkup_conf?
>>>>>>>>>> I would much prefer the second, even though the clock node
>>>>>>>>>> only uses a single register. And in the first case, we would need
>>>>>>>>>> to have the offset into the wkup_conf space hard-coded in the
>>>>>>>>>> driver for each new SoC. Eventually all that data would need to be
>>>>>>>>>> put in tables and we end up back to machine board files..
>>>>>>>>>>
>>>>>>>>>> I'm not saying every magic number in all drivers should
>>>>>>>>>> be offloaded into DT, but there is a line somewhere between
>>>>>>>>>> that and having the DT simply contain the SoC's name compatible
>>>>>>>>>
>>>>>>>>> That's not the question here.
>>>>>>>>>
>>>>>>>>>> and all other data going into the kernel. That line might be a
>>>>>>>>>> personal preference, so my question back is: what is wrong
>>>>>>>>>> if we do want "1000 new syscons per each register" for our
>>>>>>>>>> SoCs DT?
>>>>>>>>>
>>>>>>>>> Because it is false representation of hardware. You do not have 1000
>>>>>>>>> devices. You have only one device.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> (and the number is not 1000, scanning the kernel I can see
>>>>>>>>>> the largest wkup_conf region node we have today has a grand
>>>>>>>>>> total number sub-nodes of 6)
>>>>>>>>>
>>>>>>>>> But what is being added here is device per each register, not per feature.
>>>>>>>>
>>>>>>>> The register layout is like this:
>>>>>>>
>>>>>>> The register layout of what? How is the device called? Is datasheet
>>>>>>> available anywhere?
>>>>>>
>>>>>> Yes, it is available here: https://www.ti.com/de/lit/pdf/spruj16
>>>>>>
>>>>>> 14 Registers
>>>>>> 14.2 Device Configuration Registers
>>>>>> 14.2.1 CTRL_MMR Registers
>>>>>> 14.2.1.1 General Purpose Control Registers
>>>>>> 14.2.1.1.3 WKUP_CTRL_MMR0 Registers
>>>>>>
>>>>>> Each domain has their own set of general purpose control registers,
>>>>>> CTRL_MMR for the main domain, MCU_CTRL_MMR0 for the MCU domain,
>>>>>> WKUP_CTRL_MMR0 for the wakeup domain.
>>>>>
>>>>>
>>>>> So according to the doc you have only one device - CTRL_MMR. All other
>>>>> splits are superficial.
>>>>>
>>>>
>>>> It is not one device, it is a collection of devices under one labeled
>>>> bus range. Some items here are full normal devices, already modeled by DT
>>>> as stand-alone devices, for instance our chipid, efuse, clock controller,
>>>> etc. even our pinmux is part of this bus range.
>>>>
>>>> They are grouped as we have one set for each domain (MAIN, WKUP, MCU).
>>>>
>>>> All other splits are not superficial, if we go down that path then
>>>> the whole SoC is one "device". We could simply have the whole address
>>>> bus be one node and have Linux hard-code offsets in the drivers, we
>>>> end up back at board files..
>>>>
>>>> DT should break things into logically distinct and reusable units
>>>> so we don't have to store that in the kernel. That is what we do
>>>> here, even if some units end up being very small.
>>>>
>>>>>>
>>>>>> So I understand this to just be a collection of general purpose control
>>>>>> registers. If you go by feature, then many of the registers can be
>>>>>> grouped into units with a specific purpose or controlling a specific
>>>>>> device which are also grouped by the offsets they represent. I assume
>>>>>
>>>>> It could work if you have distinctive groups, but here:
>>>>> 1. You do not have this grouped, you just judge by yourself "oh, that's
>>>>> group A, that's B".
>>>>> 2. Group per one register is not that.
>>>>>
>>>>> For me this is one big block and even CLKSEL is spread all over so
>>>>> cannot be really made distinctive.
>>>>>
>>>>>> this is why the other nodes in this wkup_conf node were created. Also in
>>>>>
>>>>> The other nodes represent some sort of fake or totally arbitrary
>>>>> grouping. That's abuse of the syscon.
>>>>>
>>>>
>>>> They are grouped by function.
>>>
>>> Not really - other DTS sent just few days ago created each entry per one
>>> register.
>>>
>>>>
>>>>>> my opinion this makes the relation between the original device and this
>>>>>> general purpose control registers better understandable.
>>>>>>
>>>>>> For this patch the ddr-pmctrl regsiter is just a single register, but it
>>>>>> has the purpose of controlling the DDR device power management.
>>>>>
>>>>> Sure, but that is NOT syscon. One register of entire block is not system
>>>>> controller. The entire block is system controller.
>>>>>
>>>>
>>>> The whole block cannot be a system controller as there are regular
>>>> devices inside this range. If we made the whole region a syscon and
>>>
>>> That's still system controller. It's nothing special here.
>>>
>>>> also left the device nodes inside, then we would have overlapping
>>>> register owners, one register would be controlled by two or more
>>>
>>> No, owner is the parent device always.
>>
>> Which parent device? That is my point, if the top level node for the
>> whole CTRL_MMR region is made into one big syscon, then a big regmap
>> is made that covers the whole region. All the child devices also make
> 
> Children take the parent regmap or you do not have even the children.

The parent is a "simple-bus", there is no parent regmap. And before
you say make the parent a "syscon", I've explained why we cannot do
that.

> Actually the second point is what we talk here: you created fake devices
> per each register and these are supposed to be squashed into the parent.
> I am repeating this 3rd time or more.
> 
> 
>> regmaps covering their device range. Now these registers under the child
>> device belong to two different regmaps. No synchronization is done as
>> these are not the same regmap, regmap only handles this for multiple
>> access to registers within the same regmap.
>>
>> Let's take a real example, here is part of AM62A CTRL_MMR node.
>>
>> main_conf: bus@100000 {
>> 	compatible = "simple-bus";
>> 	#address-cells = <1>;
>> 	#size-cells = <1>;
>> 	ranges = <0x00 0x00 0x00100000 0x20000>;
>>
>> 	phy_gmii_sel: phy@4044 {
>> 		compatible = "ti,am654-phy-gmii-sel";
>> 		reg = <0x4044 0x8>;
>> 		#phy-cells = <1>;
>> 	};
>>
>> 	...
>> };
>>
>> If we turn "main_conf" into a syscon, then who "owns" 0x4044?
>> Both the top level syscon and phy_gmii_sel nodes would build
>> a different regmap instance that contains those same registers.
> 
> Two registers is hardly a separate device.
> 

Sure it is, plenty of devices have only a couple registers. There
are already examples all over from all kinds of devices, clocks,
muxes, GPIO extenders, ADCs, DACs, etc. that are real and separate
devices that function perfectly fine while only having one or two
programmable registers.

>>
>> Bit of back story, this is actually how I got involved in sorting
>> out this "syscon" stuff for our devices. I built a checker into
>> the regmap framework core that would detect when multiple regmaps
>> are created that contain overlapping registers.
>>
>> I found several bugs this way and want to push the check upstream at
>> some point. But first I wanted to fix the biggest cause of warnings,
>> which was from syscon being used as described above.
>>
>>>
>>>> drivers. How would we synchronize mappings, access, updates, etc.
>>>> Any one register should belong to exactly one device.
>>>
>>> regmap synchronizes everything. There is no problem here, at all.
>>>
>>>>
>>>> Is your issue the name "system controller", as yes I agree some of
>>>> these regions are not "system controllers".
>>>>
>>>> Would it work better if we didn't call this "ti,am62-ddr-pmctrl"
>>>> node a "syscon"? That can be done, we just would add a normal
>>>> binding doc for it, instead of trying to reuse the generic
>>>> bindings/mfd/syscon.yaml file.
>>>
>>> You still do not have multiple subnodes, one per each register or even
>>> few registers.
>>
>> If this ddr-pmctrl device is not modeled as a syscon device, then who
>> says it has to be more than a few (3?) registers in size? This seems like
>> a rather arbitrary rule, and completely unfeasible for several whole
>> classes of devices that only have/need a few registers to work them.
> 
> What does the syscon description say? Collection of registers, a set of
> miscellaneous registers. Registers in plural. Do not use syscon for
> other purposes.
> 
> It is not arbitrary. It is written in binding description.
> 

Re-read the first sentence: "If this ddr-pmctrl device is *not* modeled
as a syscon device". My comment is that ddr-pmctrl is not a syscon,
and so if we don't include any claim it is a "syscon" in the binding,
why do we have to follow the rules in the unrelated syscon binding
description.

Andrew

> Best regards,
> Krzysztof