All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Lyude Paul <lyude@redhat.com>
Cc: David Airlie <airlied@linux.ie>,
	nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, bskeggs@redhat.com,
	stable@vger.kernel.org
Subject: Re: [PATCH] drm/nouveau: Set DRIVER_ATOMIC cap earlier to fix debugfs
Date: Thu, 26 Jul 2018 17:12:02 +0200	[thread overview]
Message-ID: <20180726151202.GE27305@kroah.com> (raw)
In-Reply-To: <20180723171322.9677-1-lyude@redhat.com>

On Mon, Jul 23, 2018 at 01:13:20PM -0400, Lyude Paul wrote:
> commit eb493fbc150f4a28151ae1ee84f24395989f3600 upstream
> 
> Currently nouveau doesn't actually expose the state debugfs file that's
> usually provided for any modesetting driver that supports atomic, even
> if nouveau is loaded with atomic=1. This is due to the fact that the
> standard debugfs files that DRM creates for atomic drivers is called
> when drm_get_pci_dev() is called from nouveau_drm.c. This happens well
> before we've initialized the display core, which is currently
> responsible for setting the DRIVER_ATOMIC cap.
> 
> So, move the atomic option into nouveau_drm.c and just add the
> DRIVER_ATOMIC cap whenever it's enabled on the kernel commandline. This
> shouldn't cause any actual issues, as the atomic ioctl will still fail
> as expected even if the display core doesn't disable it until later in
> the init sequence. This also provides the added benefit of being able to
> use the state debugfs file to check the current display state even if
> clients aren't allowed to modify it through anything other than the
> legacy ioctls.
> 
> Additionally, disable the DRIVER_ATOMIC cap in nv04's display core, as
> this was already disabled there previously.
> 
> Signed-off-by: Lyude Paul <lyude@redhat.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
> ---
>  drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 +++
>  drivers/gpu/drm/nouveau/nouveau_drm.c   | 7 +++++++
>  drivers/gpu/drm/nouveau/nv50_display.c  | 6 ------
>  3 files changed, 10 insertions(+), 6 deletions(-)

Please give me a hint as to what kernel versions you want the patches to
be applied to, otherwise I just have to guess :)

thanks,

greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Lyude Paul <lyude@redhat.com>
Cc: bskeggs@redhat.com, stable@vger.kernel.org,
	David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/nouveau: Set DRIVER_ATOMIC cap earlier to fix debugfs
Date: Thu, 26 Jul 2018 17:12:02 +0200	[thread overview]
Message-ID: <20180726151202.GE27305@kroah.com> (raw)
In-Reply-To: <20180723171322.9677-1-lyude@redhat.com>

On Mon, Jul 23, 2018 at 01:13:20PM -0400, Lyude Paul wrote:
> commit eb493fbc150f4a28151ae1ee84f24395989f3600 upstream
> 
> Currently nouveau doesn't actually expose the state debugfs file that's
> usually provided for any modesetting driver that supports atomic, even
> if nouveau is loaded with atomic=1. This is due to the fact that the
> standard debugfs files that DRM creates for atomic drivers is called
> when drm_get_pci_dev() is called from nouveau_drm.c. This happens well
> before we've initialized the display core, which is currently
> responsible for setting the DRIVER_ATOMIC cap.
> 
> So, move the atomic option into nouveau_drm.c and just add the
> DRIVER_ATOMIC cap whenever it's enabled on the kernel commandline. This
> shouldn't cause any actual issues, as the atomic ioctl will still fail
> as expected even if the display core doesn't disable it until later in
> the init sequence. This also provides the added benefit of being able to
> use the state debugfs file to check the current display state even if
> clients aren't allowed to modify it through anything other than the
> legacy ioctls.
> 
> Additionally, disable the DRIVER_ATOMIC cap in nv04's display core, as
> this was already disabled there previously.
> 
> Signed-off-by: Lyude Paul <lyude@redhat.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
> ---
>  drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 +++
>  drivers/gpu/drm/nouveau/nouveau_drm.c   | 7 +++++++
>  drivers/gpu/drm/nouveau/nv50_display.c  | 6 ------
>  3 files changed, 10 insertions(+), 6 deletions(-)

Please give me a hint as to what kernel versions you want the patches to
be applied to, otherwise I just have to guess :)

thanks,

greg k-h

  reply	other threads:[~2018-07-26 15:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-22 16:38 FAILED: patch "[PATCH] drm/nouveau: Set DRIVER_ATOMIC cap earlier to fix debugfs" failed to apply to 4.17-stable tree gregkh
2018-07-23 17:13 ` [PATCH] drm/nouveau: Set DRIVER_ATOMIC cap earlier to fix debugfs Lyude Paul
2018-07-26 15:12   ` Greg KH [this message]
2018-07-26 15:12     ` Greg KH
2018-07-26 15:48     ` Lyude Paul
  -- strict thread matches above, loose matches on Subject: below --
2018-07-03 20:31 Lyude Paul
2018-07-03 20:31 ` Lyude Paul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180726151202.GE27305@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=airlied@linux.ie \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.