2024-03-10 13:30:38

by Frank Oltmanns

[permalink] [raw]
Subject: [PATCH v4 1/5] clk: sunxi-ng: common: Support minimum and maximum rate

The Allwinner SoC's typically have an upper and lower limit for their
clocks' rates. Up until now, support for that has been implemented
separately for each clock type.

Implement that functionality in the sunxi-ng's common part making use of
the CCF rate liming capabilities, so that it is available for all clock
types.

Suggested-by: Maxime Ripard <[email protected]>
Signed-off-by: Frank Oltmanns <[email protected]>
Cc: [email protected]
---
drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++
drivers/clk/sunxi-ng/ccu_common.h | 3 +++
2 files changed, 22 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-ng/ccu_common.c
index 8babce55302f..ac0091b4ce24 100644
--- a/drivers/clk/sunxi-ng/ccu_common.c
+++ b/drivers/clk/sunxi-ng/ccu_common.c
@@ -44,6 +44,16 @@ bool ccu_is_better_rate(struct ccu_common *common,
unsigned long current_rate,
unsigned long best_rate)
{
+ unsigned long min_rate, max_rate;
+
+ clk_hw_get_rate_range(&common->hw, &min_rate, &max_rate);
+
+ if (current_rate > max_rate)
+ return false;
+
+ if (current_rate < min_rate)
+ return false;
+
if (common->features & CCU_FEATURE_CLOSEST_RATE)
return abs(current_rate - target_rate) < abs(best_rate - target_rate);

@@ -122,6 +132,7 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,

for (i = 0; i < desc->hw_clks->num ; i++) {
struct clk_hw *hw = desc->hw_clks->hws[i];
+ struct ccu_common *common = hw_to_ccu_common(hw);
const char *name;

if (!hw)
@@ -136,6 +147,14 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
pr_err("Couldn't register clock %d - %s\n", i, name);
goto err_clk_unreg;
}
+
+ if (common->max_rate)
+ clk_hw_set_rate_range(hw, common->min_rate,
+ common->max_rate);
+ else
+ WARN(common->min_rate,
+ "No max_rate, ignoring min_rate of clock %d - %s\n",
+ i, name);
}

ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get,
diff --git a/drivers/clk/sunxi-ng/ccu_common.h b/drivers/clk/sunxi-ng/ccu_common.h
index 942a72c09437..329734f8cf42 100644
--- a/drivers/clk/sunxi-ng/ccu_common.h
+++ b/drivers/clk/sunxi-ng/ccu_common.h
@@ -31,6 +31,9 @@ struct ccu_common {
u16 lock_reg;
u32 prediv;

+ unsigned long min_rate;
+ unsigned long max_rate;
+
unsigned long features;
spinlock_t *lock;
struct clk_hw hw;

--
2.44.0



2024-03-13 19:07:23

by Jernej Škrabec

[permalink] [raw]
Subject: Re: [PATCH v4 1/5] clk: sunxi-ng: common: Support minimum and maximum rate

Dne nedelja, 10. marec 2024 ob 14:21:11 CET je Frank Oltmanns napisal(a):
> The Allwinner SoC's typically have an upper and lower limit for their
> clocks' rates. Up until now, support for that has been implemented
> separately for each clock type.
>
> Implement that functionality in the sunxi-ng's common part making use of
> the CCF rate liming capabilities, so that it is available for all clock
> types.
>
> Suggested-by: Maxime Ripard <[email protected]>
> Signed-off-by: Frank Oltmanns <[email protected]>
> Cc: [email protected]

This looks pretty nice now.

Reviewed-by: Jernej Skrabec <[email protected]>

Best regards,
Jernej

> ---
> drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++
> drivers/clk/sunxi-ng/ccu_common.h | 3 +++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-ng/ccu_common.c
> index 8babce55302f..ac0091b4ce24 100644
> --- a/drivers/clk/sunxi-ng/ccu_common.c
> +++ b/drivers/clk/sunxi-ng/ccu_common.c
> @@ -44,6 +44,16 @@ bool ccu_is_better_rate(struct ccu_common *common,
> unsigned long current_rate,
> unsigned long best_rate)
> {
> + unsigned long min_rate, max_rate;
> +
> + clk_hw_get_rate_range(&common->hw, &min_rate, &max_rate);
> +
> + if (current_rate > max_rate)
> + return false;
> +
> + if (current_rate < min_rate)
> + return false;
> +
> if (common->features & CCU_FEATURE_CLOSEST_RATE)
> return abs(current_rate - target_rate) < abs(best_rate - target_rate);
>
> @@ -122,6 +132,7 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
>
> for (i = 0; i < desc->hw_clks->num ; i++) {
> struct clk_hw *hw = desc->hw_clks->hws[i];
> + struct ccu_common *common = hw_to_ccu_common(hw);
> const char *name;
>
> if (!hw)
> @@ -136,6 +147,14 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
> pr_err("Couldn't register clock %d - %s\n", i, name);
> goto err_clk_unreg;
> }
> +
> + if (common->max_rate)
> + clk_hw_set_rate_range(hw, common->min_rate,
> + common->max_rate);
> + else
> + WARN(common->min_rate,
> + "No max_rate, ignoring min_rate of clock %d - %s\n",
> + i, name);
> }
>
> ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get,
> diff --git a/drivers/clk/sunxi-ng/ccu_common.h b/drivers/clk/sunxi-ng/ccu_common.h
> index 942a72c09437..329734f8cf42 100644
> --- a/drivers/clk/sunxi-ng/ccu_common.h
> +++ b/drivers/clk/sunxi-ng/ccu_common.h
> @@ -31,6 +31,9 @@ struct ccu_common {
> u16 lock_reg;
> u32 prediv;
>
> + unsigned long min_rate;
> + unsigned long max_rate;
> +
> unsigned long features;
> spinlock_t *lock;
> struct clk_hw hw;
>
>





2024-03-15 13:05:06

by Maxime Ripard

[permalink] [raw]
Subject: Re: [PATCH v4 1/5] clk: sunxi-ng: common: Support minimum and maximum rate

On Sun, 10 Mar 2024 14:21:11 +0100, Frank Oltmanns wrote:
> The Allwinner SoC's typically have an upper and lower limit for their
> clocks' rates. Up until now, support for that has been implemented
> separately for each clock type.
>
> Implement that functionality in the sunxi-ng's common part making use of
>
> [ ... ]

Acked-by: Maxime Ripard <[email protected]>

Thanks!
Maxime

2024-05-21 13:43:18

by Måns Rullgård

[permalink] [raw]
Subject: Re: [PATCH v4 1/5] clk: sunxi-ng: common: Support minimum and maximum rate

Frank Oltmanns <[email protected]> writes:

> The Allwinner SoC's typically have an upper and lower limit for their
> clocks' rates. Up until now, support for that has been implemented
> separately for each clock type.
>
> Implement that functionality in the sunxi-ng's common part making use of
> the CCF rate liming capabilities, so that it is available for all clock
> types.
>
> Suggested-by: Maxime Ripard <[email protected]>
> Signed-off-by: Frank Oltmanns <[email protected]>
> Cc: [email protected]
> ---
> drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++
> drivers/clk/sunxi-ng/ccu_common.h | 3 +++
> 2 files changed, 22 insertions(+)

This just landed in 6.6 stable, and it broke HDMI output on an A20 based
device, the clocks ending up all wrong as seen in this diff of
/sys/kernel/debug/clk/clk_summary:

@@ -70,16 +71,14 @@
apb1-i2c0 0 0 0 24000000 0

pll-gpu 0 0 0 1200000000 0
- pll-video1 3 3 1 159000000 0
+ pll-video1 2 2 1 159000000 0
hdmi 1 1 0 39750000 0

tcon0-ch1-sclk2 1 1 1 39750000 0
tcon0-ch1-sclk1 1 1 1 39750000 0

- pll-video1-2x 1 1 0 318000000 0
+ pll-video1-2x 0 0 0 318000000 0

- hdmi-tmds 2 2 0 39750000 0
- hdmi-ddc 1 1 0 1987500 0
pll-periph-base 2 2 0 1200000000 0
mbus 1 1 0 300000000 0
pll-periph-sata 0 0 0 100000000 0
@@ -199,7 +198,7 @@

ace 0 0 0 384000000 0
ve 0 0 0 384000000 0
- pll-video0 4 4 2 297000000 0
+ pll-video0 5 5 2 297000000 0
hdmi1 0 0 0 297000000 0
tcon1-ch1-sclk2 0 0 0 297000000 0
tcon1-ch1-sclk1 0 0 0 297000000 0
@@ -222,8 +221,10 @@

de-be0 1 1 1 297000000 0

- pll-video0-2x 0 0 0 594000000 0
+ pll-video0-2x 1 1 0 594000000 0

+ hdmi-tmds 2 2 0 594000000 0
+ hdmi-ddc 1 1 0 29700000 0
pll-audio-base 0 0 0 1500000 0
pll-audio-8x 0 0 0 3000000 0
i2s2 0 0 0 3000000 0

Reverting this commit makes it work again.

> diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-ng/ccu_common.c
> index 8babce55302f..ac0091b4ce24 100644
> --- a/drivers/clk/sunxi-ng/ccu_common.c
> +++ b/drivers/clk/sunxi-ng/ccu_common.c
> @@ -44,6 +44,16 @@ bool ccu_is_better_rate(struct ccu_common *common,
> unsigned long current_rate,
> unsigned long best_rate)
> {
> + unsigned long min_rate, max_rate;
> +
> + clk_hw_get_rate_range(&common->hw, &min_rate, &max_rate);
> +
> + if (current_rate > max_rate)
> + return false;
> +
> + if (current_rate < min_rate)
> + return false;
> +
> if (common->features & CCU_FEATURE_CLOSEST_RATE)
> return abs(current_rate - target_rate) < abs(best_rate - target_rate);
>
> @@ -122,6 +132,7 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
>
> for (i = 0; i < desc->hw_clks->num ; i++) {
> struct clk_hw *hw = desc->hw_clks->hws[i];
> + struct ccu_common *common = hw_to_ccu_common(hw);
> const char *name;
>
> if (!hw)
> @@ -136,6 +147,14 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
> pr_err("Couldn't register clock %d - %s\n", i, name);
> goto err_clk_unreg;
> }
> +
> + if (common->max_rate)
> + clk_hw_set_rate_range(hw, common->min_rate,
> + common->max_rate);
> + else
> + WARN(common->min_rate,
> + "No max_rate, ignoring min_rate of clock %d - %s\n",
> + i, name);
> }
>
> ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get,
> diff --git a/drivers/clk/sunxi-ng/ccu_common.h b/drivers/clk/sunxi-ng/ccu_common.h
> index 942a72c09437..329734f8cf42 100644
> --- a/drivers/clk/sunxi-ng/ccu_common.h
> +++ b/drivers/clk/sunxi-ng/ccu_common.h
> @@ -31,6 +31,9 @@ struct ccu_common {
> u16 lock_reg;
> u32 prediv;
>
> + unsigned long min_rate;
> + unsigned long max_rate;
> +
> unsigned long features;
> spinlock_t *lock;
> struct clk_hw hw;
>
> --
>
> 2.44.0
>

--
M?ns Rullg?rd

2024-05-22 06:33:35

by Frank Oltmanns

[permalink] [raw]
Subject: Re: [PATCH v4 1/5] clk: sunxi-ng: common: Support minimum and maximum rate

Hi Måns,

21.05.2024 15:43:10 Måns Rullgård <[email protected]>:

> Frank Oltmanns <[email protected]> writes:
>
>> The Allwinner SoC's typically have an upper and lower limit for their
>> clocks' rates. Up until now, support for that has been implemented
>> separately for each clock type.
>>
>> Implement that functionality in the sunxi-ng's common part making use of
>> the CCF rate liming capabilities, so that it is available for all clock
>> types.
>>
>> Suggested-by: Maxime Ripard <[email protected]>
>> Signed-off-by: Frank Oltmanns <[email protected]>
>> Cc: [email protected]
>> ---
>> drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++
>> drivers/clk/sunxi-ng/ccu_common.h |  3 +++
>> 2 files changed, 22 insertions(+)
>
> This just landed in 6.6 stable, and it broke HDMI output on an A20 based
> device, the clocks ending up all wrong as seen in this diff of
> /sys/kernel/debug/clk/clk_summary:
>
> @@ -70,16 +71,14 @@
>            apb1-i2c0                  0       0        0        24000000    0  
>                                                                                
>         pll-gpu                       0       0        0        1200000000  0  
> -       pll-video1                    3       3        1        159000000   0  
> +       pll-video1                    2       2        1        159000000   0  
>            hdmi                       1       1        0        39750000    0  
>                                                                                
>            tcon0-ch1-sclk2            1       1        1        39750000    0  
>               tcon0-ch1-sclk1         1       1        1        39750000    0  
>                                                                                
> -          pll-video1-2x              1       1        0        318000000   0  
> +          pll-video1-2x              0       0        0        318000000   0  
>                                                                                
> -             hdmi-tmds               2       2        0        39750000    0  
> -                hdmi-ddc             1       1        0        1987500     0  
>         pll-periph-base               2       2        0        1200000000  0  
>            mbus                       1       1        0        300000000   0  
>            pll-periph-sata            0       0        0        100000000   0  
> @@ -199,7 +198,7 @@
>                                                                                
>            ace                        0       0        0        384000000   0  
>            ve                         0       0        0        384000000   0  
> -       pll-video0                    4       4        2        297000000   0  
> +       pll-video0                    5       5        2        297000000   0  
>            hdmi1                      0       0        0        297000000   0  
>            tcon1-ch1-sclk2            0       0        0        297000000   0  
>               tcon1-ch1-sclk1         0       0        0        297000000   0  
> @@ -222,8 +221,10 @@
>                                                                                
>            de-be0                     1       1        1        297000000   0  
>                                                                                
> -          pll-video0-2x              0       0        0        594000000   0  
> +          pll-video0-2x              1       1        0        594000000   0  
>                                                                                
> +             hdmi-tmds               2       2        0        594000000   0  
> +                hdmi-ddc             1       1        0        29700000    0  
>         pll-audio-base                0       0        0        1500000     0  
>            pll-audio-8x               0       0        0        3000000     0  
>               i2s2                    0       0        0        3000000     0  
>
> Reverting this commit makes it work again.

Thank you for your detailed report!

I've had a first look at hdmi-tmds and hdmi-ddc, and neither seems to be calling ccu_is_better_rate() in their determine_rate() functions. Their parents have the exact same rates in your diff, so, my current working assumption is that they can't be the cause either.

I'll have a more detailed look over the weekend. Until then, if anyone has some ideas where I should have a look next, please share your thoughts.

Best regards,
  Frank

>
>> diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-ng/ccu_common.c
>> index 8babce55302f..ac0091b4ce24 100644
>> --- a/drivers/clk/sunxi-ng/ccu_common.c
>> +++ b/drivers/clk/sunxi-ng/ccu_common.c
>> @@ -44,6 +44,16 @@ bool ccu_is_better_rate(struct ccu_common *common,
>>             unsigned long current_rate,
>>             unsigned long best_rate)
>> {
>> +   unsigned long min_rate, max_rate;
>> +
>> +   clk_hw_get_rate_range(&common->hw, &min_rate, &max_rate);
>> +
>> +   if (current_rate > max_rate)
>> +       return false;
>> +
>> +   if (current_rate < min_rate)
>> +       return false;
>> +
>>     if (common->features & CCU_FEATURE_CLOSEST_RATE)
>>         return abs(current_rate - target_rate) < abs(best_rate - target_rate);
>>
>> @@ -122,6 +132,7 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
>>
>>     for (i = 0; i < desc->hw_clks->num ; i++) {
>>         struct clk_hw *hw = desc->hw_clks->hws[i];
>> +       struct ccu_common *common = hw_to_ccu_common(hw);
>>         const char *name;
>>
>>         if (!hw)
>> @@ -136,6 +147,14 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
>>             pr_err("Couldn't register clock %d - %s\n", i, name);
>>             goto err_clk_unreg;
>>         }
>> +
>> +       if (common->max_rate)
>> +           clk_hw_set_rate_range(hw, common->min_rate,
>> +                         common->max_rate);
>> +       else
>> +           WARN(common->min_rate,
>> +                "No max_rate, ignoring min_rate of clock %d - %s\n",
>> +                i, name);
>>     }
>>
>>     ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get,
>> diff --git a/drivers/clk/sunxi-ng/ccu_common.h b/drivers/clk/sunxi-ng/ccu_common.h
>> index 942a72c09437..329734f8cf42 100644
>> --- a/drivers/clk/sunxi-ng/ccu_common.h
>> +++ b/drivers/clk/sunxi-ng/ccu_common.h
>> @@ -31,6 +31,9 @@ struct ccu_common {
>>     u16     lock_reg;
>>     u32     prediv;
>>
>> +   unsigned long   min_rate;
>> +   unsigned long   max_rate;
>> +
>>     unsigned long   features;
>>     spinlock_t  *lock;
>>     struct clk_hw   hw;
>>
>> --
>>
>> 2.44.0
>>
>
> --
> Måns Rullgård

2024-05-22 18:07:50

by Måns Rullgård

[permalink] [raw]
Subject: Re: [PATCH v4 1/5] clk: sunxi-ng: common: Support minimum and maximum rate

Frank Oltmanns <[email protected]> writes:

> Hi M?ns,
>
> 21.05.2024 15:43:10 M?ns Rullg?rd <[email protected]>:
>
>> Frank Oltmanns <[email protected]> writes:
>>
>>> The Allwinner SoC's typically have an upper and lower limit for their
>>> clocks' rates. Up until now, support for that has been implemented
>>> separately for each clock type.
>>>
>>> Implement that functionality in the sunxi-ng's common part making use of
>>> the CCF rate liming capabilities, so that it is available for all clock
>>> types.
>>>
>>> Suggested-by: Maxime Ripard <[email protected]>
>>> Signed-off-by: Frank Oltmanns <[email protected]>
>>> Cc: [email protected]
>>> ---
>>> drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++
>>> drivers/clk/sunxi-ng/ccu_common.h |? 3 +++
>>> 2 files changed, 22 insertions(+)
>>
>> This just landed in 6.6 stable, and it broke HDMI output on an A20 based
>> device, the clocks ending up all wrong as seen in this diff of
>> /sys/kernel/debug/clk/clk_summary:
>>
>> @@ -70,16 +71,14 @@
>> ?????????? apb1-i2c0????????????????? 0?????? 0??????? 0??????? 24000000??? 0
>>
>> ??????? pll-gpu?????????????????????? 0?????? 0??????? 0??????? 1200000000? 0
>> -?????? pll-video1??????????????????? 3?????? 3??????? 1??????? 159000000?? 0
>> +?????? pll-video1??????????????????? 2?????? 2??????? 1??????? 159000000?? 0
>> ?????????? hdmi?????????????????????? 1?????? 1??????? 0??????? 39750000??? 0
>>
>> ?????????? tcon0-ch1-sclk2??????????? 1?????? 1??????? 1??????? 39750000??? 0
>> ????????????? tcon0-ch1-sclk1???????? 1?????? 1??????? 1??????? 39750000??? 0
>>
>> -????????? pll-video1-2x????????????? 1?????? 1??????? 0??????? 318000000?? 0
>> +????????? pll-video1-2x????????????? 0?????? 0??????? 0??????? 318000000?? 0
>>
>> -???????????? hdmi-tmds?????????????? 2?????? 2??????? 0??????? 39750000??? 0
>> -??????????????? hdmi-ddc???????????? 1?????? 1??????? 0??????? 1987500???? 0
>> ??????? pll-periph-base?????????????? 2?????? 2??????? 0??????? 1200000000? 0
>> ?????????? mbus?????????????????????? 1?????? 1??????? 0??????? 300000000?? 0
>> ?????????? pll-periph-sata??????????? 0?????? 0??????? 0??????? 100000000?? 0
>> @@ -199,7 +198,7 @@
>>
>> ?????????? ace??????????????????????? 0?????? 0??????? 0??????? 384000000?? 0
>> ?????????? ve???????????????????????? 0?????? 0??????? 0??????? 384000000?? 0
>> -?????? pll-video0??????????????????? 4?????? 4??????? 2??????? 297000000?? 0
>> +?????? pll-video0??????????????????? 5?????? 5??????? 2??????? 297000000?? 0
>> ?????????? hdmi1????????????????????? 0?????? 0??????? 0??????? 297000000?? 0
>> ?????????? tcon1-ch1-sclk2??????????? 0?????? 0??????? 0??????? 297000000?? 0
>> ????????????? tcon1-ch1-sclk1???????? 0?????? 0??????? 0??????? 297000000?? 0
>> @@ -222,8 +221,10 @@
>>
>> ?????????? de-be0???????????????????? 1?????? 1??????? 1??????? 297000000?? 0
>>
>> -????????? pll-video0-2x????????????? 0?????? 0??????? 0??????? 594000000?? 0
>> +????????? pll-video0-2x????????????? 1?????? 1??????? 0??????? 594000000?? 0
>>
>> +???????????? hdmi-tmds?????????????? 2?????? 2??????? 0??????? 594000000?? 0
>> +??????????????? hdmi-ddc???????????? 1?????? 1??????? 0??????? 29700000??? 0
>> ??????? pll-audio-base??????????????? 0?????? 0??????? 0??????? 1500000???? 0
>> ?????????? pll-audio-8x?????????????? 0?????? 0??????? 0??????? 3000000???? 0
>> ????????????? i2s2??????????????????? 0?????? 0??????? 0??????? 3000000???? 0
>>
>> Reverting this commit makes it work again.
>
> Thank you for your detailed report!
>
> I've had a first look at hdmi-tmds and hdmi-ddc, and neither seems to
> be calling ccu_is_better_rate() in their determine_rate()
> functions. Their parents have the exact same rates in your diff, so,
> my current working assumption is that they can't be the cause either.
>
> I'll have a more detailed look over the weekend. Until then, if anyone
> has some ideas where I should have a look next, please share your
> thoughts.

In case it's relevant, this system doesn't use the HDMI DDC, the
physical DDC pins being connected to a different I2C adapter for
various reasons.

From the clk_summary diff, I see a few things:

1. hdmi-tmds has changed parent from pll-video1-2x to pll-video0-2x.
2. The ratio of hdmi-tmds to its parent has changed from 1/8 to 1.
3. The resulting rate bears no relation to the pixel clock from EDID.

I tried kernel 6.9.1 as well, and that doesn't work either. I'll keep
digging and try to narrow it down.

>>> diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-ng/ccu_common.c
>>> index 8babce55302f..ac0091b4ce24 100644
>>> --- a/drivers/clk/sunxi-ng/ccu_common.c
>>> +++ b/drivers/clk/sunxi-ng/ccu_common.c
>>> @@ -44,6 +44,16 @@ bool ccu_is_better_rate(struct ccu_common *common,
>>> ??????????? unsigned long current_rate,
>>> ??????????? unsigned long best_rate)
>>> {
>>> +?? unsigned long min_rate, max_rate;
>>> +
>>> +?? clk_hw_get_rate_range(&common->hw, &min_rate, &max_rate);
>>> +
>>> +?? if (current_rate > max_rate)
>>> +?????? return false;
>>> +
>>> +?? if (current_rate < min_rate)
>>> +?????? return false;
>>> +
>>> ??? if (common->features & CCU_FEATURE_CLOSEST_RATE)
>>> ??????? return abs(current_rate - target_rate) < abs(best_rate - target_rate);
>>>
>>> @@ -122,6 +132,7 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
>>>
>>> ??? for (i = 0; i < desc->hw_clks->num ; i++) {
>>> ??????? struct clk_hw *hw = desc->hw_clks->hws[i];
>>> +?????? struct ccu_common *common = hw_to_ccu_common(hw);
>>> ??????? const char *name;
>>>
>>> ??????? if (!hw)
>>> @@ -136,6 +147,14 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device *dev,
>>> ??????????? pr_err("Couldn't register clock %d - %s\n", i, name);
>>> ??????????? goto err_clk_unreg;
>>> ??????? }
>>> +
>>> +?????? if (common->max_rate)
>>> +?????????? clk_hw_set_rate_range(hw, common->min_rate,
>>> +???????????????????????? common->max_rate);
>>> +?????? else
>>> +?????????? WARN(common->min_rate,
>>> +??????????????? "No max_rate, ignoring min_rate of clock %d - %s\n",
>>> +??????????????? i, name);
>>> ??? }
>>>
>>> ??? ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get,
>>> diff --git a/drivers/clk/sunxi-ng/ccu_common.h b/drivers/clk/sunxi-ng/ccu_common.h
>>> index 942a72c09437..329734f8cf42 100644
>>> --- a/drivers/clk/sunxi-ng/ccu_common.h
>>> +++ b/drivers/clk/sunxi-ng/ccu_common.h
>>> @@ -31,6 +31,9 @@ struct ccu_common {
>>> ??? u16???? lock_reg;
>>> ??? u32???? prediv;
>>>
>>> +?? unsigned long?? min_rate;
>>> +?? unsigned long?? max_rate;
>>> +
>>> ??? unsigned long?? features;
>>> ??? spinlock_t? *lock;
>>> ??? struct clk_hw?? hw;
>>>
>>> --
>>>
>>> 2.44.0
>>>
>>
>> --
>> M?ns Rullg?rd
>

--
M?ns Rullg?rd

2024-05-23 18:58:18

by Måns Rullgård

[permalink] [raw]
Subject: Re: [PATCH v4 1/5] clk: sunxi-ng: common: Support minimum and maximum rate

M?ns Rullg?rd <[email protected]> writes:

> Frank Oltmanns <[email protected]> writes:
>
>> Hi M?ns,
>>
>> 21.05.2024 15:43:10 M?ns Rullg?rd <[email protected]>:
>>
>>> Frank Oltmanns <[email protected]> writes:
>>>
>>>> The Allwinner SoC's typically have an upper and lower limit for their
>>>> clocks' rates. Up until now, support for that has been implemented
>>>> separately for each clock type.
>>>>
>>>> Implement that functionality in the sunxi-ng's common part making use of
>>>> the CCF rate liming capabilities, so that it is available for all clock
>>>> types.
>>>>
>>>> Suggested-by: Maxime Ripard <[email protected]>
>>>> Signed-off-by: Frank Oltmanns <[email protected]>
>>>> Cc: [email protected]
>>>> ---
>>>> drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++
>>>> drivers/clk/sunxi-ng/ccu_common.h |? 3 +++
>>>> 2 files changed, 22 insertions(+)
>>>
>>> This just landed in 6.6 stable, and it broke HDMI output on an A20 based
>>> device, the clocks ending up all wrong as seen in this diff of
>>> /sys/kernel/debug/clk/clk_summary:

[...]

>>> Reverting this commit makes it work again.
>>
>> Thank you for your detailed report!
>>
>> I've had a first look at hdmi-tmds and hdmi-ddc, and neither seems to
>> be calling ccu_is_better_rate() in their determine_rate()
>> functions. Their parents have the exact same rates in your diff, so,
>> my current working assumption is that they can't be the cause either.
>>
>> I'll have a more detailed look over the weekend. Until then, if anyone
>> has some ideas where I should have a look next, please share your
>> thoughts.
>
> In case it's relevant, this system doesn't use the HDMI DDC, the
> physical DDC pins being connected to a different I2C adapter for
> various reasons.
>
> From the clk_summary diff, I see a few things:
>
> 1. hdmi-tmds has changed parent from pll-video1-2x to pll-video0-2x.
> 2. The ratio of hdmi-tmds to its parent has changed from 1/8 to 1.
> 3. The resulting rate bears no relation to the pixel clock from EDID.
>
> I tried kernel 6.9.1 as well, and that doesn't work either. I'll keep
> digging and try to narrow it down.

It turns out HDMI output is broken in v6.9 for a different reason.
However, this commit (b914ec33b391 clk: sunxi-ng: common: Support
minimum and maximum rate) requires two others as well in order not
to break things on the A20:

cedb7dd193f6 drm/sun4i: hdmi: Convert encoder to atomic
9ca6bc246035 drm/sun4i: hdmi: Move mode_set into enable

With those two (the second depends on the first) cherry-picked on top of
v6.6.31, the HDMI output is working again. Likewise on v6.8.10.

--
M?ns Rullg?rd

2024-06-12 13:28:44

by Thorsten Leemhuis

[permalink] [raw]
Subject: Re: [PATCH v4 1/5] clk: sunxi-ng: common: Support minimum and maximum rate

On 23.05.24 20:58, Måns Rullgård wrote:
> Måns Rullgård <[email protected]> writes:
>> Frank Oltmanns <[email protected]> writes:
>>> 21.05.2024 15:43:10 Måns Rullgård <[email protected]>:
>>>> Frank Oltmanns <[email protected]> writes:
>>>>
>>>>> The Allwinner SoC's typically have an upper and lower limit for their
>>>>> clocks' rates. Up until now, support for that has been implemented
>>>>> separately for each clock type.
>>>>>
>>>>> Implement that functionality in the sunxi-ng's common part making use of
>>>>> the CCF rate liming capabilities, so that it is available for all clock
>>>>> types.
>>>>>
>>>>> Suggested-by: Maxime Ripard <[email protected]>
>>>>> Signed-off-by: Frank Oltmanns <[email protected]>
>>>>> Cc: [email protected]
>>>>> ---
>>>>> drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++
>>>>> drivers/clk/sunxi-ng/ccu_common.h |  3 +++
>>>>> 2 files changed, 22 insertions(+)
>>>>
>>>> This just landed in 6.6 stable, and it broke HDMI output on an A20 based
>>>> device, the clocks ending up all wrong as seen in this diff of
>>>> /sys/kernel/debug/clk/clk_summary:
> [...]
>
>>>> Reverting this commit makes it work again.
>>> Thank you for your detailed report!
> [...]
> It turns out HDMI output is broken in v6.9 for a different reason.
> However, this commit (b914ec33b391 clk: sunxi-ng: common: Support
> minimum and maximum rate) requires two others as well in order not
> to break things on the A20:
>
> cedb7dd193f6 drm/sun4i: hdmi: Convert encoder to atomic
> 9ca6bc246035 drm/sun4i: hdmi: Move mode_set into enable
>
> With those two (the second depends on the first) cherry-picked on top of
> v6.6.31, the HDMI output is working again. Likewise on v6.8.10.

They from what I can see are not yet in 6.6.y or on their way there (6.8
is EOL now). Did anyone ask Greg to pick this up? If not: Månsm could
you maybe do that? CCing him on a reply and asking is likely enough if
both changes apply cleanly.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot introduced: 547263745e15a0
#regzbot fix: drm/sun4i: hdmi: Move mode_set into enable
#regzbot poke

2024-06-12 14:42:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v4 1/5] clk: sunxi-ng: common: Support minimum and maximum rate

On Wed, Jun 12, 2024 at 03:28:01PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 23.05.24 20:58, M?ns Rullg?rd wrote:
> > M?ns Rullg?rd <[email protected]> writes:
> >> Frank Oltmanns <[email protected]> writes:
> >>> 21.05.2024 15:43:10 M?ns Rullg?rd <[email protected]>:
> >>>> Frank Oltmanns <[email protected]> writes:
> >>>>
> >>>>> The Allwinner SoC's typically have an upper and lower limit for their
> >>>>> clocks' rates. Up until now, support for that has been implemented
> >>>>> separately for each clock type.
> >>>>>
> >>>>> Implement that functionality in the sunxi-ng's common part making use of
> >>>>> the CCF rate liming capabilities, so that it is available for all clock
> >>>>> types.
> >>>>>
> >>>>> Suggested-by: Maxime Ripard <[email protected]>
> >>>>> Signed-off-by: Frank Oltmanns <[email protected]>
> >>>>> Cc: [email protected]
> >>>>> ---
> >>>>> drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++
> >>>>> drivers/clk/sunxi-ng/ccu_common.h |? 3 +++
> >>>>> 2 files changed, 22 insertions(+)
> >>>>
> >>>> This just landed in 6.6 stable, and it broke HDMI output on an A20 based
> >>>> device, the clocks ending up all wrong as seen in this diff of
> >>>> /sys/kernel/debug/clk/clk_summary:
> > [...]
> >
> >>>> Reverting this commit makes it work again.
> >>> Thank you for your detailed report!
> > [...]
> > It turns out HDMI output is broken in v6.9 for a different reason.
> > However, this commit (b914ec33b391 clk: sunxi-ng: common: Support
> > minimum and maximum rate) requires two others as well in order not
> > to break things on the A20:
> >
> > cedb7dd193f6 drm/sun4i: hdmi: Convert encoder to atomic
> > 9ca6bc246035 drm/sun4i: hdmi: Move mode_set into enable
> >
> > With those two (the second depends on the first) cherry-picked on top of
> > v6.6.31, the HDMI output is working again. Likewise on v6.8.10.
>
> They from what I can see are not yet in 6.6.y or on their way there (6.8
> is EOL now). Did anyone ask Greg to pick this up? If not: M?nsm could
> you maybe do that? CCing him on a reply and asking is likely enough if
> both changes apply cleanly.

Both now queued up, thanks.

greg k-h

2024-06-14 23:53:28

by Pafford, Robert J.

[permalink] [raw]
Subject: RE: [PATCH v4 1/5] clk: sunxi-ng: common: Support minimum and maximum rate

> The Allwinner SoC's typically have an upper and lower limit for their
> clocks' rates. Up until now, support for that has been implemented
> separately for each clock type.
>
> Implement that functionality in the sunxi-ng's common part making use of
> the CCF rate liming capabilities, so that it is available for all clock
> types.
>
> Suggested-by: Maxime Ripard <[email protected]>
> Signed-off-by: Frank Oltmanns <[email protected]>
> Cc: [email protected]
> ---
> drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++
> drivers/clk/sunxi-ng/ccu_common.h | 3 +++
> 2 files changed, 22 insertions(+)

This patch appears to cause a buffer under-read bug due to the call to 'hw_to_ccu_common', which assumes all entries
in the desc->hw_clocks->hws array are contained in ccu_common structs.

However, not all clocks in the array are contained in ccu_common structs. For example, as part
of the "sun20i-d1-ccu" driver, the "pll-video0" clock holds the 'clk_hw' struct inside of a 'clk_fixed_factor' struct,
as it is a fixed factor clock based on the "pll-video0-4x" clock, created with the CLK_FIXED_FACTOR_HWS macro.
This results in undefined behavior as the hw_to_ccu_common returns an invalid pointer referencing memory before the
'clk_fixed_factor' struct.

I have attached kernel warnings from a system based on the "sun8i-t113s.dtsi" device tree, where the memory contains
a non-zero value for the min-rate but a zero value for the max-rate, triggering the "No max_rate, ignoring min_rate"
warning in the 'sunxi_ccu_probe' function.


[ 0.549013] ------------[ cut here ]------------
[ 0.553727] WARNING: CPU: 0 PID: 1 at drivers/clk/sunxi-ng/ccu_common.c:155 sunxi_ccu_probe+0x105/0x164
[ 0.563153] No max_rate, ignoring min_rate of clock 6 - pll-periph0-div3
[ 0.569846] Modules linked in:
[ 0.572913] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.32-winglet #7
[ 0.579540] Hardware name: Generic DT based system
[ 0.584350] unwind_backtrace from show_stack+0xb/0xc
[ 0.589445] show_stack from dump_stack_lvl+0x2b/0x34
[ 0.594531] dump_stack_lvl from __warn+0x5d/0x92
[ 0.599275] __warn from warn_slowpath_fmt+0xd7/0x12c
[ 0.604354] warn_slowpath_fmt from sunxi_ccu_probe+0x105/0x164
[ 0.610299] sunxi_ccu_probe from devm_sunxi_ccu_probe+0x3d/0x60
[ 0.616317] devm_sunxi_ccu_probe from sun20i_d1_ccu_probe+0xbf/0xec
[ 0.622681] sun20i_d1_ccu_probe from platform_probe+0x3d/0x78
[ 0.628542] platform_probe from really_probe+0x81/0x1d0
[ 0.633862] really_probe from __driver_probe_device+0x59/0x130
[ 0.639813] __driver_probe_device from driver_probe_device+0x2d/0xc8
[ 0.646283] driver_probe_device from __driver_attach+0x4d/0xf0
[ 0.652216] __driver_attach from bus_for_each_dev+0x49/0x84
[ 0.657888] bus_for_each_dev from bus_add_driver+0x91/0x13c
[ 0.663567] bus_add_driver from driver_register+0x37/0xa4
[ 0.669066] driver_register from do_one_initcall+0x41/0x1c4
[ 0.674740] do_one_initcall from kernel_init_freeable+0x13d/0x180
[ 0.680937] kernel_init_freeable from kernel_init+0x15/0xec
[ 0.686607] kernel_init from ret_from_fork+0x11/0x1c
[ 0.691674] Exception stack(0xc8815fb0 to 0xc8815ff8)
[ 0.696739] 5fa0: 00000000 00000000 00000000 00000000
[ 0.704926] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 0.713111] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 0.719765] ---[ end trace 0000000000000000 ]---
[ 0.724452] ------------[ cut here ]------------
[ 0.729082] WARNING: CPU: 0 PID: 1 at drivers/clk/sunxi-ng/ccu_common.c:155 sunxi_ccu_probe+0x105/0x164
[ 0.738518] No max_rate, ignoring min_rate of clock 9 - pll-video0
[ 0.744730] Modules linked in:
[ 0.747801] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.6.32-winglet #7
[ 0.755911] Hardware name: Generic DT based system
[ 0.760696] unwind_backtrace from show_stack+0xb/0xc
[ 0.765768] show_stack from dump_stack_lvl+0x2b/0x34
[ 0.770859] dump_stack_lvl from __warn+0x5d/0x92
[ 0.775600] __warn from warn_slowpath_fmt+0xd7/0x12c
[ 0.780668] warn_slowpath_fmt from sunxi_ccu_probe+0x105/0x164
[ 0.786620] sunxi_ccu_probe from devm_sunxi_ccu_probe+0x3d/0x60
[ 0.792664] devm_sunxi_ccu_probe from sun20i_d1_ccu_probe+0xbf/0xec
[ 0.799035] sun20i_d1_ccu_probe from platform_probe+0x3d/0x78
[ 0.804901] platform_probe from really_probe+0x81/0x1d0
[ 0.810229] really_probe from __driver_probe_device+0x59/0x130
[ 0.816171] __driver_probe_device from driver_probe_device+0x2d/0xc8
[ 0.822624] driver_probe_device from __driver_attach+0x4d/0xf0
[ 0.828566] __driver_attach from bus_for_each_dev+0x49/0x84
[ 0.834237] bus_for_each_dev from bus_add_driver+0x91/0x13c
[ 0.839925] bus_add_driver from driver_register+0x37/0xa4
[ 0.845441] driver_register from do_one_initcall+0x41/0x1c4
[ 0.851123] do_one_initcall from kernel_init_freeable+0x13d/0x180
[ 0.857335] kernel_init_freeable from kernel_init+0x15/0xec
[ 0.863022] kernel_init from ret_from_fork+0x11/0x1c
[ 0.868096] Exception stack(0xc8815fb0 to 0xc8815ff8)
[ 0.873145] 5fa0: 00000000 00000000 00000000 00000000
[ 0.881332] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 0.889525] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 0.896165] ---[ end trace 0000000000000000 ]---
[ 0.900821] ------------[ cut here ]------------
[ 0.905471] WARNING: CPU: 0 PID: 1 at drivers/clk/sunxi-ng/ccu_common.c:155 sunxi_ccu_probe+0x105/0x164
[ 0.914885] No max_rate, ignoring min_rate of clock 12 - pll-video1
[ 0.921143] Modules linked in:
[ 0.924208] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.6.32-winglet #7
[ 0.932308] Hardware name: Generic DT based system
[ 0.937102] unwind_backtrace from show_stack+0xb/0xc
[ 0.942173] show_stack from dump_stack_lvl+0x2b/0x34
[ 0.947254] dump_stack_lvl from __warn+0x5d/0x92
[ 0.952004] __warn from warn_slowpath_fmt+0xd7/0x12c
[ 0.957081] warn_slowpath_fmt from sunxi_ccu_probe+0x105/0x164
[ 0.963034] sunxi_ccu_probe from devm_sunxi_ccu_probe+0x3d/0x60
[ 0.969052] devm_sunxi_ccu_probe from sun20i_d1_ccu_probe+0xbf/0xec
[ 0.975422] sun20i_d1_ccu_probe from platform_probe+0x3d/0x78
[ 0.981288] platform_probe from really_probe+0x81/0x1d0
[ 0.986607] really_probe from __driver_probe_device+0x59/0x130
[ 0.992540] __driver_probe_device from driver_probe_device+0x2d/0xc8
[ 0.999002] driver_probe_device from __driver_attach+0x4d/0xf0
[ 1.004944] __driver_attach from bus_for_each_dev+0x49/0x84
[ 1.010606] bus_for_each_dev from bus_add_driver+0x91/0x13c
[ 1.016286] bus_add_driver from driver_register+0x37/0xa4
[ 1.021785] driver_register from do_one_initcall+0x41/0x1c4
[ 1.027467] do_one_initcall from kernel_init_freeable+0x13d/0x180
[ 1.033679] kernel_init_freeable from kernel_init+0x15/0xec
[ 1.039356] kernel_init from ret_from_fork+0x11/0x1c
[ 1.044440] Exception stack(0xc8815fb0 to 0xc8815ff8)
[ 1.049496] 5fa0: 00000000 00000000 00000000 00000000
[ 1.057674] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1.065850] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 1.072471] ---[ end trace 0000000000000000 ]---
[ 1.077106] ------------[ cut here ]------------
[ 1.081734] WARNING: CPU: 0 PID: 1 at drivers/clk/sunxi-ng/ccu_common.c:155 sunxi_ccu_probe+0x105/0x164
[ 1.091165] No max_rate, ignoring min_rate of clock 16 - pll-audio0
[ 1.097441] Modules linked in:
[ 1.100503] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.6.32-winglet #7
[ 1.108602] Hardware name: Generic DT based system
[ 1.113404] unwind_backtrace from show_stack+0xb/0xc
[ 1.118474] show_stack from dump_stack_lvl+0x2b/0x34
[ 1.123564] dump_stack_lvl from __warn+0x5d/0x92
[ 1.128288] __warn from warn_slowpath_fmt+0xd7/0x12c
[ 1.133356] warn_slowpath_fmt from sunxi_ccu_probe+0x105/0x164
[ 1.139283] sunxi_ccu_probe from devm_sunxi_ccu_probe+0x3d/0x60
[ 1.145318] devm_sunxi_ccu_probe from sun20i_d1_ccu_probe+0xbf/0xec
[ 1.151680] sun20i_d1_ccu_probe from platform_probe+0x3d/0x78
[ 1.157537] platform_probe from really_probe+0x81/0x1d0
[ 1.162857] really_probe from __driver_probe_device+0x59/0x130
[ 1.168816] __driver_probe_device from driver_probe_device+0x2d/0xc8
[ 1.175278] driver_probe_device from __driver_attach+0x4d/0xf0
[ 1.181219] __driver_attach from bus_for_each_dev+0x49/0x84
[ 1.186908] bus_for_each_dev from bus_add_driver+0x91/0x13c
[ 1.192595] bus_add_driver from driver_register+0x37/0xa4
[ 1.198103] driver_register from do_one_initcall+0x41/0x1c4
[ 1.203803] do_one_initcall from kernel_init_freeable+0x13d/0x180
[ 1.210006] kernel_init_freeable from kernel_init+0x15/0xec
[ 1.215684] kernel_init from ret_from_fork+0x11/0x1c
[ 1.220759] Exception stack(0xc8815fb0 to 0xc8815ff8)
[ 1.225806] 5fa0: 00000000 00000000 00000000 00000000
[ 1.233984] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1.242169] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 1.248818] ---[ end trace 0000000000000000 ]---