On 08/11/2024 19:41, Andreas Kemnade wrote:
> Am Fri, 8 Nov 2024 14:42:14 +0200
> schrieb Roger Quadros <rogerq@xxxxxxxxxx>:
>
>>> diff --git a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
>>> index 3661340009e7a..11f8af34498b1 100644
>>> --- a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
>>> +++ b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
>>> @@ -612,19 +612,23 @@ &i2c3 {
>>> };
>>>
>>> &mcspi1 {
>>> - status = "disabled";
>>
>> But according to commit a622310f7f01 ("ARM: dts: gta04: fix excess dma channel usage"),
>> these mcspi modules are not used. So it doesn't make sense to enable them even if it
>> seems to solve the power management issue?
>>
> They are not used, if they are just disabled, kernel does not touch
> them, so if it is there, the kernel can handle
> pm. At least as long as it is not under ti,sysc.
>
> There are probably cleaner solutions for this, but for a CC: stable I
> would prefer something less invasive.
>
> I can try a ti-sysc based fix in parallel.
>
>> Does bootloader leave the mcspi modules in a unwanted state?
>
> Or at least something related to them.
> As said, for the blamed patch I checked only for CM_IDLEST1_CORE
> and CM_FCLKEN1_CORE.
>
>> Would it make sense for the bus driver to explicitly turn off all modules?
>
> Hmm, not very clear what you mean. AFAIK everything below ti-sysc gets
> turned off if a disable is in the child node. Explicitly disabling such
> stuff in the dtsi and enable it in the board dts sound sane
> to me at first glance. I think it is a common pattern. The question is
> whether that causes confusion with not ti-sysc stuff. Well, having
> status=okay everywhere in the dts should not harm.
> But as said for a regression fix some overhaul affecting every device
> is out of scope.
McSPI modules have Revision, Syconfig and Sysstatus registers.
Is it because we are missing the ti-sysc representation for it
that the module power is not being correctly handled in Linux
if module is kept disabled?
--
cheers,
-roger
