Re: [PATCH v1 35/45] clk: mediatek: Split MT8195 clock drivers and allow module build

[AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>]

Il 09/02/23 04:46, Chen-Yu Tsai ha scritto:
> On Wed, Feb 8, 2023 at 5:00 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>>
>> Il 08/02/23 09:28, Chen-Yu Tsai ha scritto:
>>> On Mon, Feb 6, 2023 at 11:30 PM AngeloGioacchino Del Regno
>>> <angelogioacchino.delregno@collabora.com> wrote:
>>>>
>>>> MT8195 clock drivers were encapsulated in one single (and big) Kconfig
>>>> option: there's no reason to do that, as it is totally unnecessary to
>>>> build in all or none of them.
>>>>
>>>> Split them out: keep boot-critical clocks as bool and allow choosing
>>>> non critical clocks as tristate.
>>>
>>> The power domain controller references vppsys*, vdecsys*, vdosys*, wpesys,
>>> imgsys and camsys. I'd argue that this makes these clock drivers
>>> semi-boot-critical. Maybe mfgcfg as well when we add the GPU?
>>
>> You don't need to power on additional power domains if you want to load modules
>> from a ramdisk! :-)
> 
> Right.
> 
>> Besides, you caught me: mtk-pm-domains will be my next target after clocks...
>> I don't like how it behaves in regard to probe deferrals. Specifically,
>> I dislike the fact that you either register *all domains* or *none at all*
>> (unless instantiating two different driver instances and that's ugly).
> 
> I don't really like it either, but is it possible to split probe deferrals?
> I mean, if you skip a couple power domains because the clocks aren't
> available, how do you come back to them?
> 

Honestly, I have no clue right now - I didn't even think about any possible
implementation for now... but let's see what I can come up with whenever I
get a chance to actually take a look.

Surely not before finishing work on this series, though.

> And IIRC for a clock provider that is _not_ marked as disabled in the DT,
> trying to fetch a clock from it would just give -EPROBEDEFER until
> the provider is registered.
> 

Yes it will give a probe deferral. An internal probe retry mechanism on the
power domains that couldn't probe would be one of the possible options.

Actually, we have almost endless options on how to resolve that power domains
issue, so it's not worrying me at all!

Cheers,
Angelo

> ChenYu
> 
>>>
>>> They should be bundled together at the very least. The power domain
>>> controller not probing disables all display and multimedia capabilities.
>>>
>>> Also wondering if we should have "default COMMON_CLK_MT8195" ...
>>>
>>> I suppose the same questions apply to other SoCs.
>>>
>>> ChenYu
>>
>>