Message-ID: <7a3c9205-8fb8-440c-bebe-090f1c49689e@amlogic.com>
Date: Tue, 4 Nov 2025 13:28:13 +0800
From: Chuan Liu <chuan.liu@...ogic.com>
To: Jerome Brunet <jbrunet@...libre.com>
Cc: Chuan Liu via B4 Relay <devnull+chuan.liu.amlogic.com@...nel.org>,
 Neil Armstrong <neil.armstrong@...aro.org>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Kevin Hilman <khilman@...libre.com>,
 Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
 linux-amlogic@...ts.infradead.org, linux-clk@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/4] clk: amlogic: optimize the PLL driver



On 11/1/2025 12:27 AM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
> 
> On Fri 31 Oct 2025 at 23:09, Chuan Liu <chuan.liu@...ogic.com> wrote:
> 
>> Hi Jerome,
>>
>> On 10/31/2025 5:04 PM, Jerome Brunet wrote:
>>> [ EXTERNAL EMAIL ]
>>> On Fri 31 Oct 2025 at 16:10, Chuan Liu via B4 Relay
>>> <devnull+chuan.liu.amlogic.com@...nel.org> wrote:
>>>
>>>> This patch series consists of four topics involving the amlogic PLL
>>>> driver:
>>>> - Fix out-of-range PLL frequency setting.
>>>> - Improve the issue of PLL lock failures.
>>>> - Add handling for PLL lock failure.
>>>> - Optimize PLL enable timing.
>>>>
>>>> For easier review and management, these are submitted as a single
>>>> patch series.
>>>>
>>>> The PLL timing optimization changes were merged into our internal
>>>> repository quite some time ago and have been verified on a large
>>>> number of SoCs:
>>>> - Already supported upstream: G12A, G12B, SM1, S4, A1, C3.
>>>> - Planned for upstream support: T7, A5, A4, S7, S7D, S6, etc.
>>>>
>>>> Based on the upstream code base, I have performed functional testing
>>>> on G12A, A1, A5, A4, T7, S7, S7D, and S6, all of which passed.
>>>>
>>>> Additionally, stress testing using scripts was conducted on A5 and
>>>> A1, with over 40,000 and 50,000 iterations respectively, and no
>>>> abnormalities were observed. Below is a portion of the stress test
>>>> log (CLOCK_ALLOW_WRITE_DEBUGFS has been manually enabled):
>>> Okay, this little game has been going on long enough.
>>> You've posted v2 24h hours ago
>>> You've got feedback within hours
>>> There was still a 1 question pending
>>> The rest of community had no chance to review.
>>>
>>
>> There might be a serious misunderstanding here.
>>
>> In recent years, we've mainly been maintaining our code in our
>> internal repository, which has led to some differences between our
>> internal codebase and the upstream version. The patches that account
>> for these differences are already queued for submission, and several
>> SoCs are also waiting in line to be submitted. As a result, quite a
>> few patches have piled up, waiting to go upstream.
>>
>> Previously, I had been waiting for your clock driver restructuring
>> patches to be ready (which have recently been merged), so for almost
>> a year, we haven't made much progress on clock driver–related
>> upstreaming.
> 
> Ohoh now you are just teasing me !

I must clarify that there seems to have been a misunderstanding. We
are increasingly focusing on the development of upstream ecosystem
and actively working to make it more comprehensive.

> 
> That work was made necessary because of all the copy/paste Amlogic was
> submitting. Despite many requests, this was never addressed so I had
> to step in.

I fully understand your perspective, especially given the challenging
process of upstreaming our clock driver due to historical reasons. I
have always maintained a friendly attitude and kept communication
open with you. My intention here is solely to provide context and
avoid any further misunderstandings.

First, I acknowledge your approach: these optimizations are
beneficial.

Over the years, we have also recognized these issues and have
implemented a series of improvements in our internal repository, such
as:
   - Reducing driver code volume and improving reusability,
   - Standardizing naming conventions (e.g., clock names, clock IDs)
   - Optimizing image size
   - Enhancing driver execution efficiency
   - Ensuring compatibility between ARM and ARM64 architectures

To address the challenges encountered, we have also contributed to
optimizing SoC hardware design. Improvements have already been
observed in newer SoCs, and we plan to gradually submit the related
drivers to the community in the future.

> 
> If you want things to go faster, then *really* pay attention to the review
> you are getting, do not ask question to ignore the answers and stop
> making people repeat themselves over and over.
> 

Thank you and the other reviewers for taking the time to review my
patch.

There may have been instances where I misunderstood your comments,
but I never intentionally ignored your feedback. Moving forward, I
will actively submit our company's drivers to the upstream, and I
certainly hope not to be perceived as uncooperative from the start.

Powered by blists - more mailing lists