Patchwork [5/5] ARM: tegra: jetson-tk1: enable GK20A GPU

login
register
mail settings
Submitter Alexandre Courbot
Date May 19, 2014, 9:24 a.m.
Message ID <1400491450-19223-6-git-send-email-acourbot@nvidia.com>
Download mbox | patch
Permalink /patch/350164/
State Superseded, archived
Headers show

Comments

Alexandre Courbot - May 19, 2014, 9:24 a.m.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
Sjoerd Simons - Sept. 25, 2014, 1:27 p.m.
Playing a bit with todays linux-next on my jetson, it seems this patch is
still required for enabling the GPU. Is there anything blocking it (firmware
not available yet in liux-firmware?)

On Mon, May 19, 2014 at 06:24:10PM +0900, Alexandre Courbot wrote:
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
>  arch/arm/boot/dts/tegra124-jetson-tk1.dts | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
> index e31fb61a81d3..15a194d1277f 100644
> --- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
> +++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
> @@ -30,6 +30,12 @@
>  		};
>  	};
>  
> +	gpu@0,57000000 {
> +		status = "okay";
> +
> +		vdd-supply = <&vdd_gpu>;
> +	};
> +
>  	pinmux: pinmux@0,70000868 {
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&state_default>;
> @@ -1505,7 +1511,7 @@
>  					regulator-always-on;
>  				};
>  
> -				sd6 {
> +				vdd_gpu: sd6 {
>  					regulator-name = "+VDD_GPU_AP";
>  					regulator-min-microvolt = <650000>;
>  					regulator-max-microvolt = <1200000>;
Stephen Warren - Sept. 25, 2014, 3:48 p.m.
On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> Playing a bit with todays linux-next on my jetson, it seems this patch is
> still required for enabling the GPU. Is there anything blocking it (firmware
> not available yet in liux-firmware?)

I think initially I was waiting for the DRM patch "drm/nouvea: support 
for probing platform devices" to be applied, but it looks like that's 
been applied already, so only patches 4 and 5 in this series are still 
outstanding.

Alex, wasn't there also some issue where the VPR register had to be 
programmed, and if it wasn't there'd be a hang when the GPU registers 
were touched? If we've added code to Nouveau/tegradrm to detect that and 
avoid the problem, then I guess we can commit these last two patches for 
3.19. A resend after the 3.18 merge window might help.

> On Mon, May 19, 2014 at 06:24:10PM +0900, Alexandre Courbot wrote:
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>>   arch/arm/boot/dts/tegra124-jetson-tk1.dts | 8 +++++++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
>> index e31fb61a81d3..15a194d1277f 100644
>> --- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
>> +++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
>> @@ -30,6 +30,12 @@
>>   		};
>>   	};
>>
>> +	gpu@0,57000000 {
>> +		status = "okay";
>> +
>> +		vdd-supply = <&vdd_gpu>;
>> +	};
>> +
>>   	pinmux: pinmux@0,70000868 {
>>   		pinctrl-names = "default";
>>   		pinctrl-0 = <&state_default>;
>> @@ -1505,7 +1511,7 @@
>>   					regulator-always-on;
>>   				};
>>
>> -				sd6 {
>> +				vdd_gpu: sd6 {
>>   					regulator-name = "+VDD_GPU_AP";
>>   					regulator-min-microvolt = <650000>;
>>   					regulator-max-microvolt = <1200000>;
>

--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Thierry Reding - Sept. 25, 2014, 4:41 p.m.
On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
> On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> >Playing a bit with todays linux-next on my jetson, it seems this patch is
> >still required for enabling the GPU. Is there anything blocking it (firmware
> >not available yet in liux-firmware?)
> 
> I think initially I was waiting for the DRM patch "drm/nouvea: support for
> probing platform devices" to be applied, but it looks like that's been
> applied already, so only patches 4 and 5 in this series are still
> outstanding.
> 
> Alex, wasn't there also some issue where the VPR register had to be
> programmed, and if it wasn't there'd be a hang when the GPU registers were
> touched? If we've added code to Nouveau/tegradrm to detect that and avoid
> the problem, then I guess we can commit these last two patches for 3.19. A
> resend after the 3.18 merge window might help.

A patch that programs VPR was merged into U-Boot (though I don't think
it's made it into master yet). I'm not sure we can reasonably check for
that in Nouveau, given that the register is somewhere completely
unrelated. In fact I think the U-Boot patch was triggered by some
discussion about how to solve this and it was decided that it shouldn't
be done in the kernel, but U-Boot should set it up.

That said, perhaps one solution would be to make U-Boot enable the gk20a
device if it's set up the VPR and disable it otherwise?

Thierry
Stephen Warren - Sept. 25, 2014, 6:07 p.m.
On 09/25/2014 10:41 AM, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
>> On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
>>> Playing a bit with todays linux-next on my jetson, it seems this patch is
>>> still required for enabling the GPU. Is there anything blocking it (firmware
>>> not available yet in liux-firmware?)
>>
>> I think initially I was waiting for the DRM patch "drm/nouvea: support for
>> probing platform devices" to be applied, but it looks like that's been
>> applied already, so only patches 4 and 5 in this series are still
>> outstanding.
>>
>> Alex, wasn't there also some issue where the VPR register had to be
>> programmed, and if it wasn't there'd be a hang when the GPU registers were
>> touched? If we've added code to Nouveau/tegradrm to detect that and avoid
>> the problem, then I guess we can commit these last two patches for 3.19. A
>> resend after the 3.18 merge window might help.
>
> A patch that programs VPR was merged into U-Boot (though I don't think
> it's made it into master yet). I'm not sure we can reasonably check for
> that in Nouveau, given that the register is somewhere completely
> unrelated. In fact I think the U-Boot patch was triggered by some
> discussion about how to solve this and it was decided that it shouldn't
> be done in the kernel, but U-Boot should set it up.
>
> That said, perhaps one solution would be to make U-Boot enable the gk20a
> device if it's set up the VPR and disable it otherwise?

For that to work, we'd need the DT to say status="disabled" by default 
for the GPU, and for the fixed U-Boot (and indeed every other 
bootloader...) to enable the GPU node. This would allow people with old 
versions of U-Boot (or other bootloaders) to continue to boot. This 
means bootloaders would only have to set status="okay", but never have 
to set status="disabled", which at least simplifies them a tiny bit.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sjoerd Simons - Sept. 25, 2014, 6:10 p.m.
On Thu, 2014-09-25 at 18:41 +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
> > On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> > >Playing a bit with todays linux-next on my jetson, it seems this patch is
> > >still required for enabling the GPU. Is there anything blocking it (firmware
> > >not available yet in liux-firmware?)
> > 
> > I think initially I was waiting for the DRM patch "drm/nouvea: support for
> > probing platform devices" to be applied, but it looks like that's been
> > applied already, so only patches 4 and 5 in this series are still
> > outstanding.
> > 
> > Alex, wasn't there also some issue where the VPR register had to be
> > programmed, and if it wasn't there'd be a hang when the GPU registers were
> > touched? If we've added code to Nouveau/tegradrm to detect that and avoid
> > the problem, then I guess we can commit these last two patches for 3.19. A
> > resend after the 3.18 merge window might help.
> 
> A patch that programs VPR was merged into U-Boot (though I don't think
> it's made it into master yet).

Assuming you're talking about "ARM: tegra: Disable VPR",that has landed
in u-boot master and released as part of v2014.10-rc2 [0]

>  I'm not sure we can reasonably check for
> that in Nouveau, given that the register is somewhere completely
> unrelated. In fact I think the U-Boot patch was triggered by some
> discussion about how to solve this and it was decided that it shouldn't
> be done in the kernel, but U-Boot should set it up.
> 
> That said, perhaps one solution would be to make U-Boot enable the gk20a
> device if it's set up the VPR and disable it otherwise?

I guess in that case the vdd-supply should still be added to the dts
with u-boot toggling the status field of the node?


0: http://git.denx.de/?p=u-boot.git;a=commit;h=df3443dfa449ad02bef8ddf6e2c90a6fd9394fc9
Alexandre Courbot - Sept. 26, 2014, 4:44 a.m.
On 09/26/2014 12:48 AM, Stephen Warren wrote:
> On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
>> Playing a bit with todays linux-next on my jetson, it seems this patch is
>> still required for enabling the GPU. Is there anything blocking it
>> (firmware
>> not available yet in liux-firmware?)
>
> I think initially I was waiting for the DRM patch "drm/nouvea: support
> for probing platform devices" to be applied, but it looks like that's
> been applied already, so only patches 4 and 5 in this series are still
> outstanding.

Actually I am waiting for the firmware and firmware loading support 
patch to land in linux-firmware and Nouveau respectively. I have yet to 
send these patches publicly due to some ongoing discussion about the 
firmware's license.

For now if you want to run Nouveau on TK1, the easiest solution is to 
use my kernel and Nouveau branches. The branches that should be used are 
visible in the manifest of 
https://github.com/Gnurou/tegra-nouveau-rootfs - which BTW also provides 
an easy way to enable the FOSS graphics stack on a L4T image (minus the 
firmware at the moment).

More generally speaking, I still have a lot of patches to upstream - I 
apologize for not having been able to catch up with them. Things have 
been busy on other fronts, but since these other fronts are soon not 
going to be a concern anymore I will be able to focus on Nouveau again 
after mid-next week. :)

>
> Alex, wasn't there also some issue where the VPR register had to be
> programmed, and if it wasn't there'd be a hang when the GPU registers
> were touched? If we've added code to Nouveau/tegradrm to detect that and
> avoid the problem, then I guess we can commit these last two patches for
> 3.19. A resend after the 3.18 merge window might help.

The VPR patch has landed in U-boot mainline, so this should be less of a 
problem now. AFAIK there is no safe way to check whether VPR has been 
disabled, but the solution might be in your suggestion to make the 
bootloader enable the GPU DT node if it finds it safe to do so.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Thierry Reding - Sept. 26, 2014, 9:59 a.m.
On Thu, Sep 25, 2014 at 12:07:01PM -0600, Stephen Warren wrote:
> On 09/25/2014 10:41 AM, Thierry Reding wrote:
> >On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
> >>On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> >>>Playing a bit with todays linux-next on my jetson, it seems this patch is
> >>>still required for enabling the GPU. Is there anything blocking it (firmware
> >>>not available yet in liux-firmware?)
> >>
> >>I think initially I was waiting for the DRM patch "drm/nouvea: support for
> >>probing platform devices" to be applied, but it looks like that's been
> >>applied already, so only patches 4 and 5 in this series are still
> >>outstanding.
> >>
> >>Alex, wasn't there also some issue where the VPR register had to be
> >>programmed, and if it wasn't there'd be a hang when the GPU registers were
> >>touched? If we've added code to Nouveau/tegradrm to detect that and avoid
> >>the problem, then I guess we can commit these last two patches for 3.19. A
> >>resend after the 3.18 merge window might help.
> >
> >A patch that programs VPR was merged into U-Boot (though I don't think
> >it's made it into master yet). I'm not sure we can reasonably check for
> >that in Nouveau, given that the register is somewhere completely
> >unrelated. In fact I think the U-Boot patch was triggered by some
> >discussion about how to solve this and it was decided that it shouldn't
> >be done in the kernel, but U-Boot should set it up.
> >
> >That said, perhaps one solution would be to make U-Boot enable the gk20a
> >device if it's set up the VPR and disable it otherwise?
> 
> For that to work, we'd need the DT to say status="disabled" by default for
> the GPU, and for the fixed U-Boot (and indeed every other bootloader...) to
> enable the GPU node. This would allow people with old versions of U-Boot (or
> other bootloaders) to continue to boot. This means bootloaders would only
> have to set status="okay", but never have to set status="disabled", which at
> least simplifies them a tiny bit.

Sounds like a reasonable requirement on bootloaders to me. If it's clear
that the device will not work without an initialized VPR region, part of
the "boot protocol" should be for the bootloader to tell the kernel when
it's safe to enable the GPU.

Thierry
Thierry Reding - Sept. 26, 2014, 10:01 a.m.
On Thu, Sep 25, 2014 at 08:10:31PM +0200, Sjoerd Simons wrote:
> On Thu, 2014-09-25 at 18:41 +0200, Thierry Reding wrote:
> > On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
> > > On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> > > >Playing a bit with todays linux-next on my jetson, it seems this patch is
> > > >still required for enabling the GPU. Is there anything blocking it (firmware
> > > >not available yet in liux-firmware?)
> > > 
> > > I think initially I was waiting for the DRM patch "drm/nouvea: support for
> > > probing platform devices" to be applied, but it looks like that's been
> > > applied already, so only patches 4 and 5 in this series are still
> > > outstanding.
> > > 
> > > Alex, wasn't there also some issue where the VPR register had to be
> > > programmed, and if it wasn't there'd be a hang when the GPU registers were
> > > touched? If we've added code to Nouveau/tegradrm to detect that and avoid
> > > the problem, then I guess we can commit these last two patches for 3.19. A
> > > resend after the 3.18 merge window might help.
> > 
> > A patch that programs VPR was merged into U-Boot (though I don't think
> > it's made it into master yet).
> 
> Assuming you're talking about "ARM: tegra: Disable VPR",that has landed
> in u-boot master and released as part of v2014.10-rc2 [0]

Oh, good.

> >  I'm not sure we can reasonably check for
> > that in Nouveau, given that the register is somewhere completely
> > unrelated. In fact I think the U-Boot patch was triggered by some
> > discussion about how to solve this and it was decided that it shouldn't
> > be done in the kernel, but U-Boot should set it up.
> > 
> > That said, perhaps one solution would be to make U-Boot enable the gk20a
> > device if it's set up the VPR and disable it otherwise?
> 
> I guess in that case the vdd-supply should still be added to the dts
> with u-boot toggling the status field of the node?

Yes, if that's what we decide on then this patch should be modified to
remove the status = "okay" line.

Thierry

Patch

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index e31fb61a81d3..15a194d1277f 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -30,6 +30,12 @@ 
 		};
 	};
 
+	gpu@0,57000000 {
+		status = "okay";
+
+		vdd-supply = <&vdd_gpu>;
+	};
+
 	pinmux: pinmux@0,70000868 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&state_default>;
@@ -1505,7 +1511,7 @@ 
 					regulator-always-on;
 				};
 
-				sd6 {
+				vdd_gpu: sd6 {
 					regulator-name = "+VDD_GPU_AP";
 					regulator-min-microvolt = <650000>;
 					regulator-max-microvolt = <1200000>;