Re: [Nouveau] [RESEND PATCH 2/5] drm: Move nomodeset kernel parameter handler to the DRM subsystem

Hi Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas: The "nomodeset" kernel cmdline parameter is handled by the vgacon driver but the exported vgacon_text_force() symbol is only used by DRM drivers. It makes much more sense for the parameter logic to be in the subsystem of the drivers

Re: [Nouveau] [RESEND PATCH 2/5] drm: Move nomodeset kernel parameter handler to the DRM subsystem

On Wed, 03 Nov 2021, Javier Martinez Canillas wrote: > The "nomodeset" kernel cmdline parameter is handled by the vgacon driver > but the exported vgacon_text_force() symbol is only used by DRM drivers. > > It makes much more sense for the parameter logic to be in the subsystem > of the drivers

Re: [Nouveau] [RESEND PATCH 3/5] drm: Rename vgacon_text_force() function to drm_modeset_disabled()

Hi Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas: This function is used by some DRM drivers to determine if the "nomodeset" kernel command line parameter was set and prevent these drivers to probe. But the function name is quite confusing and does not reflect what really the drivers

Re: [Nouveau] [RESEND PATCH 0/5] Cleanups for the nomodeset kernel command line parameter logic

Hi Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas: [ resend with all relevant people as Cc now, sorry to others for the spam ] There is a lot of historical baggage on this parameter. It's defined in the vgacon driver as a "nomodeset" parameter, but it's handler function is called

Re: [Nouveau] [PATCH 5.10 32/77] drm/ttm: fix memleak in ttm_transfered_destroy

On 2021-11-01 10:17 +0100, Greg Kroah-Hartman wrote: > From: Christian König > > commit 0db55f9a1bafbe3dac750ea669de9134922389b5 upstream. > > We need to cleanup the fences for ghost objects as well. > > Signed-off-by: Christian König > Reported-by: Erhard F. > Tested-by: Erhard F. >

Re: [Nouveau] [PATCH 5.10 32/77] drm/ttm: fix memleak in ttm_transfered_destroy

On Wed, Nov 3, 2021 at 8:52 PM Sven Joachim wrote: > > On 2021-11-01 10:17 +0100, Greg Kroah-Hartman wrote: > > > From: Christian König > > > > commit 0db55f9a1bafbe3dac750ea669de9134922389b5 upstream. > > > > We need to cleanup the fences for ghost objects as well. > > > > Signed-off-by:

Re: [Nouveau] [PATCH 5.10 32/77] drm/ttm: fix memleak in ttm_transfered_destroy

On Wed, Nov 3, 2021 at 9:29 PM Karol Herbst wrote: > > On Wed, Nov 3, 2021 at 8:52 PM Sven Joachim wrote: > > > > On 2021-11-01 10:17 +0100, Greg Kroah-Hartman wrote: > > > > > From: Christian König > > > > > > commit 0db55f9a1bafbe3dac750ea669de9134922389b5 upstream. > > > > > > We need to

Re: [Nouveau] [PATCH 5.10 32/77] drm/ttm: fix memleak in ttm_transfered_destroy

On 2021-11-03 21:32 +0100, Karol Herbst wrote: > On Wed, Nov 3, 2021 at 9:29 PM Karol Herbst wrote: >> >> On Wed, Nov 3, 2021 at 8:52 PM Sven Joachim wrote: >> > >> > On 2021-11-01 10:17 +0100, Greg Kroah-Hartman wrote: >> > >> > > From: Christian König >> > > >> > > commit

Re: [Nouveau] [PATCH 5.10 32/77] drm/ttm: fix memleak in ttm_transfered_destroy

On Wed, Nov 3, 2021 at 9:47 PM Sven Joachim wrote: > > On 2021-11-03 21:32 +0100, Karol Herbst wrote: > > > On Wed, Nov 3, 2021 at 9:29 PM Karol Herbst wrote: > >> > >> On Wed, Nov 3, 2021 at 8:52 PM Sven Joachim wrote: > >> > > >> > On 2021-11-01 10:17 +0100, Greg Kroah-Hartman wrote: > >> > >

Re: [Nouveau] [PATCH] ce/gf100: fix incorrect CE0 address calculation on some GPUs

On Wed, Nov 3, 2021 at 8:51 AM Karol Herbst wrote: > > On Wed, Nov 3, 2021 at 2:11 AM Ben Skeggs wrote: > > > > From: Ben Skeggs > > > > The code which constructs the modules for each engine present on the GPU > > passes -1 for 'instance' on non-instanced engines, which affects how the > > name

Re: [Nouveau] [PATCH] ce/gf100: fix incorrect CE0 address calculation on some GPUs

On Wed, Nov 3, 2021 at 2:11 AM Ben Skeggs wrote: > > From: Ben Skeggs > > The code which constructs the modules for each engine present on the GPU > passes -1 for 'instance' on non-instanced engines, which affects how the > name for a sub-device is generated. This is then stored as 'instance 0'