Re: [PATCH 0/8] Support dynamic EMC frequency scaling on Tegra186/Tegra194

[Aaron Kling]

On Thu, Sep 4, 2025 at 3:19 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On 03/09/2025 08:37, Aaron Kling wrote:
> > On Wed, Sep 3, 2025 at 1:20 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> >>
> >> On 02/09/2025 18:51, Aaron Kling wrote:
> >>> On Tue, Sep 2, 2025 at 3:23 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> >>>>
> >>>> On Sun, Aug 31, 2025 at 10:33:48PM -0500, Aaron Kling wrote:
> >>>>> This series borrows the concept used on Tegra234 to scale EMC based on
> >>>>> CPU frequency and applies it to Tegra186 and Tegra194. Except that the
> >>>>> bpmp on those archs does not support bandwidth manager, so the scaling
> >>>>> iteself is handled similar to how Tegra124 currently works.
> >>>>>
> >>>>
> >>>> Three different subsystems and no single explanation of dependencies and
> >>>> how this can be merged.
> >>>
> >>> The only cross-subsystem hard dependency is that patches 5 and 6 need
> >>> patches 1 and 2 respectively. Patch 5 logically needs patch 3 to
> >>> operate as expected, but there should not be compile compile or probe
> >>> failures if those are out of order. How would you expect this to be
> >>> presented in a cover letter?
> >>
> >> Also, placing cpufreq patch between two memory controller patches means
> >> you really make it more difficult to apply it for the maintainers.
> >> Really, think thoroughly how this patchset is supposed to be read.
> >
> > This is making me more confused. My understanding was that a series
> > like this that has binding, driver, and dt changes would flow like
> > that: all bindings first, all driver changes in the middle, and all dt
>
> You mix completely independent subsystems, that's the main problem.
> Don't send v3 before you understand it or we finish the discussion here.
>
> > changes last. Are you suggesting that this should be: cpufreq driver
> > -> bindings -> memory drivers -> dt? Are the bindings supposed to be
> > pulled with the driver changes? I had understood those to be managed
> > separately.
> What does the submitting patches doc in DT say?

The only relevant snippet I see is:
"The Documentation/ portion of the patch should come in the series
before the code implementing the binding."

I had got it in my head that all bindings should go first as a
separate subsystem, not just docs. I will double check all series
before sending new revisions.

Aaron