On Mon, Jan 16, 2023 at 10:56 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote:
>
> * Andreas Kemnade <andreas@xxxxxxxxxxxx> [230116 16:39]:
> > On Mon, 16 Jan 2023 16:51:57 +0200
> > Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> >
> > > Hi,
> > >
> > > * Adam Ford <aford173@xxxxxxxxx> [230116 14:16]:
> > > > Would it make sense to make this default in the omap3.dtsi file and
> > > > enable them in the individual boards that need it?
> > >
> > > In general disabling the unused devices by default for omaps will break
> > > the power management. The disabled devices are completely ignored by the
> > > kernel, and the devices are left to whatever the bootloader state might
> > > be.
> > >
> > hmm, shouldn't ti-sysc keep things disabled in most cases? It is still a bit
> > known because there is no status = "disabled" in the target-module@xxx node.
>
> Oh right, if the child device is tagged disabled (instead of the the parent
> ti-sysc tagged disabled) the module should get idled just fine as long as the
> module related quirks are implemented for ti-sysc.c.
>
> But still, I'd rather not start tagging devices disabled by default and then
> re-enabling everywhere since we never needed it before. It just adds a lot
> of pointless status tinkering, see commit 12afc0cf8121 ("ARM: dts: Drop
> pointless status changing for am3 musb").
>
> So considering things, IMO it's best to set only the child device with
> status disabled, and set it at the board specific dts file in this case.
Doesn't this imply the target-module stuff needs to be implemented for
the drivers? It looks like a lot of the omap3 drivers are still using
hwmods although some have target-modules. In this case, the mcspi
drivers that Andreas is disabling don't appear to have target-module
stuff configured.
adam
>
> Also note that the dma channels could be freed with /delete-property/ at the
> board specific dts file even for devices that are usable if not really
> needed.
>
> Regards,
>
> Tony
>
