[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180512194541.GZ28661@phenom.ffwll.local>
Date: Sat, 12 May 2018 21:45:41 +0200
From: Daniel Vetter <daniel@...ll.ch>
To: Eric Anholt <eric@...olt.net>
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
Daniel Vetter <daniel.vetter@...ll.ch>,
Sean Paul <seanpaul@...omium.org>
Subject: Re: [PATCH] drm: Fix render node numbering regression from control
node removal.
On Tue, May 08, 2018 at 05:14:25PM -0700, Eric Anholt wrote:
> drm_minor_alloc() does multiplication on this enum, so the removal
> ended up moving render nodes down from 128 base to 64. This caused
> Mesa's surfaceless backend to be unable to open the render nodes,
> since it was still looking up at 128.
>
> Signed-off-by: Eric Anholt <eric@...olt.net>
> Fixes: 0d49f303e8a7 ("drm: remove all control node code")
> Cc: Daniel Vetter <daniel.vetter@...ll.ch>
> Cc: Sean Paul <seanpaul@...omium.org>
Oops.
> ---
> include/drm/drm_file.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 99ab50cbab00..69b0a8b57502 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -49,6 +49,7 @@ struct device;
>
> enum drm_minor_type {
> DRM_MINOR_PRIMARY,
> + DRM_MINOR_CONTROL,
Maybe add a comment here why we need this? Either way:
Reviewed-by: Daniel Vetter <daniel.vetter@...ll.ch>
> DRM_MINOR_RENDER,
> };
>
> --
> 2.17.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Powered by blists - more mailing lists