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

[Brian Masney <bmasney@redhat.com>]

Hi Konrad,

On Tue, Jun 30, 2026 at 04:37:12PM +0200, Konrad Dybcio wrote:
> On 3/23/26 5:07 PM, Brian Masney wrote:
> > On Mon, Mar 23, 2026 at 8:48 AM Konrad Dybcio
> > <konrad.dybcio@oss.qualcomm.com> 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@gmail.com> wrote:
> >>>>> On Wed, Mar 4, 2026 at 10:50 PM Brian Masney <bmasney@redhat.com> 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@oss.qualcomm.com/
> > 
> > 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

The latest version of my clk scaling is v8 from March.
https://lore.kernel.org/linux-clk/20260327-clk-scaling-v8-0-86cd0aba3c5f@redhat.com/

It's honestly stuck in limbo right now. It fixes a real issue that you
can see from the kunit tests, and I'm happy with how simple it is now.
The series is kind of stuck though. It would be very helpful if you
could talk to some folks within QC that work on the clk drivers to see
if they would be willing to help test since it's making systems run
suboptimal. Crashes can occur on some devices when you switch between
different types of displays based on older reports.

I submitted a talk to Linux Plumbers for the Power Management / Thermal
MC to talk about this, and current state of sync_state support in clk.

Brian