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

[Brian Masney]

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.

Thanks,

Brian