Messages in this thread | | | From | Chen-Yu Tsai <> | Date | Thu, 9 Feb 2023 11:46:12 +0800 | Subject | Re: [PATCH v1 35/45] clk: mediatek: Split MT8195 clock drivers and allow module build |
| |
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?
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.
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 > >
| |