linux-kernel - Re: [PATCH] ARM: dts: gta04: fix excess dma channel usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241107103552.22583403@akair>
Date: Thu, 7 Nov 2024 10:35:52 +0100
From: Andreas Kemnade <andreas@...nade.info>
To: Tony Lindgren <tony@...mide.com>
Cc: Adam Ford <aford173@...il.com>, bcousson@...libre.com,
 robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
 linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, "H. Nikolaus Schaller" <hns@...delico.com>
Subject: Re: [PATCH] ARM: dts: gta04: fix excess dma channel usage

Revisiting it again...

Am Sun, 22 Jan 2023 10:08:52 +0100
schrieb Andreas Kemnade <andreas@...nade.info>:

> On Thu, 19 Jan 2023 09:30:20 +0200
> Tony Lindgren <tony@...mide.com> wrote:
> 
> > * Tony Lindgren <tony@...mide.com> [230116 17:33]:  
> > > * Adam Ford <aford173@...il.com> [230116 17:00]:    
> > > > 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.    
> > > 
> > > Sorry I don't remember if omap_device.c ignores status disabled or not.
> > > But in any case, it should be trivial to update omap3.dtsi to configure
> > > some of the devices like mcspi to probe with device tree data and ti-sysc
> > > as needed.    
> > 
> > So as long as gta04 power management still behaves with this patch it
> > should good to go.
> >   
> # sleep 10 ; /usr/local/bin/idledump
>      CM_IDLEST1_CORE 00000042

RAM + SCM on, no issue, cross-checked, force-enabling mcspi brings more
activity, so this an indication thet mcspi is off.

>      CM_IDLEST3_CORE 00000000
>      CM_FCLKEN1_CORE 00000000

same here with force-enabling mcspi, brings in some bits set.

>      CM_FCLKEN3_CORE 00000002

see comments below.

>      CM_CLKSTST_CORE 00000003
>      CM_IDLEST_CKGEN 00000209

this becomes 1 without this patch.

>     CM_IDLEST2_CKGEN 00000000
>        CM_FCLKEN_DSS 00000000
>        CM_IDLEST_DSS 00000000
>        CM_FCLKEN_CAM 00000000
>        CM_IDLEST_CAM 00000000
>        CM_FCLKEN_PER 00000000
>        CM_IDLEST_PER 00000000
> 
> 
> FCLKEN3_CORE becomes 0 after unbinding the bandgap sensor.
> 
> but...
> # cat /sys/kernel/debug/pm_debug/time 
> usbhost_pwrdm (ON),OFF:830267486567,RET:0,INA:0,ON:12202880865
> sgx_pwrdm (INA),OFF:0,RET:0,INA:841224365234,ON:1245971680
> core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:842470336914
> per_pwrdm (ON),OFF:520406799328,RET:30043365464,INA:0,ON:292020111087
> 
> hmmm.... 
> 
> but does not look like anything related to mcspi*.
> 
it does not look like, but it is, but how... There is something below
my radar.

Regards,
Andreas