Cleanup of -Wunused-const-variable in drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c

[Daniel Vetter]

On Thu, Jun 13, 2019 at 01:52:02PM -0700, Rob Clark wrote:
> so, for dpu_format_map_tile, I'd like to define a fourcc modifier for
> tiled formats (we currently have a workaround in userspace w/ a
> private modifier in the gallium driver).. I think the problem is
> defining the layout of the tiled format(s) (there are at least two per
> generation and I can't guarantee they are the same across adreno
> generations).  We've mostly avoided needing to know the exact layout
> by using gpu blits to go from tiled<->linear so far.
> 
> For the others, those look like formats we haven't wired up yet.
> 
> I'd say they are all things we want to support eventually, although
> not sure what the timeline will be..  but I'd ask if you remove them
> then split into at least a separate patch for dpu_format_map_tile vs
> others, so we can more easily revert/amend to bring them back.

We've been kinda cheating on this with i915 modifiers too, X/Y tiled
depend upon the chip you're running on :-) But on all modern chips it's a
lot more well-defined, so probably not a huge problem.

I think there's little chance right now for adreno to become a discrete
gpu, so could do the same tricky. If it ever becomes discrete or we want
to share more, then we'd need to bake in the layout properly I think.

I guess the question is: Is the format shared with e.g. camera blocks, or
purely a freedreno internal thing.
-Daniel

> 
> BR,
> -R
> 
> On Thu, Jun 13, 2019 at 1:13 PM Nathan Huckleberry <nhuck at google.com> wrote:
> >
> > Hey all,
> >
> > I'm looking into cleaning up ignored warnings in the kernel so we can
> > remove compiler flags to ignore warnings.
> >
> > There are several unused variables in dpu_formats.c
> > ('dpu_format_map_tile', 'dpu_format_map_p010',
> > 'dpu_format_map_p010_ubwc', 'dpu_format_map_tp10_ubwc').
> > They look like modifiers that were never implemented. I'd like to
> > remove these variables if there are no plans moving forward to
> > implement them. Otherwise I'll just leave them.
> >
> > https://github.com/ClangBuiltLinux/linux/issues/528
> >
> > Thanks,
> > Nathan Huckleberry

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch