[v4,1/5] clk: sunxi-ng: common: Support minimum and maximum rate

Commit Message

Frank Oltmanns March 10, 2024, 1:21 p.m. UTC

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 <[e-mail]>
Signed-off-by: Frank Oltmanns <[e-mail]>
Cc: [e-mail]
---
 drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++
 drivers/clk/sunxi-ng/ccu_common.h |  3 +++
 2 files changed, 22 insertions(+)

Comments

Jernej Škrabec March 13, 2024, 6:17 p.m. UTC | #1

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 <[e-mail]>
> Signed-off-by: Frank Oltmanns <[e-mail]>
> Cc: [e-mail]

This looks pretty nice now.

Reviewed-by: Jernej Skrabec <[e-mail]>

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;
> 
>

Maxime Ripard March 15, 2024, 1:04 p.m. UTC | #2

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 <[e-mail]>

Thanks!
Maxime

Måns Rullgård May 21, 2024, 1:35 p.m. UTC | #3

Frank Oltmanns <[e-mail]> 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 <[e-mail]>
> Signed-off-by: Frank Oltmanns <[e-mail]>
> Cc: [e-mail]
> ---
>  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
>

Frank Oltmanns May 22, 2024, 6:33 a.m. UTC | #4

Hi Måns,

21.05.2024 15:43:10 Måns Rullgård <[e-mail]>:

> Frank Oltmanns <[e-mail]> 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 <[e-mail]>
>> Signed-off-by: Frank Oltmanns <[e-mail]>
>> Cc: [e-mail]
>> ---
>> 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

Måns Rullgård May 22, 2024, 6:07 p.m. UTC | #5

Frank Oltmanns <[e-mail]> writes:

> Hi Måns,
>
> 21.05.2024 15:43:10 Måns Rullgård <[e-mail]>:
>
>> Frank Oltmanns <[e-mail]> 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 <[e-mail]>
>>> Signed-off-by: Frank Oltmanns <[e-mail]>
>>> Cc: [e-mail]
>>> ---
>>> 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 May 23, 2024, 6:58 p.m. UTC | #6

Måns Rullgård <[e-mail]> writes:

> Frank Oltmanns <[e-mail]> writes:
>
>> Hi Måns,
>>
>> 21.05.2024 15:43:10 Måns Rullgård <[e-mail]>:
>>
>>> Frank Oltmanns <[e-mail]> 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 <[e-mail]>
>>>> Signed-off-by: Frank Oltmanns <[e-mail]>
>>>> Cc: [e-mail]
>>>> ---
>>>> 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.

Thorsten Leemhuis June 12, 2024, 1:28 p.m. UTC | #7

On 23.05.24 20:58, Måns Rullgård wrote:
> Måns Rullgård <[e-mail]> writes:
>> Frank Oltmanns <[e-mail]> writes:
>>> 21.05.2024 15:43:10 Måns Rullgård <[e-mail]>:
>>>> Frank Oltmanns <[e-mail]> 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 <[e-mail]>
>>>>> Signed-off-by: Frank Oltmanns <[e-mail]>
>>>>> Cc: [e-mail]
>>>>> ---
>>>>> 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

Greg KH June 12, 2024, 2:42 p.m. UTC | #8

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 <[e-mail]> writes:
> >> Frank Oltmanns <[e-mail]> writes:
> >>> 21.05.2024 15:43:10 Måns Rullgård <[e-mail]>:
> >>>> Frank Oltmanns <[e-mail]> 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 <[e-mail]>
> >>>>> Signed-off-by: Frank Oltmanns <[e-mail]>
> >>>>> Cc: [e-mail]
> >>>>> ---
> >>>>> 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

Frank Oltmanns June 20, 2024, 3:27 p.m. UTC | #9

Hi Robert,

I'm truly sorry for the trouble the patch has caused you and for my late
reply!

On 2024-06-14 at 23:52:08 +0000, "Pafford, Robert J." <[e-mail]> 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
>> the CCF rate liming capabilities, so that it is available for all clock
>> types.
>>
>> Suggested-by: Maxime Ripard <[e-mail]>
>> Signed-off-by: Frank Oltmanns <[e-mail]>
>> Cc: [e-mail]
>> ---
>>  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.
>

Great catch! At first glance, it seems to me that calling
clk_hw_set_rate_range() in sunxi_ccu_probe() should not have happenend
in the loop that iterates over the hw_clks.

Instead we should add one more loop that iterates over the ccu_clks.
Note, that there is already one such loop but, unfortunately, we can't
use that as it happens before the hw_clks loop and we can only call
clk_hw_set_rate_range() after the hw_clk has been registered.

Hence, I propose to move the offending code to a new loop:
	for (i = 0; i < desc->num_ccu_clks; i++) {
		struct ccu_common *cclk = desc->ccu_clks[i];

		if (!cclk)
			continue;

		if (cclk->max_rate)
			clk_hw_set_rate_range(&cclk->hw, common->min_rate,
					      common->max_rate);
		else
			WARN(cclk->min_rate,
			     "No max_rate, ignoring min_rate of clock %d - %s\n",
			     i, cclk->hw.init->name);
	}

I haven't tested (or even compiled) the above, but I'll test and send a
patch within the next few days for you to test.

Thanks again,
  Frank

>
> 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 ]---

Pafford, Robert J. June 26, 2024, 4:02 p.m. UTC | #10

Hi Frank,

Moving to a new for loop makes sense. Let me know when you have a patch
and I'll be glad to test it on my board. I do also wonder if this may
have contributed to some of the HDMI issues seen in the other thread.

Best,
Robert

> Hi Robert,
>
> I'm truly sorry for the trouble the patch has caused you and for my late
> reply!
>
> On 2024-06-14 at 23:52:08 +0000, "Pafford, Robert J." <[e-mail]> 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
>>> the CCF rate liming capabilities, so that it is available for all clock
>>> types.
>>>
>>> Suggested-by: Maxime Ripard <[e-mail]>
>>> Signed-off-by: Frank Oltmanns <[e-mail]>
>>> Cc: [e-mail]
>>> ---
>>>  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.
>>
>
> Great catch! At first glance, it seems to me that calling
> clk_hw_set_rate_range() in sunxi_ccu_probe() should not have happenend
> in the loop that iterates over the hw_clks.
> 
> Instead we should add one more loop that iterates over the ccu_clks.
> Note, that there is already one such loop but, unfortunately, we can't
> use that as it happens before the hw_clks loop and we can only call
> clk_hw_set_rate_range() after the hw_clk has been registered.
> 
> Hence, I propose to move the offending code to a new loop:
>         for (i = 0; i < desc->num_ccu_clks; i++) {
>                 struct ccu_common *cclk = desc->ccu_clks[i];
> 
>                 if (!cclk)
>                         continue;
> 
>                 if (cclk->max_rate)
>                         clk_hw_set_rate_range(&cclk->hw, common->min_rate,
>                                               common->max_rate);
>                 else
>                         WARN(cclk->min_rate,
>                              "No max_rate, ignoring min_rate of clock %d - %s\n",
>                              i, cclk->hw.init->name);
>         }
> 
> I haven't tested (or even compiled) the above, but I'll test and send a
> patch within the next few days for you to test.
> 
> Thanks again,
>   Frank
> 
>>
>> 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.
>>
>> [...]

Frank Oltmanns June 26, 2024, 5:07 p.m. UTC | #11

Hi Robert,

26.06.2024 18:03:24 Pafford, Robert J. <[e-mail]>:

> Hi Frank,
>
> Moving to a new for loop makes sense. Let me know when you have a patch

The patch is here, strange you didn't receive it:
https://lore.kernel.org/all/[e-mail]/


> and I'll be glad to test it on my board. I do also wonder if this may
> have contributed to some of the HDMI issues seen in the other thread.

My thought's exactly!

Best regards,
  Frank

>
> Best,
> Robert
>
>> Hi Robert,
>>
>> I'm truly sorry for the trouble the patch has caused you and for my late
>> reply!
>>
>> On 2024-06-14 at 23:52:08 +0000, "Pafford, Robert J." <[e-mail]> 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
>>>> the CCF rate liming capabilities, so that it is available for all clock
>>>> types.
>>>>
>>>> Suggested-by: Maxime Ripard <[e-mail]>
>>>> Signed-off-by: Frank Oltmanns <[e-mail]>
>>>> Cc: [e-mail]
>>>> ---
>>>>   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.
>>>
>>
>> Great catch! At first glance, it seems to me that calling
>> clk_hw_set_rate_range() in sunxi_ccu_probe() should not have happenend
>> in the loop that iterates over the hw_clks.
>>
>> Instead we should add one more loop that iterates over the ccu_clks.
>> Note, that there is already one such loop but, unfortunately, we can't
>> use that as it happens before the hw_clks loop and we can only call
>> clk_hw_set_rate_range() after the hw_clk has been registered.
>>
>> Hence, I propose to move the offending code to a new loop:
>>         for (i = 0; i < desc->num_ccu_clks; i++) {
>>                 struct ccu_common *cclk = desc->ccu_clks[i];
>>
>>                 if (!cclk)
>>                         continue;
>>
>>                 if (cclk->max_rate)
>>                         clk_hw_set_rate_range(&cclk->hw, common->min_rate,
>>                                               common->max_rate);
>>                 else
>>                         WARN(cclk->min_rate,
>>                              "No max_rate, ignoring min_rate of clock %d - %s\n",
>>                              i, cclk->hw.init->name);
>>         }
>>
>> I haven't tested (or even compiled) the above, but I'll test and send a
>> patch within the next few days for you to test.
>>
>> Thanks again,
>>   Frank
>>
>>>
>>> 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.
>>>
>>> [...]

Pafford, Robert J. June 27, 2024, 1:22 a.m. UTC | #12

Frank Oltmanns <[e-mail]> writes:

> Hi Robert,
>
> 26.06.2024 18:03:24 Pafford, Robert J. <[e-mail]>:
>
>> Hi Frank,
>>
>> Moving to a new for loop makes sense. Let me know when you have a patch
>
> The patch is here, strange you didn't receive it:
> https://lore.kernel.org/all/[e-mail]/

Ah, this must have slipped through my inbox. I just applied it on my board and it is
now cooperating with the min/max clock rates!

>
>> and I'll be glad to test it on my board. I do also wonder if this may
>> have contributed to some of the HDMI issues seen in the other thread.
>
> My thought's exactly!
>
> Best regards,
>   Frank
>
>>
>> Best,
>> Robert
>>
>>> Hi Robert,
>>>
>>> I'm truly sorry for the trouble the patch has caused you and for my late
>>> reply!
>>>
>>> On 2024-06-14 at 23:52:08 +0000, "Pafford, Robert J." <[e-mail]> 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
>>>>> the CCF rate liming capabilities, so that it is available for all clock
>>>>> types.
>>>>>
>>>>> Suggested-by: Maxime Ripard <[e-mail]>
>>>>> Signed-off-by: Frank Oltmanns <[e-mail]>
>>>>> Cc: [e-mail]
>>>>> ---
>>>>>   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.
>>>>
>>>
>>> Great catch! At first glance, it seems to me that calling
>>> clk_hw_set_rate_range() in sunxi_ccu_probe() should not have happenend
>>> in the loop that iterates over the hw_clks.
>>>
>>> Instead we should add one more loop that iterates over the ccu_clks.
>>> Note, that there is already one such loop but, unfortunately, we can't
>>> use that as it happens before the hw_clks loop and we can only call
>>> clk_hw_set_rate_range() after the hw_clk has been registered.
>>>
>>> Hence, I propose to move the offending code to a new loop:
>>>         for (i = 0; i < desc->num_ccu_clks; i++) {
>>>                 struct ccu_common *cclk = desc->ccu_clks[i];
>>>
>>>                 if (!cclk)
>>>                         continue;
>>>
>>>                 if (cclk->max_rate)
>>>                         clk_hw_set_rate_range(&cclk->hw, common->min_rate,
>>>                                               common->max_rate);
>>>                 else
>>>                         WARN(cclk->min_rate,
>>>                              "No max_rate, ignoring min_rate of clock %d - %s\n",
>>>                              i, cclk->hw.init->name);
>>>         }
>>>
>>> I haven't tested (or even compiled) the above, but I'll test and send a
>>> patch within the next few days for you to test.
>>>
>>> Thanks again,
>>>   Frank
>>>
>>>>
>>>> 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.
>>>>
>>>> [...]

Thanks,
Robert

Chen-Yu Tsai June 27, 2024, 4:46 a.m. UTC | #13

On Thu, Jun 27, 2024 at 9:23 AM Pafford, Robert J.
<[e-mail]> wrote:
>
> Frank Oltmanns <[e-mail]> writes:
>
> > Hi Robert,
> >
> > 26.06.2024 18:03:24 Pafford, Robert J. <[e-mail]>:
> >
> >> Hi Frank,
> >>
> >> Moving to a new for loop makes sense. Let me know when you have a patch
> >
> > The patch is here, strange you didn't receive it:
> > https://lore.kernel.org/all/[e-mail]/
>
> Ah, this must have slipped through my inbox. I just applied it on my board and it is
> now cooperating with the min/max clock rates!

Please reply to the thread and give a Tested-by.

ChenYu

> >
> >> and I'll be glad to test it on my board. I do also wonder if this may
> >> have contributed to some of the HDMI issues seen in the other thread.
> >
> > My thought's exactly!
> >
> > Best regards,
> >   Frank
> >
> >>
> >> Best,
> >> Robert
> >>
> >>> Hi Robert,
> >>>
> >>> I'm truly sorry for the trouble the patch has caused you and for my late
> >>> reply!
> >>>
> >>> On 2024-06-14 at 23:52:08 +0000, "Pafford, Robert J." <[e-mail]> 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
> >>>>> the CCF rate liming capabilities, so that it is available for all clock
> >>>>> types.
> >>>>>
> >>>>> Suggested-by: Maxime Ripard <[e-mail]>
> >>>>> Signed-off-by: Frank Oltmanns <[e-mail]>
> >>>>> Cc: [e-mail]
> >>>>> ---
> >>>>>   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.
> >>>>
> >>>
> >>> Great catch! At first glance, it seems to me that calling
> >>> clk_hw_set_rate_range() in sunxi_ccu_probe() should not have happenend
> >>> in the loop that iterates over the hw_clks.
> >>>
> >>> Instead we should add one more loop that iterates over the ccu_clks.
> >>> Note, that there is already one such loop but, unfortunately, we can't
> >>> use that as it happens before the hw_clks loop and we can only call
> >>> clk_hw_set_rate_range() after the hw_clk has been registered.
> >>>
> >>> Hence, I propose to move the offending code to a new loop:
> >>>         for (i = 0; i < desc->num_ccu_clks; i++) {
> >>>                 struct ccu_common *cclk = desc->ccu_clks[i];
> >>>
> >>>                 if (!cclk)
> >>>                         continue;
> >>>
> >>>                 if (cclk->max_rate)
> >>>                         clk_hw_set_rate_range(&cclk->hw, common->min_rate,
> >>>                                               common->max_rate);
> >>>                 else
> >>>                         WARN(cclk->min_rate,
> >>>                              "No max_rate, ignoring min_rate of clock %d - %s\n",
> >>>                              i, cclk->hw.init->name);
> >>>         }
> >>>
> >>> I haven't tested (or even compiled) the above, but I'll test and send a
> >>> patch within the next few days for you to test.
> >>>
> >>> Thanks again,
> >>>   Frank
> >>>
> >>>>
> >>>> 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.
> >>>>
> >>>> [...]
>
> Thanks,
> Robert

Patch

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;