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

From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Tero Kristo <t-kristo@ti.com>
Cc: "Tony Lindgren" <tony@atomide.com>,
	"Merlijn Wajer" <merlijn@wizzup.org>,
	"Adam Ford" <aford173@gmail.com>,
	"Philipp Rossak" <embed3d@gmail.com>,
	"Paweł Chmiel" <pawel.mikolaj.chmiel@gmail.com>,
	"Tomi Valkeinen" <tomi.valkeinen@ti.com>,
	"Filip Matijević" <filip.matijevic.pz@gmail.com>,
	"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
	"moaz korena" <moaz@korena.xyz>,
	"James Hilliard" <james.hilliard1@gmail.com>,
	kernel@pyra-handheld.com,
	"Discussions about the Letux Kernel"
	<letux-kernel@openphoenux.org>,
	maemo-leste@lists.dyne.org,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>
Subject: Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
Date: Tue, 8 Oct 2019 22:15:57 +0200	[thread overview]
Message-ID: <0FEF1AB1-5FE0-4EEE-BEB9-0957BB424C18@goldelico.com> (raw)
In-Reply-To: <0bb4739d-e26f-de49-fd80-257a836e892a@ti.com>

> Am 08.10.2019 um 10:00 schrieb Tero Kristo <t-kristo@ti.com>:
> 
> On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
>> Hi Tero,
>>> Am 07.10.2019 um 21:18 schrieb Tero Kristo <t-kristo@ti.com>:
>>> 
>>> On 07/10/2019 18:52, Tony Lindgren wrote:
>>>> Hi,
>>>> * H. Nikolaus Schaller <hns@goldelico.com> [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:0000: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 = 0x40000000
>> # echo auto > $(find /sys -name control | grep \/5600)
>> # rwmem 0x5600fe10
>> # rwmem 0x56000024
>> 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