[Freedreno] [PATCH 02/13] drm: drm_printer: Add printer for devcoredump

[Jordan Crouse]

On Thu, Jul 12, 2018 at 08:40:55PM +0100, Chris Wilson wrote:
> Quoting Jordan Crouse (2018-07-12 19:59:19)
> > Add a drm printer suitable for use with the read callback for
> > devcoredump or other suitable buffer based output format that
> > isn't otherwise covered by seq_file.
> > 
> > Signed-off-by: Jordan Crouse <jcrouse at codeaurora.org>
> > ---
> >  drivers/gpu/drm/drm_print.c | 74 +++++++++++++++++++++++++++++++++++++
> >  include/drm/drm_print.h     | 27 ++++++++++++++
> >  2 files changed, 101 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> > index b25f98f33f6c..03d1f98e5ac7 100644
> > --- a/drivers/gpu/drm/drm_print.c
> > +++ b/drivers/gpu/drm/drm_print.c
> > @@ -30,6 +30,80 @@
> >  #include <drm/drmP.h>
> >  #include <drm/drm_print.h>
> >  
> > +void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf)
> > +{
> > +       struct drm_print_iterator *iterator = p->arg;
> > +       ssize_t len;
> > +
> > +       if (!iterator->remain)
> > +               return;
> > +
> > +       /* Figure out how big the string will be */
> > +       len = snprintf(NULL, 0, "%pV", vaf);
> 
> I was thinking there's some duplication here (kmalloc + snprintf) that
> could be reduced to kasprintf here. Is avoiding that allocation
> important or frequent enough to merit open coding?
> 
> It's pity the kernel's printk doesn't support %n, so that leaves with
> 
> buf = kasprintf(GFP_... , "%pV", vaf);
> if (!buf)
> 	return;
> 
> len = strlen(buf);

> and even the copy + increment looks like it can then be factored to share
> more code.

I could profile it to see if avoiding the allocation is worth while.

I have a use case that prints approximately 1MB (stupid GPU, be less complex)
so that is enough to be able to see noticeable deltas if they exist.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project