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:
> > >>
> > >>
> > >>   CC [M]  drivers/gpu/drm/drm_blend.o
> > >> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’:
> > >> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function 
> > >> ‘drm_get_format_name’
> > >>  drm_get_format_name(fb->pixel_format));
> > >>  ^~~
> > >> In file included from ./include/drm/drmP.h:71:0,
> > >>  from drivers/gpu/drm/drm_atomic.c:29:
> > >> ./include/drm/drm_fourcc.h:65:7: note: declared here
> > >>  char *drm_get_format_name(uint32_t format, struct drm_format_name_buf 
> > >> *buf);
> > >>^~~
> > >>
> > >> Can you pls rebase onto drm-misc or linux-next or something?
> > >
> > > That was based on airlied/drm-next (last fetched on Sunday I think),
> > > I can rebase it on drm-misc if it helps, but it seems older than
> > > drm-next.
> > > Should I just rebase on top of current head of drm-next?
> > 
> > It needs to be drm-misc (linux-next doesn't have it yet) due to the
> > new atomic debug work that we just landed. I'm working on drm-tip as a
> > drm local integration tree to ease pains like these a bit, but that
> > doesn't really exist yet.
> 
> I'm confused as to how the different trees and branches merge back to
> Torvalds' tree (I'm interested in particular in drm), and I'm not sure
> which branch you want me to rebase on in the drm-misc tree [1],
> especially since all of them are older than drm-next [2].

Dave just pulled in all outstanding pull requests, so just basing on top
of his drm-next should be good enough.

> I'll try to rebase on drm-misc-fixes (currently at 4da5caa6a6f82cda3193)
> as it sounds about right, but it doesn't apply at all, so it'll take
> a little while.
> 
> Could you give me a quick explanation or point me to a doc/page that
> explains how the various trees and branches get merged?
> I googled a bit and found this doc [4] by Jani, but it doesn't mention
> drm-misc for instance, so I'm not sure how up-to-date and
> non-intel-specific it is.

We atm don't have it :( drm-misc was kinda just a (very long running)
experiment, but I want to know make it official. Unfortunately the
scripting rework to split out a new drm-misc.git repo is taking a bit
longer. Atm things are still in flux, but I hope that'll settle soon-ish.

> Looking at this page, something just occurred to me: did you mean
> drm-fixes [3], instead of one of the branches on drm-misc?
> 
> Cheers,
>   Eric
> 
> [1] git://anongit.freedesktop.org/drm/drm-misc

Yeah, that's the new location, but atm it's just under testing and it's
not the real drm-misc. That one is in drm-intel.git, in the topic/drm-misc
branch.

> [2] git://people.freedesktop.org/~airlied/linux drm-next
> [2] git://people.freedesktop.org/~airlied/linux drm-fixes
> [3] https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html

https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html

We need to flesh that out, and maybe feature it a bit more prominently.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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 of places in the kernel where a similar
>> > formatting problem occurs. In a few occasions it has been solved by
>> > extending printk with additional format specifiers (such as for MAC/IP
>> > addresses, GUIDs, various kind of device names, ...). DRM fourccs are
>> > probably too DRM specific to be worth a format specifier, but I wonder
>> > whether we could introduce a new specifier that takes a function pointer
>> > as a formatting helper. Another similarly crazy option would be a format
>> > specifier for strings that would free the passed pointer after printing
>> > it.
>> 
>> I think there are too many non-standard format specifiers already. I
>> can't review the non-standard format strings without looking at
>> Documentation/prink-formats.txt first. The formatting hook would be a
>> generic alternative, but that's more than a little scary from the
>> security standpoint. And what if the hook has to allocate memory? Can't
>> do that in atomic contexts.
>
> There are lots of details to sort out obviously and I don't have an answer to 
> all questions yet. I think it would be worth researching this, as the problem 
> isn't specific to DRM/KMS.

That's easy to agree to; as much as you didn't mean to shoot down the
patch, I didn't mean to shoot down your idea! :)

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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:
> > 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’:
> > drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to
> > function ‘drm_get_format_name’> >>
> >  drm_get_format_name(fb->pixel_format));
> >  ^~~
> > In file included from ./include/drm/drmP.h:71:0,
> >  from drivers/gpu/drm/drm_atomic.c:29:
> > ./include/drm/drm_fourcc.h:65:7: note: declared here
> >  char *drm_get_format_name(uint32_t format, struct
> >  drm_format_name_buf *buf);
> >^~~
> > 
> > Can you pls rebase onto drm-misc or linux-next or something?
>  
>  That was based on airlied/drm-next (last fetched on Sunday I think),
>  I can rebase it on drm-misc if it helps, but it seems older than
>  drm-next. Should I just rebase on top of current head of drm-next?
> >>> 
> >>> It needs to be drm-misc (linux-next doesn't have it yet) due to the
> >>> new atomic debug work that we just landed. I'm working on drm-tip as a
> >>> drm local integration tree to ease pains like these a bit, but that
> >>> doesn't really exist yet.
> >> 
> >> I'm confused as to how the different trees and branches merge back to
> >> Torvalds' tree (I'm interested in particular in drm), and I'm not sure
> >> which branch you want me to rebase on in the drm-misc tree [1],
> >> especially since all of them are older than drm-next [2].
> >> 
> >> I'll try to rebase on drm-misc-fixes (currently at 4da5caa6a6f82cda3193)
> >> as it sounds about right, but it doesn't apply at all, so it'll take
> >> a little while.
> > 
> > While at it, could you make the function return a const char * ?
> 
> I thought I mentioned that too, though I didn't insist.

You did, and I think Eric agreed to change that.

> > By the way, while this is an improvement over the current situation in
> > that it fixes the missing kfree() issue, I wonder whether the problem
> > we're trying to solve should be addressed at a more global level.
> 
> Maybe, but let's not block this one!

Sure, that wasn't the intent of my e-mail.

> > The issue here is that printk can't format the fourcc as a string by
> > itself. There's a bunch of places in the kernel where a similar
> > formatting problem occurs. In a few occasions it has been solved by
> > extending printk with additional format specifiers (such as for MAC/IP
> > addresses, GUIDs, various kind of device names, ...). DRM fourccs are
> > probably too DRM specific to be worth a format specifier, but I wonder
> > whether we could introduce a new specifier that takes a function pointer
> > as a formatting helper. Another similarly crazy option would be a format
> > specifier for strings that would free the passed pointer after printing
> > it.
> 
> I think there are too many non-standard format specifiers already. I
> can't review the non-standard format strings without looking at
> Documentation/prink-formats.txt first. The formatting hook would be a
> generic alternative, but that's more than a little scary from the
> security standpoint. And what if the hook has to allocate memory? Can't
> do that in atomic contexts.

There are lots of details to sort out obviously and I don't have an answer to 
all questions yet. I think it would be worth researching this, as the problem 
isn't specific to DRM/KMS.

> >> Could you give me a quick explanation or point me to a doc/page that
> >> explains how the various trees and branches get merged?
> >> I googled a bit and found this doc [4] by Jani, but it doesn't mention
> >> drm-misc for instance, so I'm not sure how up-to-date and
> >> non-intel-specific it is.
> >> 
> >> Looking at this page, something just occurred to me: did you mean
> >> drm-fixes [3], instead of one of the branches on drm-misc?
> >> 
> >> Cheers,
> >> 
> >>   Eric
> >> 
> >> [1] git://anongit.freedesktop.org/drm/drm-misc
> >> [2] git://people.freedesktop.org/~airlied/linux drm-next
> >> [2] git://people.freedesktop.org/~airlied/linux drm-fixes
> >> [3] https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html

-- 
Regards,

Laurent Pinchart

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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 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’:
>> > >> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to
>> > >> function ‘drm_get_format_name’> >> 
>> > >>  drm_get_format_name(fb->pixel_format));
>> > >>  ^~~
>> > >> 
>> > >> In file included from ./include/drm/drmP.h:71:0,
>> > >> 
>> > >>  from drivers/gpu/drm/drm_atomic.c:29:
>> > >> ./include/drm/drm_fourcc.h:65:7: note: declared here
>> > >> 
>> > >>  char *drm_get_format_name(uint32_t format, struct drm_format_name_buf
>> > >>  *buf);> >>  
>> > >>^~~
>> > >> 
>> > >> Can you pls rebase onto drm-misc or linux-next or something?
>> > > 
>> > > That was based on airlied/drm-next (last fetched on Sunday I think),
>> > > I can rebase it on drm-misc if it helps, but it seems older than
>> > > drm-next. Should I just rebase on top of current head of drm-next?
>> > 
>> > It needs to be drm-misc (linux-next doesn't have it yet) due to the
>> > new atomic debug work that we just landed. I'm working on drm-tip as a
>> > drm local integration tree to ease pains like these a bit, but that
>> > doesn't really exist yet.
>> 
>> I'm confused as to how the different trees and branches merge back to
>> Torvalds' tree (I'm interested in particular in drm), and I'm not sure
>> which branch you want me to rebase on in the drm-misc tree [1],
>> especially since all of them are older than drm-next [2].
>> 
>> I'll try to rebase on drm-misc-fixes (currently at 4da5caa6a6f82cda3193)
>> as it sounds about right, but it doesn't apply at all, so it'll take
>> a little while.
>
> While at it, could you make the function return a const char * ?

I thought I mentioned that too, though I didn't insist.

> By the way, while this is an improvement over the current situation in that 
> it 
> fixes the missing kfree() issue, I wonder whether the problem we're trying to 
> solve should be addressed at a more global level.

Maybe, but let's not block this one!

> The issue here is that printk can't format the fourcc as a string by itself. 
> There's a bunch of places in the kernel where a similar formatting problem 
> occurs. In a few occasions it has been solved by extending printk with 
> additional format specifiers (such as for MAC/IP addresses, GUIDs, various 
> kind of device names, ...). DRM fourccs are probably too DRM specific to be 
> worth a format specifier, but I wonder whether we could introduce a new 
> specifier that takes a function pointer as a formatting helper. Another 
> similarly crazy option would be a format specifier for strings that would 
> free 
> the passed pointer after printing it.

I think there are too many non-standard format specifiers already. I
can't review the non-standard format strings without looking at
Documentation/prink-formats.txt first. The formatting hook would be a
generic alternative, but that's more than a little scary from the
security standpoint. And what if the hook has to allocate memory? Can't
do that in atomic contexts.

BR,
Jani.


>
>> Could you give me a quick explanation or point me to a doc/page that
>> explains how the various trees and branches get merged?
>> I googled a bit and found this doc [4] by Jani, but it doesn't mention
>> drm-misc for instance, so I'm not sure how up-to-date and
>> non-intel-specific it is.
>> 
>> Looking at this page, something just occurred to me: did you mean
>> drm-fixes [3], instead of one of the branches on drm-misc?
>> 
>> Cheers,
>>   Eric
>> 
>> [1] git://anongit.freedesktop.org/drm/drm-misc
>> [2] git://people.freedesktop.org/~airlied/linux drm-next
>> [2] git://people.freedesktop.org/~airlied/linux drm-fixes
>> [3] https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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
> > >> 
> > >> drivers/gpu/drm/drm_atomic.c: In function
> > >> ‘drm_atomic_plane_print_state’:
> > >> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to
> > >> function ‘drm_get_format_name’> >> 
> > >>  drm_get_format_name(fb->pixel_format));
> > >>  ^~~
> > >> 
> > >> In file included from ./include/drm/drmP.h:71:0,
> > >> 
> > >>  from drivers/gpu/drm/drm_atomic.c:29:
> > >> ./include/drm/drm_fourcc.h:65:7: note: declared here
> > >> 
> > >>  char *drm_get_format_name(uint32_t format, struct drm_format_name_buf
> > >>  *buf);> >>  
> > >>^~~
> > >> 
> > >> Can you pls rebase onto drm-misc or linux-next or something?
> > > 
> > > That was based on airlied/drm-next (last fetched on Sunday I think),
> > > I can rebase it on drm-misc if it helps, but it seems older than
> > > drm-next. Should I just rebase on top of current head of drm-next?
> > 
> > It needs to be drm-misc (linux-next doesn't have it yet) due to the
> > new atomic debug work that we just landed. I'm working on drm-tip as a
> > drm local integration tree to ease pains like these a bit, but that
> > doesn't really exist yet.
> 
> I'm confused as to how the different trees and branches merge back to
> Torvalds' tree (I'm interested in particular in drm), and I'm not sure
> which branch you want me to rebase on in the drm-misc tree [1],
> especially since all of them are older than drm-next [2].
> 
> I'll try to rebase on drm-misc-fixes (currently at 4da5caa6a6f82cda3193)
> as it sounds about right, but it doesn't apply at all, so it'll take
> a little while.

While at it, could you make the function return a const char * ?

By the way, while this is an improvement over the current situation in that it 
fixes the missing kfree() issue, I wonder whether the problem we're trying to 
solve should be addressed at a more global level.

The issue here is that printk can't format the fourcc as a string by itself. 
There's a bunch of places in the kernel where a similar formatting problem 
occurs. In a few occasions it has been solved by extending printk with 
additional format specifiers (such as for MAC/IP addresses, GUIDs, various 
kind of device names, ...). DRM fourccs are probably too DRM specific to be 
worth a format specifier, but I wonder whether we could introduce a new 
specifier that takes a function pointer as a formatting helper. Another 
similarly crazy option would be a format specifier for strings that would free 
the passed pointer after printing it.

> Could you give me a quick explanation or point me to a doc/page that
> explains how the various trees and branches get merged?
> I googled a bit and found this doc [4] by Jani, but it doesn't mention
> drm-misc for instance, so I'm not sure how up-to-date and
> non-intel-specific it is.
> 
> Looking at this page, something just occurred to me: did you mean
> drm-fixes [3], instead of one of the branches on drm-misc?
> 
> Cheers,
>   Eric
> 
> [1] git://anongit.freedesktop.org/drm/drm-misc
> [2] git://people.freedesktop.org/~airlied/linux drm-next
> [2] git://people.freedesktop.org/~airlied/linux drm-fixes
> [3] https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html

-- 
Regards,

Laurent Pinchart

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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 function ‘drm_atomic_plane_print_state’:
> >> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function 
> >> ‘drm_get_format_name’
> >>  drm_get_format_name(fb->pixel_format));
> >>  ^~~
> >> In file included from ./include/drm/drmP.h:71:0,
> >>  from drivers/gpu/drm/drm_atomic.c:29:
> >> ./include/drm/drm_fourcc.h:65:7: note: declared here
> >>  char *drm_get_format_name(uint32_t format, struct drm_format_name_buf 
> >> *buf);
> >>^~~
> >>
> >> Can you pls rebase onto drm-misc or linux-next or something?
> >
> > That was based on airlied/drm-next (last fetched on Sunday I think),
> > I can rebase it on drm-misc if it helps, but it seems older than
> > drm-next.
> > Should I just rebase on top of current head of drm-next?
> 
> It needs to be drm-misc (linux-next doesn't have it yet) due to the
> new atomic debug work that we just landed. I'm working on drm-tip as a
> drm local integration tree to ease pains like these a bit, but that
> doesn't really exist yet.

I'm confused as to how the different trees and branches merge back to
Torvalds' tree (I'm interested in particular in drm), and I'm not sure
which branch you want me to rebase on in the drm-misc tree [1],
especially since all of them are older than drm-next [2].

I'll try to rebase on drm-misc-fixes (currently at 4da5caa6a6f82cda3193)
as it sounds about right, but it doesn't apply at all, so it'll take
a little while.

Could you give me a quick explanation or point me to a doc/page that
explains how the various trees and branches get merged?
I googled a bit and found this doc [4] by Jani, but it doesn't mention
drm-misc for instance, so I'm not sure how up-to-date and
non-intel-specific it is.

Looking at this page, something just occurred to me: did you mean
drm-fixes [3], instead of one of the branches on drm-misc?

Cheers,
  Eric

[1] git://anongit.freedesktop.org/drm/drm-misc
[2] git://people.freedesktop.org/~airlied/linux drm-next
[2] git://people.freedesktop.org/~airlied/linux drm-fixes
[3] https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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’:
>> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function 
>> ‘drm_get_format_name’
>>  drm_get_format_name(fb->pixel_format));
>>  ^~~
>> In file included from ./include/drm/drmP.h:71:0,
>>  from drivers/gpu/drm/drm_atomic.c:29:
>> ./include/drm/drm_fourcc.h:65:7: note: declared here
>>  char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
>>^~~
>>
>> Can you pls rebase onto drm-misc or linux-next or something?
>
> That was based on airlied/drm-next (last fetched on Sunday I think),
> I can rebase it on drm-misc if it helps, but it seems older than
> drm-next.
> Should I just rebase on top of current head of drm-next?

It needs to be drm-misc (linux-next doesn't have it yet) due to the
new atomic debug work that we just landed. I'm working on drm-tip as a
drm local integration tree to ease pains like these a bit, but that
doesn't really exist yet.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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, 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 allocate GFP_ATOMIC memory and fixing the callers
> > > to make them cleanup the memory afterwards, let's change the function's
> > > signature by having the caller take care of the memory and passing it to
> > > the function.
> > > The new parameter is a single-field struct in order to enforce the size
> > > of its buffer and help callers to correctly manage their memory.
> > > 
> > > Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
> > > Cc: Rob Clark 
> > > Cc: Christian König 
> > > Acked-by: Christian König 
> > > Acked-by: Rob Clark 
> > > Acked-by: Sinclair Yeh  (vmwgfx)
> > > Reviewed-by: Jani Nikula 
> > > Suggested-by: Ville Syrjälä 
> > > Signed-off-by: Eric Engestrom 
> > > ---
> > > v3 - fix "Fixes" tag, replace it with an actual commit message
> > >- collect ack & r-b
> > > 
> > > v2 - use single-field struct instead of typedef to let the compiler
> > >  enforce the type (Christian König)
> > 
> > Applied to drm-misc, thanks.
> 
> 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’:
> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function 
> ‘drm_get_format_name’
>  drm_get_format_name(fb->pixel_format));
>  ^~~
> In file included from ./include/drm/drmP.h:71:0,
>  from drivers/gpu/drm/drm_atomic.c:29:
> ./include/drm/drm_fourcc.h:65:7: note: declared here
>  char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
>^~~
> 
> Can you pls rebase onto drm-misc or linux-next or something?

That was based on airlied/drm-next (last fetched on Sunday I think),
I can rebase it on drm-misc if it helps, but it seems older than
drm-next.
Should I just rebase on top of current head of drm-next?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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 now leaking memory.
> > Rob Clark also noticed it was also allocating GFP_KERNEL memory in
> > atomic contexts, breaking them.
> > 
> > Instead of having to allocate GFP_ATOMIC memory and fixing the callers
> > to make them cleanup the memory afterwards, let's change the function's
> > signature by having the caller take care of the memory and passing it to
> > the function.
> > The new parameter is a single-field struct in order to enforce the size
> > of its buffer and help callers to correctly manage their memory.
> > 
> > Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
> > Cc: Rob Clark 
> > Cc: Christian König 
> > Acked-by: Christian König 
> > Acked-by: Rob Clark 
> > Acked-by: Sinclair Yeh  (vmwgfx)
> > Reviewed-by: Jani Nikula 
> > Suggested-by: Ville Syrjälä 
> > Signed-off-by: Eric Engestrom 
> > ---
> > v3 - fix "Fixes" tag, replace it with an actual commit message
> >- collect ack & r-b
> > 
> > v2 - use single-field struct instead of typedef to let the compiler
> >  enforce the type (Christian König)
> 
> Applied to drm-misc, thanks.

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’:
drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function 
‘drm_get_format_name’
 drm_get_format_name(fb->pixel_format));
 ^~~
In file included from ./include/drm/drmP.h:71:0,
 from drivers/gpu/drm/drm_atomic.c:29:
./include/drm/drm_fourcc.h:65:7: note: declared here
 char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
   ^~~

Can you pls rebase onto drm-misc or linux-next or something?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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 GFP_KERNEL memory in
> atomic contexts, breaking them.
> 
> Instead of having to allocate GFP_ATOMIC memory and fixing the callers
> to make them cleanup the memory afterwards, let's change the function's
> signature by having the caller take care of the memory and passing it to
> the function.
> The new parameter is a single-field struct in order to enforce the size
> of its buffer and help callers to correctly manage their memory.
> 
> Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
> Cc: Rob Clark 
> Cc: Christian König 
> Acked-by: Christian König 
> Acked-by: Rob Clark 
> Acked-by: Sinclair Yeh  (vmwgfx)
> Reviewed-by: Jani Nikula 
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Eric Engestrom 
> ---
> v3 - fix "Fixes" tag, replace it with an actual commit message
>- collect ack & r-b
> 
> v2 - use single-field struct instead of typedef to let the compiler
>  enforce the type (Christian König)

Applied to drm-misc, thanks.
-Daniel

> ---
>  include/drm/drm_fourcc.h| 10 +-
>  drivers/gpu/drm/drm_fourcc.c| 14 +++--
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
>  drivers/gpu/drm/drm_atomic.c|  7 +++--
>  drivers/gpu/drm/drm_crtc.c  |  7 +++--
>  drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
>  drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
>  drivers/gpu/drm/drm_plane.c |  7 +++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
>  drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
>  drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
>  drivers/gpu/drm/i915/intel_display.c| 41 
> ++---
>  drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
>  17 files changed, 80 insertions(+), 86 deletions(-)
> 
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index dc0aafa..4b03ca0 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -45,6 +45,14 @@ struct drm_format_info {
>   u8 vsub;
>  };
>  
> +/**
> + * struct drm_format_name_buf - name of a DRM format
> + * @str: string buffer containing the format name
> + */
> +struct drm_format_name_buf {
> + char str[32];
> +};
> +
>  const struct drm_format_info *__drm_format_info(u32 format);
>  const struct drm_format_info *drm_format_info(u32 format);
>  uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
> @@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
>  int drm_format_vert_chroma_subsampling(uint32_t format);
>  int drm_format_plane_width(int width, uint32_t format, int plane);
>  int drm_format_plane_height(int height, uint32_t format, int plane);
> -char *drm_get_format_name(uint32_t format) __malloc;
> +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
>  
>  #endif /* __DRM_FOURCC_H__ */
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index cbb8b77..99b0b60 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
> depth)
>  EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>  
>  /**
> - * drm_get_format_name - return a string for drm fourcc format
> + * drm_get_format_name - fill a string with a drm fourcc format's name
>   * @format: format to compute name of
> + * @buf: caller-supplied buffer
> - *
> - * Note that the buffer returned by this function is owned by the caller
> - * and will need to be freed using kfree().
>   */
> -char *drm_get_format_name(uint32_t format)
> +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
>  {
> - char *buf = kmalloc(32, GFP_KERNEL);
> -
> - snprintf(buf, 32,
> + snprintf(buf->str, sizeof(buf->str),
>"%c%c%c%c %s-endian (0x%08x)",
>printable_char(format & 0xff),
>printable_char((format >> 8) & 0xff),
> @@ -98,7 +94,7 @@ char *drm_get_format_name(uint32_t format)
>format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
>format);
>  
> - return buf;
> + return buf->str;
>  }
>

[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 allocate GFP_ATOMIC memory and fixing the callers
to make them cleanup the memory afterwards, let's change the function's
signature by having the caller take care of the memory and passing it to
the function.
The new parameter is a single-field struct in order to enforce the size
of its buffer and help callers to correctly manage their memory.

Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
Cc: Rob Clark 
Cc: Christian König 
Acked-by: Christian König 
Acked-by: Rob Clark 
Acked-by: Sinclair Yeh  (vmwgfx)
Reviewed-by: Jani Nikula 
Suggested-by: Ville Syrjälä 
Signed-off-by: Eric Engestrom 
---
v3 - fix "Fixes" tag, replace it with an actual commit message
   - collect ack & r-b

v2 - use single-field struct instead of typedef to let the compiler
 enforce the type (Christian König)
---
 include/drm/drm_fourcc.h| 10 +-
 drivers/gpu/drm/drm_fourcc.c| 14 +++--
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
 drivers/gpu/drm/drm_atomic.c|  7 +++--
 drivers/gpu/drm/drm_crtc.c  |  7 +++--
 drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
 drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
 drivers/gpu/drm/drm_plane.c |  7 +++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
 drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
 drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
 drivers/gpu/drm/i915/intel_display.c| 41 ++---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
 17 files changed, 80 insertions(+), 86 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index dc0aafa..4b03ca0 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -45,6 +45,14 @@ struct drm_format_info {
u8 vsub;
 };
 
+/**
+ * struct drm_format_name_buf - name of a DRM format
+ * @str: string buffer containing the format name
+ */
+struct drm_format_name_buf {
+   char str[32];
+};
+
 const struct drm_format_info *__drm_format_info(u32 format);
 const struct drm_format_info *drm_format_info(u32 format);
 uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
@@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
 int drm_format_vert_chroma_subsampling(uint32_t format);
 int drm_format_plane_width(int width, uint32_t format, int plane);
 int drm_format_plane_height(int height, uint32_t format, int plane);
-char *drm_get_format_name(uint32_t format) __malloc;
+char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
 
 #endif /* __DRM_FOURCC_H__ */
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index cbb8b77..99b0b60 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
depth)
 EXPORT_SYMBOL(drm_mode_legacy_fb_format);
 
 /**
- * drm_get_format_name - return a string for drm fourcc format
+ * drm_get_format_name - fill a string with a drm fourcc format's name
  * @format: format to compute name of
+ * @buf: caller-supplied buffer
- *
- * Note that the buffer returned by this function is owned by the caller
- * and will need to be freed using kfree().
  */
-char *drm_get_format_name(uint32_t format)
+char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
 {
-   char *buf = kmalloc(32, GFP_KERNEL);
-
-   snprintf(buf, 32,
+   snprintf(buf->str, sizeof(buf->str),
 "%c%c%c%c %s-endian (0x%08x)",
 printable_char(format & 0xff),
 printable_char((format >> 8) & 0xff),
@@ -98,7 +94,7 @@ char *drm_get_format_name(uint32_t format)
 format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
 format);
 
-   return buf;
+   return buf->str;
 }
 EXPORT_SYMBOL(drm_get_format_name);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 199d3f7..2924cdd 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2032,7 +2032,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc