Re: [PATCH] clk: qcom: dispcc-sc8280xp: remove CLK_SET_RATE_PARENT from byte_div_clk_src dividers

[Konrad Dybcio]

On 3/23/26 5:07 PM, Brian Masney wrote:
> Hi Konrad,
> 
> On Mon, Mar 23, 2026 at 8:48 AM Konrad Dybcio
> <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>> On 3/13/26 5:54 PM, Brian Masney wrote:
>>> On Fri, Mar 06, 2026 at 06:27:20PM -0500, Brian Masney wrote:
>>>> On Wed, Mar 4, 2026 at 10:08 AM Pengyu Luo <mitltlatltl@xxxxxxxxx> wrote:
>>>>> On Wed, Mar 4, 2026 at 10:50 PM Brian Masney <bmasney@xxxxxxxxxx> wrote:
>>>>>> On Tue, Mar 03, 2026 at 01:10:43PM +0100, Konrad Dybcio wrote:
>>>>>>> On 3/3/26 12:55 PM, Pengyu Luo wrote:
>>
>> [...]
>>
>>> Ignore my previous patch set. In my v6 that I just posted, I updated
>>> clk-divider.c to support the new v2 clk negotiation logic. The
>>> clk_regmap_div_ops uses this driver, so you shouldn't have to make any
>>> code changes.
>>>
>>> Anyways, would someone from Qualcomm be willing to test this? The
>>> procedure is fairly simple:
>>
>> Unfortunately, I don't think it's easy to get your hands on a 8280
>> device with DSI.. maybe Pengyu could test that on his tablet/laptop.
> 
> It doesn't have to be an 8280 SoC. It could be any device that has the
> issue where the parent rate change screws up that portion of the clock
> tree, and crashes the device. This has been a long-standing issue in
> the clk framework.  I know you recently posted a series for 5 other
> SoCs with a similar change [1], so any of those other devices should
> work as well.
> 
> [1] https://lore.kernel.org/linux-arm-msm/20260304-topic-dsi_byte_fixup-v1-0-b79b29f83176@xxxxxxxxxxxxxxxx/
> 
> The kunit tests in my clk scaling patch set demonstrate the issues
> that I have worked on. For example, in my test scenario, I start with
> a parent, and two children. The parent can do any rate. The two
> children are simple dividers. This is the current behavior today:
> 
>         KUNIT_ASSERT_EQ(test, clk_get_rate(ctx->parent_clk), 24 * HZ_PER_MHZ);
>         KUNIT_ASSERT_EQ(test, clk_get_rate(ctx->child1_clk), 24 * HZ_PER_MHZ);
>         KUNIT_ASSERT_EQ(test, clk_get_rate(ctx->child2_clk), 24 * HZ_PER_MHZ);
> 
>         ret = clk_set_rate(ctx->child1_clk, 32 * HZ_PER_MHZ);
> 
>         /*
>          * The last sibling rate change is the one that was successful, and
>          * wins. The parent, and two children are all changed to 32 MHz.
>          */
>         KUNIT_EXPECT_EQ(test, clk_get_rate(ctx->parent_clk), 32 * HZ_PER_MHZ);
>         KUNIT_EXPECT_EQ(test, clk_get_rate(ctx->child1_clk), 32 * HZ_PER_MHZ);
>         KUNIT_EXPECT_EQ(test, clk_get_rate(ctx->child2_clk), 32 * HZ_PER_MHZ);
> 
> With my changes, the clk framework will land on 96 MHz for the parent,
> and 24 MHz and 32 MHz for the two children.
> 
> Anyways, it would be great if someone from Qualcomm would be willing
> to help me test my changes on real hardware. If it requires code
> changes to a specific clk provider, then I'm willing to also do that
> work if someone can test for me. Getting confirmation that this is
> fixed on real hardware will help to land my series that will provide a
> solution to this problem that has existing in the clk framework since
> it was introduced over 12 years ago.

Was going through my inbox - do you still need the testing? I see that
the last revision of the series (v6) is from march

Do I need anything other than just the series itself?

Konrad