Re: [U-Boot] [PATCH 0/2] ARM: tegra: enable GPU DT node

[Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

On 07/24/2015 10:07 PM, Peter Robinson wrote:
> Hi,
>
>>> Tegra124 requires the bootloader to perform VPR initialization, otherwise the
>>> GPU cannot be used by the system. Since using the GPU without that
>>> initialization results in a hang, the GPU DT node is left disabled, and it is
>>> the task of the bootloader to enable it after ensuring it is safe to use the
>>> GPU.
>>>
>>> VPR init is already performed since patch df3443dfa449, but the device tree was
>>> left untouched. This patch series performs this last step and prepares the GPU
>>> intialization code to receive more code for newer chips.
>>
>> Tested-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
>>
>> I've tested this patchset on v2015.07 with 4.2.0-rc3-00115-gc5dfd65 -
>> with these two patches I get a console login on HDMI again.
>>
>> However, I'm still having trouble with X11... Should that be working
>> with linux.git? (haven't tried linux-next.git yet)
>
> My understanding is that it's not or you need  to use glamour to do
> so, wayland in theory should work.
>
>> Among other errors, it seems that nouveau is looking for firmware
>> nouveau/nvea_fuc409c and nouveau/fuc409c - who should be providing that?
>> It's not in linux-firmware.git [1], and I see no /dev/mmcblk0p* to check
>> whether the original system has such a file (which I doubt, given the
>> nouveau naming). It then falls back to the tegra drm iiuc.
>
> Details of the changes with firmware loading in this patch series
> here, likely need the patches, or maybe newer ones for it to work:
> http://www.spinics.net/lists/dri-devel/msg84828.html
>
> Firmware landed upstream here:
> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=899ebcb6812681b91cf2dfd390574b478c612442
>
>> With -rc2 I've seen the system freeze, with -rc3 just not behaving as
>> expected when starting X (with ssh/serial remaining usable).
>
> Without the above patchset I've seen the lockups too.

Sorry for the delayed reply.

As Peter mentioned, the correct firmware files have landed in 
linux-firmware, and the loading code using the right paths is in 
Nouveau. It may not have landed in Linux mainline yet, so for the moment 
I recommend to use https://github.com/Gnurou/linux/tree/staging/nouveau 
(can probably be merged into any recent kernel tree) for the kernel and 
https://github.com/Gnurou/nouveau/tree/staging for Nouveau. This will 
require Nouveau to be loaded as a module.

As for X, there are two issues to be addressed:

1) The display and render functions are performed by two different DRI 
nodes, and two different drivers (tegradrm for display, nouveau for 
render). I suspect the fastest path towards X acceleration is to use the 
modesetting driver + GLamor. It may require some changes to handle the 
two different nodes. Modesetting without GLamor should just work, in any 
case. I really should have a look at this sometime but am hoping someone 
else will pick that low-hanging fruit. :)

2) Buffers generated by Nouveau use a tiling mode that tegradrm can 
understand, but it needs to be told about it through a dedicated IOCTL. 
Without this, buffers would need to be copied into linear buffers before 
sharing, which would be suboptimal. The kmscube repository linked by 
Mikko includes the code to do that.

Note that Nouveau's DDX can also somehow work with this patch:

http://comments.gmane.org/gmane.comp.freedesktop.xorg.nouveau/20101

However, I think modesetting + GLamor is the way to do, especially since 
the DDX solution cannot currently work with the Maxwell GPUs found in 
Tegra X1 (whereas GLamor should provide acceleration).

In any case, I would be very interested to hear about progress with 
getting X on Tegra K1. I don't think the effort required is too big.

Good luck!
Alex.