On 11/1/2025 12:27 AM, Jerome Brunet wrote:

[ EXTERNAL EMAIL ]

On Fri 31 Oct 2025 at 23:09, Chuan Liu [off-list ref] wrote:

quoted

Hi Jerome,

On 10/31/2025 5:04 PM, Jerome Brunet wrote:

quoted

[ EXTERNAL EMAIL ]
On Fri 31 Oct 2025 at 16:10, Chuan Liu via B4 Relay
[off-list ref] wrote:

quoted

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.