| Message ID | 1400491450-19223-6-git-send-email-acourbot@nvidia.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
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>;
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
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
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
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
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
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
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
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>;
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> --- arch/arm/boot/dts/tegra124-jetson-tk1.dts | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)