Message-ID: <9059e380-3a80-5d93-6224-08e4eeabf116@ti.com>
Date:   Wed, 9 Oct 2019 19:34:47 +0300
From:   Tero Kristo <t-kristo@...com>
To:     "H. Nikolaus Schaller" <hns@...delico.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

On 09/10/2019 17:23, H. Nikolaus Schaller wrote:
> 
>> 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

You should have similar patch as above for am33xx. Otherwise it will 
probably fail probing the ti-sysc, resulting in the failure you see.

-Tero

> 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
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Powered by blists - more mailing lists