Messages in this thread | | | Date | Tue, 17 May 2022 10:59:30 +0200 | Subject | Re: [PATCH 5/5] clk: mediatek: Add MediaTek Helio X10 MT6795 clock drivers | From | AngeloGioacchino Del Regno <> |
| |
Il 17/05/22 10:48, Matthias Brugger ha scritto: > Hi Angelo, > > On 17/05/2022 10:07, AngeloGioacchino Del Regno wrote: >> Il 16/05/22 13:30, Matthias Brugger ha scritto: >>> >>> >>> On 13/05/2022 18:50, AngeloGioacchino Del Regno wrote: >>>> 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 >>>> <angelogioacchino.delregno@collabora.com> >>> >>> 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") > >
My clock drivers should already be able to be compiled as module, but I admit I haven't even tried... I'll check that commit out just to make sure that everything ticks right, thanks!
> 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). >
No we're not targeting this, but if we have *no reason* to not be compatible with GKI, we can satisfy that criteria, hence we have to. Anyway - I didn't know that having clocks as modules was enforced by GKI... thanks for the information!
>> 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 >
Hahaha! Everyone can do that by trying hard enough! You can, too! :-)
>> 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? >
Definitely - sounds good. You'll get a v2 ASAP, then!
Cheers, Angelo
| |