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@xxxxxxx>
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
