search for: tegradrm

...we'd be eager to hear it. I don't want it rushed in, but we do have several projects blocked on getting that approved & committed. I assume the sequencing should be: * Fix the minor issue you identified here/complete review of nouveau kernel patches * Complete review of the related TegraDRM new modifier support patch * Finalize and complete review of userspace/Mesa nouveau modifier support patches * Get drm_fourcc.h updates committed * Get these patches and TegraDRM patches committed * Integrate final drm_fourcc.h to Mesa patches and get Mesa patches committed Does that sound right...

...ied 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 reasona...

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 at nvidia.com> > --- > arch/arm/boot/dts/tegra124-jetson-tk1.dts | 8 +++++++- >

...I don't want it rushed in, but > we do have several projects blocked on getting that approved & committed. > > I assume the sequencing should be: > > * Fix the minor issue you identified here/complete review of nouveau > kernel patches > * Complete review of the related TegraDRM new modifier support patch > * Finalize and complete review of userspace/Mesa nouveau modifier > support patches > * Get drm_fourcc.h updates committed > * Get these patches and TegraDRM patches committed > * Integrate final drm_fourcc.h to Mesa patches and get Mesa patches > comm...

...icely almost as-is, minus the fact that the display hardware is not handled by Nouveau and we only support render nodes (I have yet to look at what the state of render nodes in Mesa is). For X, Thierry is IIUC working on the display driver, and at some point these efforts should join to connect tegradrm and Nouveau using PRIME. We are not quite there yet, and since we are working with limited resources it will likely require some time, but the fact we could bring up a (seemingly) working Nouveau kernel driver with so little code is encouraging. Thanks, Alex.

...e he knows best about exported buffers and attributes. I wonder if this would not better be done at the time the buffer gets imported. It seems to me that this would be a more appropriate way than having an ioctl dedicated to this. Thierry, would you have any input based on your experience with tegradrm? In the end, it seems like you have settled for a similar ioctl to set the tiling mode of displayed buffers. > > Signed-off-by: Ari Hirvonen <ahirvonen at nvidia.com> > [acourbot at nvidia.com: carry upstream, many fixes] > Signed-off-by: Alexandre Courbot <acourbot at nvidi...

Hi [..snip..] > Finally, support for probing GK20A is added in the last 2 patches. It should be > noted that contrary to what Nouveau currently expects, GK20A does not embed any > display hardware (that part being handled by tegradrm). So this driver should > really be only used through DRM render-nodes and collaborate with the display > driver using PRIME. I have not yet figured out how to turn GK20A's instantiation > of Nouveau into a render-node only driver without breaking support for existing > desktop GPUs...

...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 at nvidia.com> >...

...y 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 n...

...hes 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). Assum...

...nd > definitely not the nexus/android lead platforms. > > Display side would be easier since there's a bunch of kms drivers now > upstream. But given that google decided to go ahead with their own adf > instead of drm-kms that's also a non-starter. Hmm.. Maybe we could use TegraDRM on the display side.. That and Nouveau would already be two upstream drivers that support explicit sync on Tegra K1. Also, if we bring sync fd's out of staging, one idea would be to add support for EGL_ANDROID_native_fence_sync in mesa, along with some tests. That would demonstrate convertin...

Riley (CCed) and I will be at Plumbers in a couple weeks. There is a session on sync planned in the Android track, and of course we'll be available to chat. On Thu, Oct 2, 2014 at 1:44 PM, Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Oct 02, 2014 at 05:59:51PM +0300, Lauri Peltonen wrote: > > +Rom who seems to be presenting about mainlining android sync at linux >

I hope this is a good mailing list for this problem. I have a Jetson TK1 board and I am trying to get the nouveau drivers running on it without success. I am using the following: Nouveau linux kernel 4.8.0-rc4+ Nouveau DRM git master xf86-video-nouveau git master Gnurou xserver git branch GK20A My base system is Debian. When I try to start X I get: X: drmmode_display.c:783:

...few things usually done by the video BIOS (which Tegra does not feature). > > Finally, support for probing GK20A is added in the last 2 patches. It should be > noted that contrary to what Nouveau currently expects, GK20A does not embed any > display hardware (that part being handled by tegradrm). So this driver should > really be only used through DRM render-nodes and collaborate with the display > driver using PRIME. I have not yet figured out how to turn GK20A's instantiation > of Nouveau into a render-node only driver without breaking support for existing > desktop GPUs...

This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace are available here: https://gitlab.freedesktop.org/cubanismo/mesa/tree/nouveau_work But those need a bit of cleanup before they're ready to submit. I've tested this on Tesla, Kepler, Pascal,

...ell as to perform a few things usually done by the video BIOS (which Tegra does not feature). Finally, support for probing GK20A is added in the last 2 patches. It should be noted that contrary to what Nouveau currently expects, GK20A does not embed any display hardware (that part being handled by tegradrm). So this driver should really be only used through DRM render-nodes and collaborate with the display driver using PRIME. I have not yet figured out how to turn GK20A?s instantiation of Nouveau into a render-node only driver without breaking support for existing desktop GPUs, and consequently the d...

...urcc_XXX constants like the broadcom modifiers do? I wasn't sure which style was preferred. The nouveau code is full of magic numbers, but that's a bit lower level than this file. If preferred, I can send this out as part of a patchset that adds support for the modifiers to nouveau and TegraDRM, but I have some things to clean up there before it's ready for proper review, and I didn't want to block review of the basic modifier layout on that work.

Second version of this patchset addressing Ben's comments and fixing a few extra things. This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates the use of this staging option with the SET_TILING ioctl, which can be used to