Nouveau - Sep 2014 - [5/5] ARM: tegra: jetson-tk1: enable GK20A GPU

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140925/907d4902/attachment.sig>

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.

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
-- 
Sjoerd Simons <sjoerd at luon.net>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140926/3813d982/attachment.sig>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140926/d408be81/attachment.sig>