Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Hi,

On Thu, 30 Oct 2025 13:01:52 +0200 Matti Vaittinen wrote:

On 30/10/2025 10:54, Lothar Waßmann wrote:

quoted

Hi,

On Wed, 29 Oct 2025 16:35:25 +0100 Maud Spierings wrote:  

quoted

Hi Matti,

On 10/29/25 11:05, Matti Vaittinen wrote:  

quoted

On 29/10/2025 11:48, Lothar Waßmann wrote:  

quoted

Hi,

On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote:  

quoted

On 29/10/2025 09:11, Lothar Waßmann wrote:  

quoted

Hi,

On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote:  

quoted

On 10/28/25 13:42, Maud Spierings wrote:  

quoted

On 10/28/25 13:15, Matti Vaittinen wrote:  

[...]  

quoted

quoted

quoted

Could/Should this be described using the:
'rohm,feedback-pull-up-r1-ohms' and
'rohm,feedback-pull-up-r2-ohms'? If I understand the comment
correctly, that might allow the driver to be able to use correctly
scaled voltages.

https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/
devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108  

// snip

quoted

quoted

quoted

quoted

quoted

If real voltages aren't matching what is calculated by the driver, then
the voltages requested by regulator consumers will cause wrong voltages
to be applied. Debug interfaces will also show wrong voltages, and the
safety limits set in the device-tree will not be really respected.

I think this would be well worth fixing.
    

Before doing the real-life test I did the same calculation that's done
in the driver to be sure that it will generate the correct values:
bc 1.07.1
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017
Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
fb_uv=0
r1=2200
r2=499
min=800000
step=10000
# default voltage without divider
min+30*step
1100000
min=min-(fb_uv-min)*r2/r1
step=step*(r1+r2)/r1
min
981454
step
12268
# default voltage with divider
min+30*step
1349494

Probably we need to use this value rather than the nominal 135000 as
the target voltage in the DTB.  

Yes. When the driver calculates the voltages which match the actual
voltages, then you should also use the actual voltages in the device-tree.
     

// snip

quoted

quoted

Then setting 1349494 as the actual voltage makes it fully work.
Otherwise it complains:
buck6: failed to apply 1350000-1350000uV constraint: -EINVAL

Final debug output now:
[    0.327807] rohm-bd718x7 0-004b: buck6: old range min 800000, step 10000
[    0.327813] rohm-bd718x7 0-004b: new range min 981454, step 12268
[    0.327819] rohm-bd718x7 0-004b: regulator 'buck6' has FB pull-up
configured

I will add this fix to the next version of this patchset and include
your requested change in the dts.
 

Does it also work with min/max settings in the DTS that are taken from
the designated value +/- 5% tolerance margin, so that the DTS contains
reasonable values determined by the HW requirements, rather than some
artificial number that is enforced by the SW behaviour?  

I am unsure what you mean by "artificial number that is enforced by the 
SW behaviour"?

The nominal voltage that is required by the consumer is 1.35 V. That's
the voltage I would expect to set as target for the regulator.
If that voltage cannot be achieved exactly, I would prefer to have the
intended voltage listed explicitly rather than listing a value that
accidentally can be achieved by the regulator but has nothing to do with
the requirements of the consumer.

I don't know why there should be two different min values? Assuming the 
latter should be max - I have no problem seeing a range of allowed 

My copypaste is obviously spoiled... ;)


Lothar Waßmann