[PATCH v3 1/6] drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info

[Liviu Dudau]

On Thu, Oct 11, 2018 at 02:40:10PM +0200, Daniel Vetter wrote:
> On Thu, Oct 11, 2018 at 12:11 PM Liviu Dudau <Liviu.Dudau at arm.com> wrote:
> > On Thu, Oct 11, 2018 at 10:58:30AM +0100, Alexandru-Cosmin Gheorghe wrote:
> > > On Thu, Oct 11, 2018 at 10:29:42AM +0200, Daniel Vetter wrote:
> > > > On Mon, Oct 08, 2018 at 09:52:04AM +0000, Alexandru-Cosmin Gheorghe wrote:
> > > > > > One question I have is validating this. I think a bunch of unit tests,
> > > > > > integrated into the existing kms selftests we already (so that
> > > > > > intel-gfx-ci and other CI can run it) would be great. Both for the small
> > > > > > helper functions (block width/height, but especially drm_pitch), but also
> > > > > > for the drm_framebuffer_create functions, so that we can exercise the
> > > > > > metric pile of validation corner cases.
> > > > > > -Daniel
> > > > >
> > > > > So, you are thinking of adding tests here drivers/gpu/drm/selftests/ ?
> > > > > Looking inside the folder, it seems more like a stub than proper
> > > > > test suite for the drm framework, or am I missing something ?
> > > >
> > > > It's indeed very incomplete still.
> > > >
> > > > > I did run tests for all supported formats by the mali-dp, with our
> > > > > internal testsuite and everything was OK for all the fourcc enabled
> > > > > in mali-dp
> > > >
> > > > Your internal test suite is to no value to the overall community :-) Can
> > > > we get those upstreamed somewhere, ideally as part of igt?
> >
> > On balance of things, how many more drivers are we going to cover when
> > going from internal test suite to igt? +1 (intel)? +3 (finger in the
> > air)? By looking at the commit log is hard to judge the traction of igt in
> > the "overall community".
> 
> With my intel hat on I don't particularly care how you test mali, and
> I don't think you folks care how we test intel. (Ok maybe there's a
> shared interest in having high quality upstream drivers so that OS
> people can upgrade without fear of regressions across any of the hw
> vendors, but that's a long story and somewhat an aside).
> 
> But there's piles of shared infrastructure, and that's really where I
> think a common test suite, ideally run as part of drm core CI (I'm
> working on that, doesn't exist yet). That's where the shared CI
> efforts really pay off imo. There's also some value in trying to make
> sure all drivers work the same across all drivers. Both of these
> pieces need to be there to be able to refactor the drm subsystem
> aggressively, which we'll need to do because hw is changing all the
> time. If you don't care about any of this, then pushing your driver to
> upstream doesn't make a hole lot of sense imo :-)

Nah, I wasn't looking to start a holy war, it was a genuine question. I
don't remember exactly the timeline but I do admit that I was a bit
puzzled (confused?) by the appearance of drivers/gpu/drm/selftests given
the existence of igt, so I though one of them is the "newer" thing to
support. I was on the fence on which one is worth backing, hence the
quantitative question (how many more drivers actively get tested with
igt?).

I know that I have used igt to test mali-dp before submission, we also
had some patches that need refreshing to add writeback support (sorry
for being slow on those), but I haven't seen people contributing in
earnest to igt support for their drivers (vc4 is the newest, amdgpu from
a few months ago, I thought there was some adreno stuff but I can't find
right now). So for the passer-bys (aka managers) it is hard (sometimes)
to see the benefit of investing effort in something that doesn't look
like a clear winner.

Maybe igt could use some "Supported drivers" section in the README so we
can point it out to our decision makers?

Best regards,
Liviu

> 
> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯