Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
> Am 09.10.2019 um 18:34 schrieb Tero Kristo : > > On 09/10/2019 17:23, H. Nikolaus Schaller wrote: >>> Am 09.10.2019 um 15:55 schrieb Tero Kristo : >>> >>> On 09/10/2019 15:53, H. Nikolaus Schaller wrote: > Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller : > > > 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@letux:~# 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@letux:~# Here is the CM/PM register dump after enabling power/control *** SGX Register Dump *** 0x44E00900 0301 CM_GFX_L3_CLKSTCTRL 0x44E00904 0005 CM_GFX_GFX_CLKCTRL 0x44E0090c 0002 CM_GFX_L4LS_GFX_CLKSTCTR 0x44E00910 0003 CM_GFX_MMUCFG_CLKCTRL 0x44E00914 0003 CM_GFX_MMUDATA_CLKCTRL 0x44E0052c CM_DPLL.CLKSEL_GFX_FCLK 0x44E01100 00060047 PM_GFX_PWRSTCTRL 0x44E01104 0001 RM_GFX_RSTCTRL 0x44E01110 0037 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 so the pattern of ^^^ but for gfx clock? Yes, there seems to be [PATCH 1/2] clk: ti: am33xx: drop idlest polling from gfx clock which I am missing. Most likely, I accidentally did download from patchwork just a single patch (am43xx) and not the series... With this patch added, I now have access to the sgx registers: root@letux:~# ./sgxdump *** SGX Register Dump *** 0x44E00900 0302 CM_GFX_L3_CLKSTCTRL 0x44E00904 00040002 CM_GFX_GFX_CLKCTRL 0x44E0090c 0002 CM_GFX_L4LS_GFX_CLKSTCTR 0x44E00910 0003 CM_GFX_MMUCFG_CLKCTRL 0x44E00914 0003 CM_GFX_MMUDATA_CLKCTRL 0x44E0052c CM_DPLL.CLKSEL_GFX_FCLK 0x44E01100 00060047 PM_GFX_PWRSTCTRL 0x44E01104 RM_GFX_RSTCTRL 0x44E01110 0037 PM_GFX_PWRSTST 0x5600fe14 SGX_CORE_VERSION 0x5600fe00 4000 OCP_REVISION 0x5600fe04 0005 OCP_HWINFO 0x5600fe10 0028 OCP_SYSCONFIG 0x5600fe24 OCP_IRQSTATUS_RA_0 0x5600fe28 OCP_IRQSTATUS_RA_1 0x5600fe2c OCP_IRQSTATUS_RA_2 0x5600fe30 OCP_IRQSTATUS_0 0x5600fe34 OCP_IRQSTATUS_1 0x5600fe38 OCP_IRQSTATUS_2 0x5600fe3c OCP_IRQENABLE_SET_0 0x5600fe40 OCP_IRQENABLE_SET_1 0x5600fe44 OCP_IRQENABLE_SET_2
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 : On 09/10/2019 15:53, H. Nikolaus Schaller wrote: Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller : 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@letux:~# 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@letux:~# Here is the CM/PM register dump after enabling power/control *** SGX Register Dump *** 0x44E00900 0301 CM_GFX_L3_CLKSTCTRL 0x44E00904 0005 CM_GFX_GFX_CLKCTRL 0x44E0090c 0002 CM_GFX_L4LS_GFX_CLKSTCTR 0x44E00910 0003 CM_GFX_MMUCFG_CLKCTRL 0x44E00914 0003 CM_GFX_MMUDATA_CLKCTRL 0x44E0052c CM_DPLL.CLKSEL_GFX_FCLK 0x44E01100 00060047 PM_GFX_PWRSTCTRL 0x44E01104 0001 RM_GFX_RSTCTRL 0x44E01110 0037 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
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 : > > On 09/10/2019 15:53, H. Nikolaus Schaller wrote: >>> Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller : >>> >>> >>> 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@letux:~# 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@letux:~# >> Here is the CM/PM register dump after enabling power/control >> *** SGX Register Dump *** >> 0x44E00900 0301 CM_GFX_L3_CLKSTCTRL >> 0x44E00904 0005 CM_GFX_GFX_CLKCTRL >> 0x44E0090c 0002 CM_GFX_L4LS_GFX_CLKSTCTR >> 0x44E00910 0003 CM_GFX_MMUCFG_CLKCTRL >> 0x44E00914 0003 CM_GFX_MMUDATA_CLKCTRL >> 0x44E0052c CM_DPLL.CLKSEL_GFX_FCLK >> 0x44E01100 00060047 PM_GFX_PWRSTCTRL >> 0x44E01104 0001 RM_GFX_RSTCTRL >> 0x44E01110 0037 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
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
On 09/10/2019 15:53, H. Nikolaus Schaller wrote: Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller : Am 08.10.2019 um 10:00 schrieb Tero Kristo : On 07/10/2019 22:24, H. Nikolaus Schaller wrote: Hi Tero, Am 07.10.2019 um 21:18 schrieb Tero Kristo : On 07/10/2019 18:52, Tony Lindgren wrote: Hi, * H. Nikolaus Schaller [191005 16:59]: Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues. Yeah, this one should be fixed now. Ok! Will try asap. * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version) [ 304.140363] clock-controller:clk::0: failed to enable [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16) Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas? So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though. Is there some simple way to try this out on board; without PVR module that is? Yes, I have also seen it when just running the commands in the original commit message [1]: # echo on > $(find /sys -name control | grep \/5600) # rwmem 0x5600fe00 # OCP Revision 0x5600fe00 = 0x4000 # echo auto > $(find /sys -name control | grep \/5600) # rwmem 0x5600fe10 # rwmem 0x5624 But I have not yet tested with 5.4-rc2, just 5.4-rc1. Ok, there is a one liner DTS data fix for this issue, attached. Yes, have tested and it fixes omap5. I have the 3D demo running again on the Pyra. Yay! Together with the latest rstcrtl patches, am335x is now better. No omap_reset_deassert: timedout waiting for gfx:0 any more. 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@letux:~# 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@letux:~# Here is the CM/PM register dump after enabling power/control *** SGX Register Dump *** 0x44E00900 0301 CM_GFX_L3_CLKSTCTRL 0x44E00904 0005 CM_GFX_GFX_CLKCTRL 0x44E0090c 0002 CM_GFX_L4LS_GFX_CLKSTCTR 0x44E00910 0003 CM_GFX_MMUCFG_CLKCTRL 0x44E00914 0003 CM_GFX_MMUDATA_CLKCTRL 0x44E0052c CM_DPLL.CLKSEL_GFX_FCLK 0x44E01100 00060047 PM_GFX_PWRSTCTRL 0x44E01104 0001 RM_GFX_RSTCTRL 0x44E01110 0037 PM_GFX_PWRSTST Are you sure you have the graphics node properly applied in your kernel? 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.) It works for me with my branch + the single am33xx patch from Tony. -Tero BR, Nikolaus -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
> Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller : > > >> Am 08.10.2019 um 10:00 schrieb Tero Kristo : >> >> On 07/10/2019 22:24, H. Nikolaus Schaller wrote: >>> Hi Tero, Am 07.10.2019 um 21:18 schrieb Tero Kristo : On 07/10/2019 18:52, Tony Lindgren wrote: > Hi, > * H. Nikolaus Schaller [191005 16:59]: > Please try with Tero's current github branch at > github.com/t-kristo/linux-pm.git > 5.4-rc1-ipc from few days ago, the earlier versions had still issues. Yeah, this one should be fixed now. >>> Ok! Will try asap. >> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous >> version) >> [ 304.140363] clock-controller:clk::0: failed to enable >> [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync >> failed (16) > Hmm no idea what might be up with this one. Did some clkctrl clock > fixes maybe cause a regression here? Tero do you have any ideas? So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though. Is there some simple way to try this out on board; without PVR module that is? >>> Yes, I have also seen it when just running the commands in the original >>> commit message [1]: >>> # echo on > $(find /sys -name control | grep \/5600) >>> # rwmem 0x5600fe00 # OCP Revision >>> 0x5600fe00 = 0x4000 >>> # echo auto > $(find /sys -name control | grep \/5600) >>> # rwmem 0x5600fe10 >>> # rwmem 0x5624 >>> But I have not yet tested with 5.4-rc2, just 5.4-rc1. >> >> Ok, there is a one liner DTS data fix for this issue, attached. > > Yes, have tested and it fixes omap5. I have the 3D demo running again on the > Pyra. Yay! > > Together with the latest rstcrtl patches, am335x is now better. > No omap_reset_deassert: timedout waiting for gfx:0 any more. > > 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@letux:~# 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@letux:~# Here is the CM/PM register dump after enabling power/control *** SGX Register Dump *** 0x44E00900 0301 CM_GFX_L3_CLKSTCTRL 0x44E00904 0005 CM_GFX_GFX_CLKCTRL 0x44E0090c 0002 CM_GFX_L4LS_GFX_CLKSTCTR 0x44E00910 0003 CM_GFX_MMUCFG_CLKCTRL 0x44E00914 0003 CM_GFX_MMUDATA_CLKCTRL 0x44E0052c CM_DPLL.CLKSEL_GFX_FCLK 0x44E01100 00060047 PM_GFX_PWRSTCTRL 0x44E01104 0001 RM_GFX_RSTCTRL 0x44E01110 0037 PM_GFX_PWRSTST BR, Nikolaus
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
> Am 08.10.2019 um 10:00 schrieb Tero Kristo : > > On 07/10/2019 22:24, H. Nikolaus Schaller wrote: >> Hi Tero, >>> Am 07.10.2019 um 21:18 schrieb Tero Kristo : >>> >>> On 07/10/2019 18:52, Tony Lindgren wrote: Hi, * H. Nikolaus Schaller [191005 16:59]: Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues. >>> >>> Yeah, this one should be fixed now. >> Ok! Will try asap. >>> > * OMAP5 (Pyra): fails to enable the clocks (did work with the previous > version) > [ 304.140363] clock-controller:clk::0: failed to enable > [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed > (16) Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas? >>> >>> So, this one I am not too sure, I haven't looked at omap5 graphics >>> clocking. I don't think it has anything to do with reset handling though. >>> >>> Is there some simple way to try this out on board; without PVR module that >>> is? >> Yes, I have also seen it when just running the commands in the original >> commit message [1]: >> # echo on > $(find /sys -name control | grep \/5600) >> # rwmem 0x5600fe00 # OCP Revision >> 0x5600fe00 = 0x4000 >> # echo auto > $(find /sys -name control | grep \/5600) >> # rwmem 0x5600fe10 >> # rwmem 0x5624 >> But I have not yet tested with 5.4-rc2, just 5.4-rc1. > > Ok, there is a one liner DTS data fix for this issue, attached. Yes, have tested and it fixes omap5. I have the 3D demo running again on the Pyra. Yay! Together with the latest rstcrtl patches, am335x is now better. No omap_reset_deassert: timedout waiting for gfx:0 any more. 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... I have also tested omap3630 and omap4460 and they are not worse, but also not better. So I think the foundation for sgx clock and reset is now ok. BR and thanks, Nikolaus
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
* Tero Kristo [191008 08:01]:
> On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
> > Hi Tero,
> >
> > > Am 07.10.2019 um 21:18 schrieb Tero Kristo :
> > >
> > > On 07/10/2019 18:52, Tony Lindgren wrote:
> > > > Hi,
> > > > * H. Nikolaus Schaller [191005 16:59]:
> > > > Please try with Tero's current github branch at
> > > > github.com/t-kristo/linux-pm.git
> > > > 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
> > >
> > > Yeah, this one should be fixed now.
> >
> > Ok! Will try asap.
> >
> > >
> > > > > * OMAP5 (Pyra): fails to enable the clocks (did work with the
> > > > > previous version)
> > > > > [ 304.140363] clock-controller:clk::0: failed to enable
> > > > > [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync
> > > > > failed (16)
> > > > Hmm no idea what might be up with this one. Did some clkctrl clock
> > > > fixes maybe cause a regression here? Tero do you have any ideas?
> > >
> > > So, this one I am not too sure, I haven't looked at omap5 graphics
> > > clocking. I don't think it has anything to do with reset handling though.
> > >
> > > Is there some simple way to try this out on board; without PVR module
> > > that is?
> >
> > Yes, I have also seen it when just running the commands in the original
> > commit message [1]:
> >
> > # echo on > $(find /sys -name control | grep \/5600)
> > # rwmem 0x5600fe00 # OCP Revision
> > 0x5600fe00 = 0x4000
> > # echo auto > $(find /sys -name control | grep \/5600)
> > # rwmem 0x5600fe10
> > # rwmem 0x5624
> >
> > But I have not yet tested with 5.4-rc2, just 5.4-rc1.
>
> Ok, there is a one liner DTS data fix for this issue, attached.
Arhg OK that thing again.. I must have changed node name while
cleaning up the patch or something. Thanks, will apply into fixes.
Then for v5.5, we should start using custom compatible properties
for the clock controller instances. I'll be posting a patch for that.
Otherwise scripts/checkpatch.pl --strict type clean-up will cause
unexpected issues.
Regards,
Tony
> From 57f9fecb167c0ef9f1ae2a1aa93a05ca8add52a2 Mon Sep 17 00:00:00 2001
> From: Tero Kristo
> Date: Tue, 8 Oct 2019 10:56:42 +0300
> Subject: [PATCH 1/1] ARM: dts: omap5: fix gpu_cm clock provider name
>
> The clkctrl code searches for the parent clockdomain based on the name
> of the CM provider node. The introduction of SGX node for omap5 made
> the node name for the gpu_cm to be clock-controller. There is no
> clockdomain named like this, so the lookup fails. Fix by changing
> the node name properly.
>
> Fixes: 394534cb07d8 ("ARM: dts: Configure sgx for omap5")
> Signed-off-by: Tero Kristo
> ---
> arch/arm/boot/dts/omap54xx-clocks.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
> b/arch/arm/boot/dts/omap54xx-clocks.dtsi
> index 939ec7dfc366..db9885103099 100644
> --- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
> @@ -1160,7 +1160,7 @@
> };
> };
>
> - gpu_cm: clock-controller@1500 {
> + gpu_cm: gpu_cm@1500 {
> compatible = "ti,omap4-cm";
> reg = <0x1500 0x100>;
> #address-cells = <1>;
> --
> 2.17.1
>
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
Hi Tero,
Am 07.10.2019 um 21:18 schrieb Tero Kristo :
On 07/10/2019 18:52, Tony Lindgren wrote:
Hi,
* H. Nikolaus Schaller [191005 16:59]:
Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git
5.4-rc1-ipc from few days ago, the earlier versions had still issues.
Yeah, this one should be fixed now.
Ok! Will try asap.
* OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
[ 304.140363] clock-controller:clk::0: failed to enable
[ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
Hmm no idea what might be up with this one. Did some clkctrl clock
fixes maybe cause a regression here? Tero do you have any ideas?
So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I
don't think it has anything to do with reset handling though.
Is there some simple way to try this out on board; without PVR module that is?
Yes, I have also seen it when just running the commands in the original commit
message [1]:
# echo on > $(find /sys -name control | grep \/5600)
# rwmem 0x5600fe00 # OCP Revision
0x5600fe00 = 0x4000
# echo auto > $(find /sys -name control | grep \/5600)
# rwmem 0x5600fe10
# rwmem 0x5624
But I have not yet tested with 5.4-rc2, just 5.4-rc1.
Ok, there is a one liner DTS data fix for this issue, attached.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki>From 57f9fecb167c0ef9f1ae2a1aa93a05ca8add52a2 Mon Sep 17 00:00:00 2001
From: Tero Kristo
Date: Tue, 8 Oct 2019 10:56:42 +0300
Subject: [PATCH 1/1] ARM: dts: omap5: fix gpu_cm clock provider name
The clkctrl code searches for the parent clockdomain based on the name
of the CM provider node. The introduction of SGX node for omap5 made
the node name for the gpu_cm to be clock-controller. There is no
clockdomain named like this, so the lookup fails. Fix by changing
the node name properly.
Fixes: 394534cb07d8 ("ARM: dts: Configure sgx for omap5")
Signed-off-by: Tero Kristo
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index 939ec7dfc366..db9885103099 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -1160,7 +1160,7 @@
};
};
- gpu_cm: clock-controller@1500 {
+ gpu_cm: gpu_cm@1500 {
compatible = "ti,omap4-cm";
reg = <0x1500 0x100>;
#address-cells = <1>;
--
2.17.1
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
Hi Tero, > Am 07.10.2019 um 21:18 schrieb Tero Kristo : > > On 07/10/2019 18:52, Tony Lindgren wrote: >> Hi, >> * H. Nikolaus Schaller [191005 16:59]: >> Please try with Tero's current github branch at >> github.com/t-kristo/linux-pm.git >> 5.4-rc1-ipc from few days ago, the earlier versions had still issues. > > Yeah, this one should be fixed now. Ok! Will try asap. > >>> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous >>> version) >>> [ 304.140363] clock-controller:clk::0: failed to enable >>> [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed >>> (16) >> Hmm no idea what might be up with this one. Did some clkctrl clock >> fixes maybe cause a regression here? Tero do you have any ideas? > > So, this one I am not too sure, I haven't looked at omap5 graphics clocking. > I don't think it has anything to do with reset handling though. > > Is there some simple way to try this out on board; without PVR module that is? Yes, I have also seen it when just running the commands in the original commit message [1]: # echo on > $(find /sys -name control | grep \/5600) # rwmem 0x5600fe00 # OCP Revision 0x5600fe00 = 0x4000 # echo auto > $(find /sys -name control | grep \/5600) # rwmem 0x5600fe10 # rwmem 0x5624 But I have not yet tested with 5.4-rc2, just 5.4-rc1. BR and thanks, Nikolaus [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.4-rc2=394534cb07d8f89b6e621e8a1e6da23571725aef
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
On 07/10/2019 18:52, Tony Lindgren wrote: Hi, * H. Nikolaus Schaller [191005 16:59]: Hi all, with the arrival of v5.4-rc1 some of Tony's sysc patches have arrived upstream, so we do no longer need them here. Therefore, I have rebased my drivers/staging/pvr driver [1] and fixed some more issues: * omap4 build only needs to distinguish between omap4420/30/60 and omap4470, because the latter has an sgx544 inside and the other sgx540 This is solved by creating a new omap4470.dts * I have added proper reg values and interrupts to the omap4 device tree node of the sgx (child node of the target-module) * some updates to my sgxdump and sgxdemo scripts (assuming simple Debian Stretch rootfs) * James Hilliard has contributed a fix for osfunc.c * omap2plus also needs to be configured for STAGING and PREEMPT to be able to compile the driver * I have added the __always_inline fix [2] which is needed for v5.4 with CONFIG_CC_OPTIMIZE_FOR_SIZE=y (which I are enabled on the Letux builds) Unfortunately Tero's rstctrl patches did not yet make it upstream (or even linux-next) so I also have a copy in this branch. Results of first testing are: * OMAP3530 (OpenPandora, BeagleBoard C): fails with [ 559.247558] PVR_K:(Error): SysLocateDevices: platform_get_resource failed * DM3730 (GTA04, BeagleBoard XM): kernel module loads * OMAP4460 (Pandaboard ES): kernel module loads * AM335x (BeagleBoneBlack): reports a problem with omap_reset_deassert: [ 204.246706] omap_reset_deassert: timedout waiting for gfx:0 Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues. Yeah, this one should be fixed now. * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version) [ 304.140363] clock-controller:clk::0: failed to enable [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16) Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas? So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though. Is there some simple way to try this out on board; without PVR module that is? -Tero * OMAP5 with omap2plus_defconfig: root@letux:~# echo on > $(find /sys -name control | grep \/5600) [ 213.490926] clock-controller:clk::0: failed to enable root@letux:~# * pvrsrvctl --start --no-module: reports (where the kernel module loads) that the uKernel does not run So I have several ideas what the reasons for the problems on the non-omap5 devices could be: * initial code may have some omap5 specific hack inside * or has omap5 specific magic constants * uKernel may "know" on which platform it runs and we would need differently patched user-space code for each one * omap5 has a dual core sgx544 while the other have single core * the register address translation is not yet correct and this inhibits communicating of the user-space libs with the uKernel Maybe, if someone can point me to a complete and working BeagleBone source tree (any kernel release) which makes use of 1.14.3699939 SDK, I could compare code and address setup to find what makes the difference. Regards, Tony [1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux-pvr [2]: https://lkml.org/lkml/2019/10/2/201 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
> Am 07.10.2019 um 17:52 schrieb Tony Lindgren : > > Hi, > > * H. Nikolaus Schaller [191005 16:59]: >> >> >> * AM335x (BeagleBoneBlack): reports a problem with omap_reset_deassert: >> [ 204.246706] omap_reset_deassert: timedout waiting for gfx:0 > > Please try with Tero's current github branch at > github.com/t-kristo/linux-pm.git > 5.4-rc1-ipc from few days ago, the earlier versions had still issues. I have seen there has been a new version today and I'll try that one asap. > >> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous >> version) >> [ 304.140363] clock-controller:clk::0: failed to enable >> [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed >> (16) > > Hmm no idea what might be up with this one. Did some clkctrl clock > fixes maybe cause a regression here? Tero do you have any ideas? BR and thanks, Nikolaus
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
Hi, * H. Nikolaus Schaller [191005 16:59]: > Hi all, > with the arrival of v5.4-rc1 some of Tony's sysc patches have arrived > upstream, so we do no longer need them here. > > Therefore, I have rebased my drivers/staging/pvr driver [1] and fixed some > more issues: > * omap4 build only needs to distinguish between omap4420/30/60 and omap4470, > because the latter has an sgx544 inside and the other sgx540 > This is solved by creating a new omap4470.dts > * I have added proper reg values and interrupts to the omap4 device > tree node of the sgx (child node of the target-module) > * some updates to my sgxdump and sgxdemo scripts (assuming simple > Debian Stretch rootfs) > * James Hilliard has contributed a fix for osfunc.c > * omap2plus also needs to be configured for STAGING and PREEMPT > to be able to compile the driver > * I have added the __always_inline fix [2] which is needed for v5.4 with > CONFIG_CC_OPTIMIZE_FOR_SIZE=y (which I are enabled on the Letux builds) > > Unfortunately Tero's rstctrl patches did not yet make it upstream (or even > linux-next) so I also have a copy in this branch. > > Results of first testing are: > * OMAP3530 (OpenPandora, BeagleBoard C): fails with > [ 559.247558] PVR_K:(Error): SysLocateDevices: platform_get_resource failed > > * DM3730 (GTA04, BeagleBoard XM): kernel module loads > > * OMAP4460 (Pandaboard ES): kernel module loads > > * AM335x (BeagleBoneBlack): reports a problem with omap_reset_deassert: > [ 204.246706] omap_reset_deassert: timedout waiting for gfx:0 Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues. > * OMAP5 (Pyra): fails to enable the clocks (did work with the previous > version) > [ 304.140363] clock-controller:clk::0: failed to enable > [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16) Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas? > * OMAP5 with omap2plus_defconfig: > root@letux:~# echo on > $(find /sys -name control | grep \/5600) > [ 213.490926] clock-controller:clk::0: failed to enable > root@letux:~# > > * pvrsrvctl --start --no-module: > reports (where the kernel module loads) that the uKernel does not run > > So I have several ideas what the reasons for the problems on the non-omap5 > devices could be: > * initial code may have some omap5 specific hack inside > * or has omap5 specific magic constants > * uKernel may "know" on which platform it runs and > we would need differently patched user-space code > for each one > * omap5 has a dual core sgx544 while the other > have single core > * the register address translation is not yet correct and > this inhibits communicating of the user-space libs > with the uKernel > > Maybe, if someone can point me to a complete and working BeagleBone source > tree (any kernel release) which makes use of 1.14.3699939 SDK, I could compare > code and address setup to find what makes the difference. Regards, Tony > [1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux-pvr > [2]: https://lkml.org/lkml/2019/10/2/201
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
* Adam Ford [190819 19:26]: > On Sat, Aug 17, 2019 at 2:03 AM Tony Lindgren wrote: > > > > * Adam Ford [190816 23:02]: > > > On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren wrote: > > > > Well I just posted some sgx interconnect target module patches. We might > > > > still have them in v5.4 assuming people manage to review and test them. > > > > > > Nikolaus, > > > > > > I tested Tony's change and I can confirm that I can read the value > > > when enabled. Should I apply his patches to your branch before I > > > test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a > > > DM3730. I am not sure if the AM3517 is even on the radar, but it has > > > an sgx530 as well. > > > > My estimate is am3517 is wired the same way as omap34xx with a 60% > > chance, then 30% chance it's wired the same way as omap36xx, and then > > 10% chance for similar wiring to am335x.. So hopefully that leaves 0% > > chance for yet something different for it's wiring :) > > Based on [1], I went under the assumption it was wired like the > omap34xx. I applied your omap34 patches to the am3517.dtsi, and I was > able to get the same response as I did for the omap3530. Do you want > me to post the patches to the mailing list, or do you want to do it? OK great, yeah please post patches :) Thanks, TOny
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
Hi, On 20/08/2019 08:48, H. Nikolaus Schaller wrote: > >> Am 19.08.2019 um 21:43 schrieb Adam Ford : >> >>> Thanks to the help from the Pyra community, I was able to get a (binary) >>> reference >>> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1. >> >> just a question, >> >> If DRM is working, does that mean it works without needing the overhead of X? > > Yes, we have to kill X11 to successfully run the gles1test1. An interesting > question > will be how to mix both... E.g. have a 3D rendering in a window controlled by > some > window manager. > This is probably what you want to look at / start with: https://github.com/TexasInstruments/dri3wsegl Cheers, Merlijn signature.asc Description: OpenPGP digital signature
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
> Am 19.08.2019 um 21:43 schrieb Adam Ford : > >> Thanks to the help from the Pyra community, I was able to get a (binary) >> reference >> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1. > > just a question, > > If DRM is working, does that mean it works without needing the overhead of X? Yes, we have to kill X11 to successfully run the gles1test1. An interesting question will be how to mix both... E.g. have a 3D rendering in a window controlled by some window manager.
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
On Wed, Aug 14, 2019 at 3:56 AM H. Nikolaus Schaller wrote: > > Hi all, > > > Am 17.07.2019 um 12:51 schrieb Merlijn Wajer : > > > > Hi, > > > > On 10/03/2019 08:07, H. Nikolaus Schaller wrote: > >> > >>> Am 10.03.2019 um 00:14 schrieb Merlijn Wajer : > >>> > >>> Hi, > >>> > >>> On 15/02/2019 14:09, H. Nikolaus Schaller wrote: > >>> > >> At least I can download and start firmware. I just have to find a way > >> to fix the omaplfb so that it works > >> with our omapdrm based panels to runs the CLipBlit test [1] on modern > >> kernels... > > > > Maybe you can compare with what we have here: > > https://github.com/maemo-leste/n9xx-linux/tree/pvr-wip-4.15.7/drivers/gpu/pvr > > I'll take a look into it especially how omaplfb is done. > > First observation is that there is a "flat" tree while I am working on a > structured one... > But that is just a marginal difference (mainly significant for Makefile > writers). > >>> > >>> I've ported the Maemo Leste kernel + pvr to 5.0 and it seems to work: > >>> https://github.com/maemo-leste/n9xx-linux/commits/pvr-wip-5.0.y > >>> > >>> Should I add this as maemo-leste-n900-5.0 branch (or something) to > >>> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx ? > >> > >> Yes, that would be nice to be able to easily compare stuff. > > > > I've just pushed the Maemo Leste v5.1 branch + patches here: > > > > > > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/n900/v5.1-patch > > > > This works on N900 with X, but it doesn't use DRM yet. I'm wondering > > what a next logical step would be: to try and modules to load/probe on > > another device (I have a droid4 or a Pandaboard ES rev B1), or to try > > and get DRM PowerVR to work on the N900, with omapdrmfb and dri3wsegl. > > > > For either path, I'll probably need some help. Any updates from anyone > > else? Maybe we should list things people can work - perhaps document > > progress in github issues. (Mailing list is also fine, BTW) > > > > Cheers, > > Merlijn > > > > I also have pushed good news to > > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr > > Thanks to the help from the Pyra community, I was able to get a (binary) > reference > implementation using DRM that works on Pyra/OMAP5. At least the gles1test1. just a question, If DRM is working, does that mean it works without needing the overhead of X? adam > > With that reference setup I was able to fix my Makefiles for the staging/pvr > implementation. > > I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the > LetuxOS kernel tree) > on the Pyra. > > In which areas does this tree go beyond the TI SDK/IMG DDK 1.14? > > * includes internal API fixes for kernels up to v5.3 > * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for > inclusion in linux-next > * has Kconfig and Makefiles for in-kernel configuration (no separate build > system) > * builds separate kernel modules for omap3430, omap3630, am335x, omap4, > omap5, dra7 etc. > pvrsrvkm > e.g. pvrsrvkm_omap_omap5_sgx544_116 > * the correct kernel module is automatically probed by matching .compatible > in device tree > so that the code is multi-platform friendly > * includes SoC integration for OMAP3/4/5 and has some preliminary bindings > documentation > * code base should also support JZ4780/CI20 and some Intel Atom processors > (CedarView, Poulsbo) > * has got a ToDo to describe what should be done during staging phase > > > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO > > My plans for the next steps are: > > * do more testing (e.g. X11, kmscube) > * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, > OpenPandora) > * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline > kernels and I am > missing the user-space libraries for MIPS). > > BR, > Nikolaus >
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
On Sat, Aug 17, 2019 at 2:03 AM Tony Lindgren wrote: > > * Adam Ford [190816 23:02]: > > On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren wrote: > > > Well I just posted some sgx interconnect target module patches. We might > > > still have them in v5.4 assuming people manage to review and test them. > > > > Nikolaus, > > > > I tested Tony's change and I can confirm that I can read the value > > when enabled. Should I apply his patches to your branch before I > > test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a > > DM3730. I am not sure if the AM3517 is even on the radar, but it has > > an sgx530 as well. > > My estimate is am3517 is wired the same way as omap34xx with a 60% > chance, then 30% chance it's wired the same way as omap36xx, and then > 10% chance for similar wiring to am335x.. So hopefully that leaves 0% > chance for yet something different for it's wiring :) Based on [1], I went under the assumption it was wired like the omap34xx. I applied your omap34 patches to the am3517.dtsi, and I was able to get the same response as I did for the omap3530. Do you want me to post the patches to the mailing list, or do you want to do it? adam [1] - http://processors.wiki.ti.com/index.php/GSG:_AM35x_and_OMAP35x_Rebuilding_the_Software#How_to_check_for_SGX_core_revision > > If you have a chance please give it a try. Also check the TRM for the > sgx sysconfig register bits to see which of the above matches, and if > 3517 has a related rstctrl register like am335x has. > > Regards, > > Tony
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
Hi Adam, > Am 17.08.2019 um 01:01 schrieb Adam Ford : > > > Nikolaus, > > I tested Tony's change and I can confirm that I can read the value > when enabled. Should I apply his patches to your branch before I > test, or is it go too to go as-is? My branch is currently as-is and not aware of Tony's patches and based on v5.3-rc3. I think I will have to remove some glue code which tries to do the platform reset and enables clocks and replace by pm_runtime_get_sync() before it fits together. Then we can likely remove the omap-pvr-soc-glue branch at least partially and/or replace by Tony's patches before they arrive in mainline. The current status of my branch is that it works on OMAP5/Pyra but a quick test on BeagleBone or GTA04 did show some reset/clock errors and it did not more than creating /proc/pvr. pvrsrvctl --start did fail. Which means that the omap-pvr-soc-glue patches are currently broken with 5.3-rc3 anyways... I'll look at it as soon as possible. > I've got an AM3517, OMAP35 and a > DM3730. I am not sure if the AM3517 is even on the radar, but it has > an sgx530 as well. Good to know and keep in mind. BR, Nikolaus
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
* Adam Ford [190816 23:02]: > On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren wrote: > > Well I just posted some sgx interconnect target module patches. We might > > still have them in v5.4 assuming people manage to review and test them. > > Nikolaus, > > I tested Tony's change and I can confirm that I can read the value > when enabled. Should I apply his patches to your branch before I > test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a > DM3730. I am not sure if the AM3517 is even on the radar, but it has > an sgx530 as well. My estimate is am3517 is wired the same way as omap34xx with a 60% chance, then 30% chance it's wired the same way as omap36xx, and then 10% chance for similar wiring to am335x.. So hopefully that leaves 0% chance for yet something different for it's wiring :) If you have a chance please give it a try. Also check the TRM for the sgx sysconfig register bits to see which of the above matches, and if 3517 has a related rstctrl register like am335x has. Regards, Tony
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren wrote: > > * H. Nikolaus Schaller [190814 10:34]: > > > > > Am 14.08.2019 um 11:47 schrieb Tony Lindgren : > > > > > > * H. Nikolaus Schaller [190814 08:57]: > > >> I also have pushed good news to > > >> > > >>https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr > > >> > > >> Thanks to the help from the Pyra community, I was able to get a (binary) > > >> reference > > >> implementation using DRM that works on Pyra/OMAP5. At least the > > >> gles1test1. > > >> > > >> With that reference setup I was able to fix my Makefiles for the > > >> staging/pvr implementation. > > >> > > >> I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of > > >> the LetuxOS kernel tree) > > >> on the Pyra. > > >> > > >> In which areas does this tree go beyond the TI SDK/IMG DDK 1.14? > > >> > > >> * includes internal API fixes for kernels up to v5.3 > > >> * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for > > >> inclusion in linux-next > > >> * has Kconfig and Makefiles for in-kernel configuration (no separate > > >> build system) > > >> * builds separate kernel modules for omap3430, omap3630, am335x, omap4, > > >> omap5, dra7 etc. > > >> pvrsrvkm > > >> e.g. pvrsrvkm_omap_omap5_sgx544_116 > > >> * the correct kernel module is automatically probed by matching > > >> .compatible in device tree > > >> so that the code is multi-platform friendly > > >> * includes SoC integration for OMAP3/4/5 and has some preliminary > > >> bindings documentation > > >> * code base should also support JZ4780/CI20 and some Intel Atom > > >> processors (CedarView, Poulsbo) > > >> * has got a ToDo to describe what should be done during staging phase > > >> > > >> > > >> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO > > >> > > >> My plans for the next steps are: > > >> > > >> * do more testing (e.g. X11, kmscube) > > >> * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. > > >> GTA04, OpenPandora) > > >> * try a JZ480/CI20 build (unfortuantely I have no HDMI there with > > >> mainline kernels and I am > > >> missing the user-space libraries for MIPS). > > > > > > That sounds good to me, just one comment. Before getting these into > > > staging, I'd like to have omap variants use proper interconnect > > > target module in devicetree like we already have in omap4.dtsi > > > as target-module@5600. This should simplify things further > > > as the module child device driver(s) can just enable things with > > > runtime PM and we can leave out all the legacy hwmod platform data > > > that sounds like you're still carrying. > > > > Yes, there is still a lot of SoC-glue included: > > > > > > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-pvr-soc-glue > > > > It would indeed be a good move to simplify and reduce the glue code > > and make it more maintainable / stable / identical on different platforms. > > OK yeah all that should just disappear :) > > > > I have patches here to add similar interconnect target modules for > > > at least omap34xx, omap36xx, omap5, and am335x that I'll try to post > > > later on today to play with. For am335x, things still depend on the > > > recentely posted prm rstctrl patches. I'm not sure if I already > > > did a dts patch for dra7 yet, need to check. > > > > I assume it is not yet in linux-next... So something for v5.5 or later. > > Well I just posted some sgx interconnect target module patches. We might > still have them in v5.4 assuming people manage to review and test them. Nikolaus, I tested Tony's change and I can confirm that I can read the value when enabled. Should I apply his patches to your branch before I test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a DM3730. I am not sure if the AM3517 is even on the radar, but it has an sgx530 as well. adam > > Regards, > > Tony
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
* H. Nikolaus Schaller [190814 10:34]: > > > Am 14.08.2019 um 11:47 schrieb Tony Lindgren : > > > > * H. Nikolaus Schaller [190814 08:57]: > >> I also have pushed good news to > >> > >>https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr > >> > >> Thanks to the help from the Pyra community, I was able to get a (binary) > >> reference > >> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1. > >> > >> With that reference setup I was able to fix my Makefiles for the > >> staging/pvr implementation. > >> > >> I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the > >> LetuxOS kernel tree) > >> on the Pyra. > >> > >> In which areas does this tree go beyond the TI SDK/IMG DDK 1.14? > >> > >> * includes internal API fixes for kernels up to v5.3 > >> * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for > >> inclusion in linux-next > >> * has Kconfig and Makefiles for in-kernel configuration (no separate build > >> system) > >> * builds separate kernel modules for omap3430, omap3630, am335x, omap4, > >> omap5, dra7 etc. > >> pvrsrvkm > >> e.g. pvrsrvkm_omap_omap5_sgx544_116 > >> * the correct kernel module is automatically probed by matching > >> .compatible in device tree > >> so that the code is multi-platform friendly > >> * includes SoC integration for OMAP3/4/5 and has some preliminary bindings > >> documentation > >> * code base should also support JZ4780/CI20 and some Intel Atom processors > >> (CedarView, Poulsbo) > >> * has got a ToDo to describe what should be done during staging phase > >> > >> > >> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO > >> > >> My plans for the next steps are: > >> > >> * do more testing (e.g. X11, kmscube) > >> * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. > >> GTA04, OpenPandora) > >> * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline > >> kernels and I am > >> missing the user-space libraries for MIPS). > > > > That sounds good to me, just one comment. Before getting these into > > staging, I'd like to have omap variants use proper interconnect > > target module in devicetree like we already have in omap4.dtsi > > as target-module@5600. This should simplify things further > > as the module child device driver(s) can just enable things with > > runtime PM and we can leave out all the legacy hwmod platform data > > that sounds like you're still carrying. > > Yes, there is still a lot of SoC-glue included: > > > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-pvr-soc-glue > > It would indeed be a good move to simplify and reduce the glue code > and make it more maintainable / stable / identical on different platforms. OK yeah all that should just disappear :) > > I have patches here to add similar interconnect target modules for > > at least omap34xx, omap36xx, omap5, and am335x that I'll try to post > > later on today to play with. For am335x, things still depend on the > > recentely posted prm rstctrl patches. I'm not sure if I already > > did a dts patch for dra7 yet, need to check. > > I assume it is not yet in linux-next... So something for v5.5 or later. Well I just posted some sgx interconnect target module patches. We might still have them in v5.4 assuming people manage to review and test them. Regards, Tony
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
> Am 14.08.2019 um 11:47 schrieb Tony Lindgren : > > * H. Nikolaus Schaller [190814 08:57]: >> I also have pushed good news to >> >> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr >> >> Thanks to the help from the Pyra community, I was able to get a (binary) >> reference >> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1. >> >> With that reference setup I was able to fix my Makefiles for the staging/pvr >> implementation. >> >> I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the >> LetuxOS kernel tree) >> on the Pyra. >> >> In which areas does this tree go beyond the TI SDK/IMG DDK 1.14? >> >> * includes internal API fixes for kernels up to v5.3 >> * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for >> inclusion in linux-next >> * has Kconfig and Makefiles for in-kernel configuration (no separate build >> system) >> * builds separate kernel modules for omap3430, omap3630, am335x, omap4, >> omap5, dra7 etc. >> pvrsrvkm >> e.g. pvrsrvkm_omap_omap5_sgx544_116 >> * the correct kernel module is automatically probed by matching .compatible >> in device tree >> so that the code is multi-platform friendly >> * includes SoC integration for OMAP3/4/5 and has some preliminary bindings >> documentation >> * code base should also support JZ4780/CI20 and some Intel Atom processors >> (CedarView, Poulsbo) >> * has got a ToDo to describe what should be done during staging phase >> >> >> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO >> >> My plans for the next steps are: >> >> * do more testing (e.g. X11, kmscube) >> * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. >> GTA04, OpenPandora) >> * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline >> kernels and I am >> missing the user-space libraries for MIPS). > > That sounds good to me, just one comment. Before getting these into > staging, I'd like to have omap variants use proper interconnect > target module in devicetree like we already have in omap4.dtsi > as target-module@5600. This should simplify things further > as the module child device driver(s) can just enable things with > runtime PM and we can leave out all the legacy hwmod platform data > that sounds like you're still carrying. Yes, there is still a lot of SoC-glue included: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-pvr-soc-glue It would indeed be a good move to simplify and reduce the glue code and make it more maintainable / stable / identical on different platforms. > > I have patches here to add similar interconnect target modules for > at least omap34xx, omap36xx, omap5, and am335x that I'll try to post > later on today to play with. For am335x, things still depend on the > recentely posted prm rstctrl patches. I'm not sure if I already > did a dts patch for dra7 yet, need to check. I assume it is not yet in linux-next... So something for v5.5 or later. BR and thanks, Nikolaus
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
* H. Nikolaus Schaller [190814 08:57]: > I also have pushed good news to > > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr > > Thanks to the help from the Pyra community, I was able to get a (binary) > reference > implementation using DRM that works on Pyra/OMAP5. At least the gles1test1. > > With that reference setup I was able to fix my Makefiles for the staging/pvr > implementation. > > I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the > LetuxOS kernel tree) > on the Pyra. > > In which areas does this tree go beyond the TI SDK/IMG DDK 1.14? > > * includes internal API fixes for kernels up to v5.3 > * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for > inclusion in linux-next > * has Kconfig and Makefiles for in-kernel configuration (no separate build > system) > * builds separate kernel modules for omap3430, omap3630, am335x, omap4, > omap5, dra7 etc. > pvrsrvkm > e.g. pvrsrvkm_omap_omap5_sgx544_116 > * the correct kernel module is automatically probed by matching .compatible > in device tree > so that the code is multi-platform friendly > * includes SoC integration for OMAP3/4/5 and has some preliminary bindings > documentation > * code base should also support JZ4780/CI20 and some Intel Atom processors > (CedarView, Poulsbo) > * has got a ToDo to describe what should be done during staging phase > > > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO > > My plans for the next steps are: > > * do more testing (e.g. X11, kmscube) > * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, > OpenPandora) > * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline > kernels and I am > missing the user-space libraries for MIPS). That sounds good to me, just one comment. Before getting these into staging, I'd like to have omap variants use proper interconnect target module in devicetree like we already have in omap4.dtsi as target-module@5600. This should simplify things further as the module child device driver(s) can just enable things with runtime PM and we can leave out all the legacy hwmod platform data that sounds like you're still carrying. I have patches here to add similar interconnect target modules for at least omap34xx, omap36xx, omap5, and am335x that I'll try to post later on today to play with. For am335x, things still depend on the recentely posted prm rstctrl patches. I'm not sure if I already did a dts patch for dra7 yet, need to check. Regards, Tony
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
Hi all, > Am 17.07.2019 um 12:51 schrieb Merlijn Wajer : > > Hi, > > On 10/03/2019 08:07, H. Nikolaus Schaller wrote: >> >>> Am 10.03.2019 um 00:14 schrieb Merlijn Wajer : >>> >>> Hi, >>> >>> On 15/02/2019 14:09, H. Nikolaus Schaller wrote: >>> >> At least I can download and start firmware. I just have to find a way to >> fix the omaplfb so that it works >> with our omapdrm based panels to runs the CLipBlit test [1] on modern >> kernels... > > Maybe you can compare with what we have here: > https://github.com/maemo-leste/n9xx-linux/tree/pvr-wip-4.15.7/drivers/gpu/pvr I'll take a look into it especially how omaplfb is done. First observation is that there is a "flat" tree while I am working on a structured one... But that is just a marginal difference (mainly significant for Makefile writers). >>> >>> I've ported the Maemo Leste kernel + pvr to 5.0 and it seems to work: >>> https://github.com/maemo-leste/n9xx-linux/commits/pvr-wip-5.0.y >>> >>> Should I add this as maemo-leste-n900-5.0 branch (or something) to >>> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx ? >> >> Yes, that would be nice to be able to easily compare stuff. > > I've just pushed the Maemo Leste v5.1 branch + patches here: > > > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/n900/v5.1-patch > > This works on N900 with X, but it doesn't use DRM yet. I'm wondering > what a next logical step would be: to try and modules to load/probe on > another device (I have a droid4 or a Pandaboard ES rev B1), or to try > and get DRM PowerVR to work on the N900, with omapdrmfb and dri3wsegl. > > For either path, I'll probably need some help. Any updates from anyone > else? Maybe we should list things people can work - perhaps document > progress in github issues. (Mailing list is also fine, BTW) > > Cheers, > Merlijn > I also have pushed good news to https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr Thanks to the help from the Pyra community, I was able to get a (binary) reference implementation using DRM that works on Pyra/OMAP5. At least the gles1test1. With that reference setup I was able to fix my Makefiles for the staging/pvr implementation. I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree) on the Pyra. In which areas does this tree go beyond the TI SDK/IMG DDK 1.14? * includes internal API fixes for kernels up to v5.3 * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next * has Kconfig and Makefiles for in-kernel configuration (no separate build system) * builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc. pvrsrvkm e.g. pvrsrvkm_omap_omap5_sgx544_116 * the correct kernel module is automatically probed by matching .compatible in device tree so that the code is multi-platform friendly * includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation * code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo) * has got a ToDo to describe what should be done during staging phase https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO My plans for the next steps are: * do more testing (e.g. X11, kmscube) * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora) * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am missing the user-space libraries for MIPS). BR, Nikolaus
