similar to: [PATCH] drm: Display Nouveau boot options at launch

For the purposes of the module parameters, specifies the permissions of the corresponding files in sysfs in predefined S_I* form rather than in octal notation. Withal it makes the source code more consistent. Moreover, because all parameters are readable to everyone, it is more user-friendly. $ grep S_IRUGO include/linux/stat.h #define S_IRUGO (S_IRUSR|S_IRGRP|S_IROTH) $ grep

From: poma <pomidorabelisima at gmail.com> Switch from "silly" S_* macros to "definitely more readable" octal "way" permissions, moreover to not "so restrictive" module parameters permissions. Suggested-by: Ilia Mirkin <imirkin at alum.mit.edu> Fixes: poma <pomidorabelisima at gmail.com> Tested-by: poma <pomidorabelisima at

I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng

noaccel=1 disables all acceleration and doesn't even attempt initialising PGRAPH+PFIFO, nofbaccel=1 only makes fbcon unaccelerated. Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nouveau_drv.c | 8 +++++++ drivers/gpu/drm/nouveau/nouveau_drv.h | 2 + drivers/gpu/drm/nouveau/nouveau_fbcon.c | 10 ++++++--

I found a bug in the nouveau kernel module. It looks like a cut and paste error on the definitions of some module parameters in nouveau_drv.c. The bug exhibits when displaying module parameter information with the modinfo utility. Here's a patch: diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c b/drivers/gpu/drm/nouveau/nouveau_drv.c index da3b93b..874adf5 100644 ---

On 20 May 2015 at 15:56, Alexandre Courbot <acourbot at nvidia.com> wrote: > Add a module option allowing to enable staging/unstable APIs. This will > allow us to experiment freely with experimental APIs for a while before > setting them in stone. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drm/nouveau/nouveau_drm.c | 18

Useful for simulating low-mem cards. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_drv.c | 4 ++++ drivers/gpu/drm/nouveau/nouveau_drv.h | 2 ++ drivers/gpu/drm/nouveau/nouveau_mem.c | 16 ++++++++++++++++ drivers/gpu/drm/nouveau/nv50_vram.c | 1 + drivers/gpu/drm/nouveau/nvc0_vram.c | 1 + 5 files changed, 24

On 21 May 2015 at 15:49, Alexandre Courbot <gnurou at gmail.com> wrote: > On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On 20 May 2015 at 15:56, Alexandre Courbot <acourbot at nvidia.com> wrote: >>> Add a module option allowing to enable staging/unstable APIs. This will >>> allow us to experiment freely with experimental

I made a little changes in this series: 1. merge the two last patches together 2. unify the private data interface with the drm debugfs one now it should be very obvious for a new dev on how to add new files to debugfs and how to get access to the nouveau structs Karol Herbst (5): debugfs: add infrastructure to add files with other fops than only read debugfs: rename functions to

I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng

Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau_drm.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drm/nouveau_drm.c b/drm/nouveau_drm.c index afb93bb..ffa1e4f 100644 --- a/drm/nouveau_drm.c +++ b/drm/nouveau_drm.c @@ -61,9 +61,10 @@ MODULE_PARM_DESC(debug, "debug string to pass to driver core"); static char

On 06/15/2015 04:09 PM, Alexandre Courbot wrote: > From: Ari Hirvonen <ahirvonen at nvidia.com> > > Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling > mode for imported dma-bufs. This ioctl is staging for now > and enabled with the "staging_tiling" module option. Adding Thierry to the conversation since he knows best about exported buffers and attributes.

On Mon, Jun 15, 2015 at 04:09:29PM +0900, Alexandre Courbot wrote: > From: Ari Hirvonen <ahirvonen at nvidia.com> > > Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling > mode for imported dma-bufs. This ioctl is staging for now > and enabled with the "staging_tiling" module option. > > Signed-off-by: Ari Hirvonen <ahirvonen at nvidia.com> >

Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a

Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a

While the GPU is guaranteed to be on when a hotplug has been received, the same assertion does not hold true if a connector probe has been started by userspace without having had received a sysfs event. So ensure that any connector probing keeps the GPU alive for the duration of the probe. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Karol Herbst <karolherbst at gmail.com> Cc:

This makes debugging with DP tracing a lot harder to interpret, so name each i2c based off the name of the encoder that it's for Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 12 ++++++++++--

From: Hans de Goede <hdegoede at redhat.com> [ Upstream commit 37a68eab4cd92b507c9e8afd760fdc18e4fecac6 ] Place the declaration of struct nouveau_conn_atom above that of struct nouveau_connector. This commit makes no changes to the moved block what so ever, it just moves it up a bit. This is a preparation patch to fix some issues with connector handling on pre nv50 displays (which do not

From: Hans de Goede <hdegoede at redhat.com> [ Upstream commit 37a68eab4cd92b507c9e8afd760fdc18e4fecac6 ] Place the declaration of struct nouveau_conn_atom above that of struct nouveau_connector. This commit makes no changes to the moved block what so ever, it just moves it up a bit. This is a preparation patch to fix some issues with connector handling on pre nv50 displays (which do not

From: Hans de Goede <hdegoede at redhat.com> [ Upstream commit 37a68eab4cd92b507c9e8afd760fdc18e4fecac6 ] Place the declaration of struct nouveau_conn_atom above that of struct nouveau_connector. This commit makes no changes to the moved block what so ever, it just moves it up a bit. This is a preparation patch to fix some issues with connector handling on pre nv50 displays (which do not