Hi Angelo,

On 17/05/2022 10:07, AngeloGioacchino Del Regno wrote:

Il 16/05/22 13:30, Matthias Brugger ha scritto:

quoted

On 13/05/2022 18:50, AngeloGioacchino Del Regno wrote:

quoted

Add the clock drivers for the entire clock tree of MediaTek Helio X10
MT6795, including system clocks (apmixedsys, infracfg, pericfg, topckgen)
and multimedia clocks (mmsys, mfg, vdecsys, vencsys).

Signed-off-by: AngeloGioacchino Del Regno 
[off-list ref]

Thanks a lot for taking care of this!
I just wonder if we couldn't build most of the clock drivers as modules like 
done for the mt6779. It would help us to keep the kernel image smaller.

Hello Matthias!

You're welcome!
...but I simply couldn't stand at seeing partially working (..or actually, not
really working) SoCs upstream. If something is upstream, it must work, or it
shouldn't be here for real :-)

Regarding your question about the clock drivers as module... I believe we can,
but that'd be only for {vdec,venc}sys and *maybe* MFG (gpu clocks): I don't know
if it'd be worth to do, as these are about... 8 clocks out of... I haven't counted
them, but more than 250, I think?

It *should* be straightforward though, just about giving them a tristate in Kconfig
instead of a bool, but that would still be limited to just those three...

I think you could guide yourself by looking at
f09b9460a5e4 ("clk: mediatek: support COMMON_CLK_MT6779 module build")


I think having clocks as modules is a criteria to be part of Android's Generic 
Kernel Image. Not that we target this here, just for your information (in case 
you didn't know).

The reason for me excluding clk-mt6795-mm from this choice is that - at least for
me - my development platform is a commercial smartphone, where the only thing that
"saves you" is having some display output... I mean - I *do* have a UART port, but
that's only because I've been able to solder thin wires on 0.2mm pads... you surely
agree on the fact that this isn't a common practice, even across developers.

Yes I was wondering if you got some development smartphone or you did the 
soldering. I have some solder knowledge but I think not enough to solder 
something like this :D

Besides, if you think that clk-mt6795-mm should indeed be a module by default,
well, that.. is.. possible - I don't see why it shouldn't be... obviously keeping
in mind that this will largely slow down the boot process, which isn't a big issue.

Well I don't want to bother you with minor details, most important thing is that 
we get support upstream... but ;) you can always mark the modules as compiled 
in, even if it's tristate, which in your case you want to do.

In any case, it is *not* possible to compile as module *any* of the clock drivers
that I have included in the CONFIG_COMMON_CLK_MT6795 (apmixed, infra, peri, topck)
as.. you know.. these are "a bit critical" on older platforms :-)


How would you proceed?

I'd make all the drivers that theoretically can be build as modules tristate, 
you can then define for your development environment to make them build-in.

Sounds good?

Regards,
Matthias

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