mbox series

[v3,0/7] Cleanup Tegra210 EMC frequency scaling

Message ID 20240429101933.11500-1-diogo.ivo@tecnico.ulisboa.pt
Headers show
Series Cleanup Tegra210 EMC frequency scaling | expand

Message

Diogo Ivo April 29, 2024, 10:19 a.m. UTC 
Hello,

This patch series consists of a general cleanup of the Tegra210 EMC
frequency scaling code for revision 7.

Currently the code is relying heavily on a function, update_clock_tree_delay(),
that is responsible for too many things, making it long and confusing.
The general idea with these patches is to simplify this function and its
surrounding code, making it more modular.

The motivation behind these changes (besides improving readability and
maintainability) is to make it simpler to add support in the future for
frequency change revisions other than 7, where we can reuse a large
portion of the modularized code rather than essentially repeating 2k
lines of code with minimal changes.

There are no functional changes with this patch set, as it is only meant
as preparation for following patches where revision 6 support is added.

The second version of the series can be found in [1]. v3 contains
changes only in patch 02/07 where a variable is renamed in order to fix
a build error on some architectures.

[1]: https://lore.kernel.org/linux-tegra/20240419104516.308975-1-diogo.ivo@tecnico.ulisboa.pt/

Diogo Ivo (7):
  memory: tegra: Remove periodic compensation duplicate calls
  memory: tegra: Move DQSOSC measurement to common place
  memory: tegra: Reword and correct comments
  memory: tegra: Change macros to interpret parameter as integer
  memory: tegra: Loop update_clock_tree_delay()
  memory: tegra: Move compare/update current delay values to a function
  memory: tegra: Rework update_clock_tree_delay()

 drivers/memory/tegra/tegra210-emc-cc-r21021.c | 427 ++++--------------
 1 file changed, 84 insertions(+), 343 deletions(-)

Comments

Krzysztof Kozlowski May 4, 2024, 12:20 p.m. UTC | #1 
On 29/04/2024 12:19, Diogo Ivo wrote:
> Hello,
> 
> This patch series consists of a general cleanup of the Tegra210 EMC
> frequency scaling code for revision 7.
> 
> Currently the code is relying heavily on a function, update_clock_tree_delay(),
> that is responsible for too many things, making it long and confusing.
> The general idea with these patches is to simplify this function and its
> surrounding code, making it more modular.
> 
> The motivation behind these changes (besides improving readability and
> maintainability) is to make it simpler to add support in the future for
> frequency change revisions other than 7, where we can reuse a large
> portion of the modularized code rather than essentially repeating 2k
> lines of code with minimal changes.
> 
> There are no functional changes with this patch set, as it is only meant
> as preparation for following patches where revision 6 support is added.
> 
> The second version of the series can be found in [1]. v3 contains
> changes only in patch 02/07 where a variable is renamed in order to fix
> a build error on some architectures.
> 
> [1]: https://lore.kernel.org/linux-tegra/20240419104516.308975-1-diogo.ivo@tecnico.ulisboa.pt/
> 
> Diogo Ivo (7):
>   memory: tegra: Remove periodic compensation duplicate calls
>   memory: tegra: Move DQSOSC measurement to common place

Thanks for the updates. I was hoping for some reviews and tests before I
try to apply the next version, thus I want to give it few more days.
This also means this won't fit to coming merge window. I plan to apply
the set after the v6.10 merge window.

Best regards,
Krzysztof
Krzysztof Kozlowski May 6, 2024, 8:07 a.m. UTC | #2 
On 29/04/2024 12:19, Diogo Ivo wrote:
> Hello,
> 
> This patch series consists of a general cleanup of the Tegra210 EMC
> frequency scaling code for revision 7.
> 
> Currently the code is relying heavily on a function, update_clock_tree_delay(),
> that is responsible for too many things, making it long and confusing.
> The general idea with these patches is to simplify this function and its
> surrounding code, making it more modular.

One more thing:
Your v2 was not build tested by you, was missed by LKP and you did not
Cc kernel mailing list. Maybe LKP missed it because you reduced the
recipients list, which is surprising. I do not see any reason why
removing output of get_maintainers for this patch.

Therefore anyway please resend including ALL mailing lists and ALL
maintainers, so I can have some confidence that LKP picked this up.

Best regards,
Krzysztof