Il 08/02/23 09:28, Chen-Yu Tsai ha scritto:

On Mon, Feb 6, 2023 at 11:30 PM AngeloGioacchino Del Regno
[off-list ref] wrote:

quoted

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! :-)

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).


Angelo

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

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