Re: 回复: [DMARC error] [PATCH v3 3/3] arm64: dts: meson-s4-s905y4-khadas-vim1s: add initial device tree

From: George Stark <gnstark@salutedevices.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Nick Xie <nick@khadas.com>, "robh@kernel.org" <robh@kernel.org>,
	"khilman@baylibre.com" <khilman@baylibre.com>,
	"jbrunet@baylibre.com" <jbrunet@baylibre.com>,
	"neil.armstrong@linaro.org" <neil.armstrong@linaro.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-amlogic@lists.infradead.org"
	<linux-amlogic@lists.infradead.org>,
	"conor+dt@kernel.org" <conor+dt@kernel.org>,
	"kernel@salutedevices.com" <kernel@salutedevices.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
	"xianwei.zhao@amlogic.com" <xianwei.zhao@amlogic.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: 回复: [DMARC error] [PATCH v3 3/3] arm64: dts: meson-s4-s905y4-khadas-vim1s: add initial device tree
Date: Fri, 13 Feb 2026 14:00:38 +0300	[thread overview]
Message-ID: <c1ec5f03-2fc5-4c63-91df-747f0bfd86c2@salutedevices.com> (raw)
In-Reply-To: <CAFBinCDcDy4M79+mM+axsqXLfoQ56Ucd1C-OHkGLxwNkpfZ-zQ@mail.gmail.com>

On 2/10/26 01:31, Martin Blumenstingl wrote:
> Hi George,
> 
> sorry for the late reply.
> 
> On Thu, Jan 29, 2026 at 3:48 PM George Stark <gnstark@salutedevices.com> wrote:

Hello Martin. It's great to hear from you again.
>>
>>
>> On 1/26/26 12:35, Nick Xie wrote:
>>>> Thanks for the patch. Since you have khadas mail I'm pretty sure you've
>>>> had the possibility to test it on the real vim board and I just don't
>>>> get it how it works with the voltage table above. The problem is that
>>>> pwm is calculated incorrectly in the upstream pwm-meson driver. That
>>>> voltage table appeared to be used in early amlogic bl loader and
>>>> appropriate pwm is initialized from a table's record. Duty cycle value
>>>> is translated to pwm regs correctly. Later when kernel start running
>>>> pwm-regulator driver is probed. It reads the pwm regs, calculates back
>>>> duty-cyle and search it in the table. Since calculation algos are not
>>>> match and the table doesn't contain full range of 0-100% values
>>>> regulator driver doesn't find current voltage. In such case regulator
>>>> core sets the minimum voltage from the table [1] and the SoC may hang
>>>> (depending on board) due to minimum voltage may be too low for the
>>>> current frequency SoC uses.
> Nick likely didn't spot any issues on S4 since CPU frequency scaling
> is not upstreamed yet (as there's no way to control the CPU clock
> yet).
> The lack of a OPP table means: the PWM and CPU clock will just stay at
> whatever the bootloader provides

It makes sense. I should experiment on the latest kernel.

>>>> Or I'm missing something?
>>>
>>>
>>>> There's not-yet-reviewed patch that fixes pwm algo [2]. There's
>>>> calculation example in the cover letter.
>>>> [1] https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/regulator/core.c#L1227
>>>> [2] https://lkml.iu.edu/2412.3/00826.html
>>>
>>> What's the status of such patches?
>>
>> the patch is ready for review. It's seems like nobody is interested
> I'm sorry to see that the patch had it's first anniversary.
> I'll need to bring out my logic analyzer and test your patch (I hope
> it's precise enough to show the impact of your changes).
> Are your plans then to re-send the patches or have you moved on and
> need someone else to take care of it?

It's a major step anyway if you confirm the issue yourself with an 
analyzer. In that case discussion won't be delayed for one more year
I think. Thanks.

Sure I'm ready to discuss/fix/resend this patch.

-- 
Best regards
George

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic