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

[Tony Lindgren]

* Tero Kristo <t-kristo@xxxxxx> [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 <t-kristo@xxxxxx>:
> > > 
> > > On 07/10/2019 18:52, Tony Lindgren wrote:
> > > > Hi,
> > > > * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [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.

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 <t-kristo@xxxxxx>
> 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 <t-kristo@xxxxxx>
> ---
>  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
>