lkml.org 
[lkml]   [2022]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 5/5] clk: mediatek: Add MediaTek Helio X10 MT6795 clock drivers
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")


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

\
 
 \ /
  Last update: 2022-05-17 10:48    [W:0.217 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site