Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-11 Thread Daniel Vetter
On Wed, Nov 09, 2016 at 04:59:31PM +, Eric Engestrom wrote: > On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote: > > On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom > > wrote: > > >> Well, had to drop it again since it didn't compile: > > >> > > >> > > >>

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-10 Thread Jani Nikula
On Thu, 10 Nov 2016, Laurent Pinchart wrote: > Hi Jani, > > On Thursday 10 Nov 2016 12:30:09 Jani Nikula wrote: >> On Thu, 10 Nov 2016, Laurent Pinchart wrote: >> > The issue here is that printk can't format the fourcc as a string by >> > itself. There's a bunch

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-10 Thread Laurent Pinchart
Hi Jani, On Thursday 10 Nov 2016 12:30:09 Jani Nikula wrote: > On Thu, 10 Nov 2016, Laurent Pinchart wrote: > > On Wednesday 09 Nov 2016 16:59:31 Eric Engestrom wrote: > >> On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote: > >>> On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom wrote: >

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-10 Thread Jani Nikula
On Thu, 10 Nov 2016, Laurent Pinchart wrote: > Hi Eric, > > On Wednesday 09 Nov 2016 16:59:31 Eric Engestrom wrote: >> On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote: >> > On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom wrote: >> > >> Well, had to

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-10 Thread Laurent Pinchart
Hi Eric, On Wednesday 09 Nov 2016 16:59:31 Eric Engestrom wrote: > On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote: > > On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom wrote: > > >> Well, had to drop it again since it didn't compile: > > >> CC [M] drivers/gpu/drm/drm_blend.o > >

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-09 Thread Eric Engestrom
On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote: > On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom > wrote: > >> Well, had to drop it again since it didn't compile: > >> > >> > >> CC [M] drivers/gpu/drm/drm_blend.o > >> drivers/gpu/drm/drm_atomic.c: In

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-09 Thread Daniel Vetter
On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom wrote: >> Well, had to drop it again since it didn't compile: >> >> >> CC [M] drivers/gpu/drm/drm_blend.o >> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’: >>

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-09 Thread Eric Engestrom
On Wednesday, 2016-11-09 02:13:25 +0100, Daniel Vetter wrote: > On Wed, Nov 09, 2016 at 02:09:16AM +0100, Daniel Vetter wrote: > > On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote: > > > The function's behaviour was changed in 90844f00049e, without changing > > > its signature,

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-08 Thread Daniel Vetter
On Wed, Nov 09, 2016 at 02:09:16AM +0100, Daniel Vetter wrote: > On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote: > > The function's behaviour was changed in 90844f00049e, without changing > > its signature, causing people to keep using it the old way without > > realising they were

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-08 Thread Daniel Vetter
On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote: > The function's behaviour was changed in 90844f00049e, without changing > its signature, causing people to keep using it the old way without > realising they were now leaking memory. > Rob Clark also noticed it was also allocating

[Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-08 Thread Eric Engestrom
The function's behaviour was changed in 90844f00049e, without changing its signature, causing people to keep using it the old way without realising they were now leaking memory. Rob Clark also noticed it was also allocating GFP_KERNEL memory in atomic contexts, breaking them. Instead of having to