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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sun, 22 Jan 2023 10:08: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

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
     CM_IDLEST3_CORE 00000000
     CM_FCLKEN1_CORE 00000000
     CM_FCLKEN3_CORE 00000002
     CM_CLKSTST_CORE 00000003
     CM_IDLEST_CKGEN 00000209
    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*.

Regards,
Andreas