[PATCH 6.6 1/4] riscv: dts: starfive: add assigned-clock* to limit frquency

[PATCH 6.6 1/4] riscv: dts: starfive: add assigned-clock* to limit frquency

[WangYuli]

From: William Qiu <william.qiu@starfivetech.com>

In JH7110 SoC, we need to go by-pass mode, so we need add the
assigned-clock* properties to limit clock frquency.

Signed-off-by: William Qiu <william.qiu@starfivetech.com>
Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: WangYuli <wangyuli@uniontech.com>
---
 .../riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
index 062b97c6e7df..4874e3bb42ab 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
@@ -204,6 +204,8 @@ &i2c6 {
 
 &mmc0 {
 	max-frequency = <100000000>;
+	assigned-clocks = <&syscrg JH7110_SYSCLK_SDIO0_SDCARD>;
+	assigned-clock-rates = <50000000>;
 	bus-width = <8>;
 	cap-mmc-highspeed;
 	mmc-ddr-1_8v;
@@ -220,6 +222,8 @@ &mmc0 {
 
 &mmc1 {
 	max-frequency = <100000000>;
+	assigned-clocks = <&syscrg JH7110_SYSCLK_SDIO1_SDCARD>;
+	assigned-clock-rates = <50000000>;
 	bus-width = <4>;
 	no-sdio;
 	no-mmc;
-- 
2.43.4

Re: [PATCH 6.6 1/4] riscv: dts: starfive: add assigned-clock* to limit frquency

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

On Mon, Sep 09, 2024 at 03:46:27PM +0800, WangYuli wrote:
> From: William Qiu <william.qiu@starfivetech.com>
> 
> In JH7110 SoC, we need to go by-pass mode, so we need add the
> assigned-clock* properties to limit clock frquency.
> 
> Signed-off-by: William Qiu <william.qiu@starfivetech.com>
> Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: WangYuli <wangyuli@uniontech.com>

What makes any of the patches in this 4 patch series stable material?

Confused,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 6.6 1/4] riscv: dts: starfive: add assigned-clock* to limit frquency

[Krzysztof Kozlowski]

On 09/09/2024 12:17, Conor Dooley wrote:
> On Mon, Sep 09, 2024 at 03:46:27PM +0800, WangYuli wrote:
>> From: William Qiu <william.qiu@starfivetech.com>
>>
>> In JH7110 SoC, we need to go by-pass mode, so we need add the
>> assigned-clock* properties to limit clock frquency.
>>
>> Signed-off-by: William Qiu <william.qiu@starfivetech.com>
>> Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
>> Signed-off-by: WangYuli <wangyuli@uniontech.com>
> 
> What makes any of the patches in this 4 patch series stable material?

That's for stable? It needs to follow stable process rules, so proper
commit ID.

Best regards,
Krzysztof

Re: [PATCH 6.6 1/4] riscv: dts: starfive: add assigned-clock* to limit frquency

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

On Mon, Sep 09, 2024 at 12:38:23PM +0200, Krzysztof Kozlowski wrote:
> On 09/09/2024 12:17, Conor Dooley wrote:
> > On Mon, Sep 09, 2024 at 03:46:27PM +0800, WangYuli wrote:
> >> From: William Qiu <william.qiu@starfivetech.com>
> >>
> >> In JH7110 SoC, we need to go by-pass mode, so we need add the
> >> assigned-clock* properties to limit clock frquency.
> >>
> >> Signed-off-by: William Qiu <william.qiu@starfivetech.com>
> >> Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> >> Signed-off-by: WangYuli <wangyuli@uniontech.com>
> > 
> > What makes any of the patches in this 4 patch series stable material?
> 
> That's for stable? It needs to follow stable process rules, so proper
> commit ID.

[6.6] in the subject and Sasha/Greg/stable list on CC, so I figure it is
for stable, yeah. Only one of these patches is a "fix", and not really a
functional one, so I would like to know why this stuff is being
backported. I think under some definition of "new device IDs and quirks"
it could be suitable, but it'd be a looser definition than I personally
agree with!

Oh, and also, the 4 patches aren't threaded - you should fix that
WangYuli.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 6.6 1/4] riscv: dts: starfive: add assigned-clock* to limit frquency

[Greg KH]

On Mon, Sep 09, 2024 at 03:46:27PM +0800, WangYuli wrote:
> From: William Qiu <william.qiu@starfivetech.com>
> 
> In JH7110 SoC, we need to go by-pass mode, so we need add the
> assigned-clock* properties to limit clock frquency.
> 
> Signed-off-by: William Qiu <william.qiu@starfivetech.com>
> Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: WangYuli <wangyuli@uniontech.com>
> ---
>  .../riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi | 4 ++++
>  1 file changed, 4 insertions(+)

What is the git id of this change in Linus's tree?

Please fix this up and resend all 4 patches with the needed information.

thanks,

greg k-h

Re: [PATCH 6.6 1/4] riscv: dts: starfive: add assigned-clock* to limit frquency

[WangYuli]

On 2024/9/9 19:17, Conor Dooley wrote:
> [6.6] in the subject and Sasha/Greg/stable list on CC, so I figure it is
> for stable, yeah. Only one of these patches is a "fix", and not really a
> functional one, so I would like to know why this stuff is being
> backported. I think under some definition of "new device IDs and quirks"
> it could be suitable, but it'd be a looser definition than I personally
> agree with!
These submissions will help to ensure a more stable behavior for the 
RISC-V devices involved on the Linux-6.6.y kernel,and as far as I can 
tell,they won't introduce any new issues (please correct me if I'm wrong).
> Oh, and also, the 4 patches aren't threaded - you should fix that

I apologize for my ignorance about the correct procedure...

For instance,for these four commits,I first used 'git format-patch -4' 
to create four consecutive .patch files,and then used 'git send-email 
--annotate --cover-letter --thread ./*.patch' to send them,but the 
result wasn't as expected...

I'm not sure where the problem lies...

> WangYuli.
QAQ
-- 
WangYuli

Re: [PATCH 6.6 1/4] riscv: dts: starfive: add assigned-clock* to limit frquency

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

On Thu, Sep 12, 2024 at 10:38:20AM +0800, WangYuli wrote:
> 
> On 2024/9/9 19:17, Conor Dooley wrote:
> > [6.6] in the subject and Sasha/Greg/stable list on CC, so I figure it is
> > for stable, yeah. Only one of these patches is a "fix", and not really a
> > functional one, so I would like to know why this stuff is being
> > backported. I think under some definition of "new device IDs and quirks"
> > it could be suitable, but it'd be a looser definition than I personally
> > agree with!
> These submissions will help to ensure a more stable behavior for the RISC-V
> devices involved on the Linux-6.6.y kernel,

I'll accept that argument for the first patch, but the three that are
adding support for audio devices on the platform cannot really be
described as making behaviour more stable. I don't hugely object to
these being backported, but I would like a more accurate justification
for it being done - even if that is just that "we are using this board
with 6.6 and would like audio to work, which these 3 simple patches
allow it to do".

> and as far as I can tell,they
> won't introduce any new issues (please correct me if I'm wrong).

I don't know. Does this first patch require a driver change for the
mmc driver to work correctly?

> > Oh, and also, the 4 patches aren't threaded - you should fix that
> 
> I apologize for my ignorance about the correct procedure...
> 
> For instance,for these four commits,I first used 'git format-patch -4' to
> create four consecutive .patch files,and then used 'git send-email
> --annotate --cover-letter --thread ./*.patch' to send them,but the result
> wasn't as expected...
> 
> I'm not sure where the problem lies...

I'm not sure, I don't send patches using that method. Usually I output
my patches to a directory and call git send-email using the path to that
directory.

Cheers,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]