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

[Daniel Vetter]

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 :-)

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