similar to: [PATCH] drm/nouveau: Set DRIVER_ATOMIC cap earlier to fix debugfs

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

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

On Thu, Sep 13, 2018 at 11:02 PM, Lyude Paul <lyude at redhat.com> wrote: > Hm, one nitpick here. Since /sys/kernel/debug/dri/*/state creation depends on > the driver supporting atomic, maybe it would be good to make it so that we set > DRIVER_ATOMIC in the driver_stub structure, then disable it per-device depending > on the nouveau_atomic setting + hw support. That way we can

From: Ville Syrjälä <ville.syrjala at linux.intel.com> We now have per-device driver_features, so let's use that to disable atomic only for pre-nv50. Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: nouveau at lists.freedesktop.org Cc: Daniel Vetter <daniel.vetter at ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>

Hm, one nitpick here. Since /sys/kernel/debug/dri/*/state creation depends on the driver supporting atomic, maybe it would be good to make it so that we set DRIVER_ATOMIC in the driver_stub structure, then disable it per-device depending on the nouveau_atomic setting + hw support. That way we can always have the state debugfs file while maintaining nouveau's current behavior with exposing

Please find below an automated bisection report for a kernel Oops seen during the initialisation of the nouveau GPU driver on jetson-tk1. All the LAVA test jobs for this bisection can be found here: http://lava.baylibre.com:10080/scheduler/alljobs?length=25&search=lava-bisect-staging-7366#table Here's the beginning of the Oops stack trace: [ 7.485361] [00000064] *pgd=f9e7b835 [

Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too

Hi Daniel. On Fri, Oct 23, 2020 at 06:04:44PM +0200, Daniel Vetter wrote: > Only the following drivers aren't converted: > - amdgpu, because of the driver_feature mangling due to virt support > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > platforms where it's supported (i.e. again driver_feature mangling) > - vc4, again because of driver_feature

uhhhhhhhhhhhhh didn't we fix this weeks ago? with "drm/nouveau: tegra: Call nouveau_drm_device_init()" On Fri, 2018-12-07 at 23:31 +0000, Guillaume Tucker wrote: > Please find below an automated bisection report for a kernel Oops > seen during the initialisation of the nouveau GPU driver on > jetson-tk1. > > > All the LAVA test jobs for this bisection can be

Split out to make the functional changes stick out more. v2: amdgpu gained DRIVER_SYNCOBJ_TIMELINE. v3: amdgpu lost DRIVER_SYNCOBJ_TIMELINE. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: amd-gfx at lists.freedesktop.org Cc: etnaviv at lists.freedesktop.org Cc: freedreno at lists.freedesktop.org Cc: intel-gfx at lists.freedesktop.org Cc: lima at lists.freedesktop.org Cc:

Split out to make the functional changes stick out more. v2: amdgpu gained DRIVER_SYNCOBJ_TIMELINE. v3: amdgpu lost DRIVER_SYNCOBJ_TIMELINE. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: amd-gfx at lists.freedesktop.org Cc: etnaviv at lists.freedesktop.org Cc: freedreno at lists.freedesktop.org Cc: intel-gfx at lists.freedesktop.org Cc: lima at lists.freedesktop.org Cc:

Split out to make the functional changes stick out more. v2: amdgpu gained DRIVER_SYNCOBJ_TIMELINE. v3: amdgpu lost DRIVER_SYNCOBJ_TIMELINE. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: amd-gfx at lists.freedesktop.org Cc: etnaviv at lists.freedesktop.org Cc: freedreno at lists.freedesktop.org Cc: intel-gfx at lists.freedesktop.org Cc: lima at lists.freedesktop.org Cc:

On 08/12/2018 00:08, Lyude Paul wrote: > uhhhhhhhhhhhhh > didn't we fix this weeks ago? with "drm/nouveau: tegra: Call > nouveau_drm_device_init()" Yes here's the fix from Thierry: https://patchwork.freedesktop.org/patch/263587/ and I can confirm that it does fix the Oops when applied on top of next-20181206 (what I used for the bisection last week):

Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too

Conversion to atomic modesetting, final step. Set the DRIVER_ATOMIC flag. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/bochs/bochs_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bochs/bochs_drv.c b/drivers/gpu/drm/bochs/bochs_drv.c index f3dd66ae99..278f9d2e7f 100644 --- a/drivers/gpu/drm/bochs/bochs_drv.c +++

Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too

Hi Am 23.10.20 um 14:28 schrieb Daniel Vetter: > Only the following drivers aren't converted: > - amdgpu, because of the driver_feature mangling due to virt support > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > platforms where it's supported (i.e. again driver_feature mangling) > - vc4, again because of driver_feature mangling > - qxl,

Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support. Subsequent patch will address this. - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else

drm_*_reference() and drm_*_unreference() functions are just compatibility alias for drm_*_get() and drm_*_put() adn should not be used by new code. So convert all users of compatibility functions to use the new APIs. Signed-off-by: Cihangir Akturk <cakturk at gmail.com> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-

Looks good to me! Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> On 8/3/17 1:58 PM, Cihangir Akturk wrote: > drm_*_reference() and drm_*_unreference() functions are just > compatibility alias for drm_*_get() and drm_*_put() adn should not be > used by new code. So convert all users of compatibility functions to use > the new APIs. > >