Hi

On Fri, Feb 10, 2023 at 11:49 PM Stephen Boyd [off-list ref] wrote:

Quoting Michael Nazzareno Trimarchi (2023-01-26 02:49:54)

quoted

Hi

On Wed, Jan 25, 2023 at 10:11 PM Stephen Boyd [off-list ref] wrote:

quoted

Quoting Dario Binacchi (2023-01-01 09:57:29)

quoted

The idea for this series was born back from Dublin (ELCE 2022) after
having attended the talk entitled "Updating and Modernizing Clock
Drivers" held by Chen-Yu Tsai and the availability of a board with
imx8mn SOC.

Interesting. I didn't see any mention of putting clks into DT in that
presentation.

quoted

This series aims to setup all imx8mn's clocks from the device tree and
remove the legacy setup code with hardwired parameters.

Please, no! We don't want one node per clk style of bindings.

I think the idea behind is:
- create a way from silicon vendor to export their clock mapping with
automatic exportation

I suspect silicon vendors automatically generate their clk drivers
today.

Was easy to think that creating tools for dts generation was easy to
have because
they don't depend on the internal linux kernel and they are formally
described. Export
clk drivers considering kernel internal change I don't think that can work.

quoted

- reduce the copy and paste code across the drivers
- avoid code duplication

Code duplication should be avoided. Surely the clk_ops is shared? Data
duplication is the real problem here. The status quo has been to have

The idea to have in dts was to have much less code by the end to handle
different SoC vendors but as you pointed me seems that you are more
concerned about data duplication.

data descriptions of clks in drivers so that drivers can turn them on.
If we're trying to avoid bloat then we only enable the drivers that we
care about, or make them modular so they don't waste kernel memory.

I'm not an expert of the dtc compiler but, is that possible that some
optimization
can happen there in the feature?

If you have ideas on how to avoid duplication there then by all means
implement them. Don't move the data duplication problem to devicetree
though.

We will sit together again ;) after your comments here

I've been wondering if we can tag drivers that are compiled into the
kernel as freeable if they aren't ever going to probe because they're
for some SoC that isn't present. That would allow us to shed various
builtin clk drivers on systems instead of forcing us to make everything
a module.

This is general on the driver level but sounds like a good idea.

Michael

quoted

Is the binding a way to solve this problem?

Don't think so.

quoted

If you don't want one node
per clk style bindings, did you still think that the way
to go is totally wrong?

Yes.

-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel