linux-kernel - Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

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]

Message-Id: <C7139FF6-F71F-4FE4-807B-62E1E5C61238@goldelico.com>
Date:   Wed, 9 Oct 2019 16:23:31 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Tero Kristo <t-kristo@...com>
Cc:     Tony Lindgren <tony@...mide.com>,
        Merlijn Wajer <merlijn@...zup.org>,
        Adam Ford <aford173@...il.com>,
        Philipp Rossak <embed3d@...il.com>,
        Paweł Chmiel <pawel.mikolaj.chmiel@...il.com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Filip Matijević <filip.matijevic.pz@...il.com>,
        Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
        moaz korena <moaz@...ena.xyz>,
        James Hilliard <james.hilliard1@...il.com>,
        kernel@...a-handheld.com,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, maemo-leste@...ts.dyne.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-omap <linux-omap@...r.kernel.org>
Subject: Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5


> Am 09.10.2019 um 15:55 schrieb Tero Kristo <t-kristo@...com>:
> 
> On 09/10/2019 15:53, H. Nikolaus Schaller wrote:
>>> Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller <hns@...delico.com>:
>>> 
>>> 
>>> But I can't access the sgx registers and get memory faults. Maybe
>>> my script has a bug and is trying the wrong address. Have to check
>>> with some distance...
>> Now I have done more tests on am335x. It is not my script but something else.
>> Trying to read 0x5600fe00 after doing
>> echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
>> gives page faults.
>> When trying to load the kernel driver, the omap_reset_deassert message has
>> gone but the driver does no initialize:
>> root@...ux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125
>> [   45.774712] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
>> root@...ux:~#
>> Here is the CM/PM register dump after enabling power/control
>> *** SGX Register Dump ***
>> 0x44E00900 00000301 CM_GFX_L3_CLKSTCTRL
>> 0x44E00904 00050000 CM_GFX_GFX_CLKCTRL
>> 0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR
>> 0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL
>> 0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL
>> 0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK
>> 0x44E01100 00060047 PM_GFX_PWRSTCTRL
>> 0x44E01104 00000001 RM_GFX_RSTCTRL
>> 0x44E01110 00000037 PM_GFX_PWRSTST
> 
> Are you sure you have the graphics node properly applied in your kernel?

Not really... There are several patch sets which seem to be necessary
(to support all omap variants) and I am not sure if I have them all and correctly.

I have collected these patches on top of v5.4-rc2:

272d7200c77a ARM: dts: omap5: fix gpu_cm clock provider name
96fa23010f2a dt-bindings: omap: add new binding for PRM instances
a164172c1f40 soc: ti: add initial PRM driver with reset control support
42a5e4261993 soc: ti: omap-prm: poll for reset complete during de-assert
9237f39716be soc: ti: omap-prm: add support for denying idle for reset clockdomain
bf2ae22e5bcf soc: ti: omap-prm: add omap4 PRM data
be5cb64f10e0 soc: ti: omap-prm: add data for am33xx
86646d7d79be soc: ti: omap-prm: add dra7 PRM data
c3b5455dfd65 soc: ti: omap-prm: add am4 PRM data
e26d4ff7ad15 soc: ti: omap-prm: add omap5 PRM data
66369100d1fc clk: ti: am43xx: drop idlest polling from gfx clock
d96899e143de bus: ti-sysc: re-order reset and main clock controls
45071446bd05 bus: ti-sysc: drop the extra hardreset during init
0da134c3aa9d bus: ti-sysc: avoid toggling power state of module during probe
17b70c96b539 ARM: OMAP2+: pdata-quirks: add PRM data for reset support
af81a68c65d7 clk: ti: clkctrl: fix setting up clkctrl clocks
d7dd7f44bce4 clk: ti: clkctrl: convert to use bit helper macros instead of bitops
42ee8270adfd clk: ti: clkctrl: add new exported API for checking standby info
218b39a8c851 dt-bindings: clk: add omap5 iva clkctrl definitions
41b6c466efde clk: ti: omap5: add IVA subsystem clkctrl data
38cfdebcc2f8 clk: ti: dra7xx: Drop idlest polling from IPU & DSP clkctrl clocks
39e827b0dfe5 clk: ti: omap4: Drop idlest polling from IPU & DSP clkctrl clocks
f4584f1e5bff clk: ti: omap5: Drop idlest polling from IPU & DSP clkctrl clocks
1c7f5871e5a0 clk: ti: am43xx: drop idlest polling from pruss clkctrl clock
53363c4cfb3d clk: ti: am33xx: drop idlest polling from pruss clkctrl clock
1907994ee9ce ARM: dts: omap5: add IVA clkctrl nodes
8182f3f282de ARM: dts: dra7: add PRM nodes
ff2880fb99c7 ARM: dts: omap4: add PRM nodes
4d49da48c458 ARM: dts: am33xx: Add PRM data
325cffda2b2d ARM: dts: am43xx: Add PRM data
b6ceeb4c5b74 ARM: dts: omap5: Add PRM data
303b7b4bcc60 ARM: dts: dra7: convert IOMMUs to use ti-sysc
d875126d92f7 ARM: dts: dra74x: convert IOMMUs to use ti-sysc
8f699534deb8 ARM: dts: omap4: convert IOMMUs to use ti-sysc
b1ec9e25a686 ARM: dts: omap5: convert IOMMUs to use ti-sysc
e90c0cc1e4a5 ARM: dts: Configure rstctrl reset for SGX


> As you can see the RM_GFX_RSTCTRL is still asserted (it should be zero so that you can access the module) and the CM_GFX_GFX_CLKCTRL is also disabled (bits 0-1 are 0, should be 2 in the working case.)

Ok.

> 
> It works for me with my branch + the single am33xx patch from Tony.

Is there a link so that I can compare with the right version?

BR and thanks,
Nikolaus