[igt-dev] [PATCH i-g-t v2] Add Arm drivers as supported drivers by igt.

[Daniel Vetter]

On Thu, Jun 20, 2019 at 01:41:21PM +0100, Liviu Dudau wrote:
> On Thu, Jun 20, 2019 at 02:36:32PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 19, 2019 at 04:13:58PM +0100, Liviu Dudau wrote:
> > > Add the drivers maintained by Arm developers to the igt.
> > > 
> > > v2: Order the modules array entries alphabetically, as per
> > > Petri Latvala's suggestion.
> > > 
> > > Signed-off-by: Liviu Dudau <liviu.dudau at arm.com>
> > 
> > Still kinda wondering why you need this here ... kms is supposed to be
> > hw/driver agnostic, so DRIVER_ANY should work.
> 
> I'm looking at adding writeback scaling tests that not all drivers are going to
> support from the start, so I thought it is better to have a more specific
> driver that I can target, even if the DRM APIs are generic.

Yeah, but for that test I'd still expect you want to open DRIVER_ANY, then
check there's writeback, and then check for scaling (using TEST_ONLY
maybe). At least for some of the more generic ones.

You can always then add even more malidp/komeda specific tests with an
igt_require(is_malid(fd)) on top for some subtests. But imo the basic igt
should be generic, otherwise the entire idea of kms as being something
cross vendor/driver is out of the window.

Hence why I think this is totally the wrong direction here. What might be
good is some helper which gets the drm driver name and compares it to what
you need, i.e. igt_drmtest_require_driver(fd, "malidp");
-Daniel

> 
> Best regards,
> Liviu
> 
> > 
> > Maybe you want to check specific constraints in your tests, but then we
> > need something like igt_require(is_komeda_driver(fd)); which can inspect
> > what you're actually running on when the test executes.
> > 
> > The drivers in this list thus far are all about exercising the gem side of
> > things, where you _really_ don't want to open random garbage. Because the
> > ioctls aren't even defined.
> > 
> > On kms all ioctls are cross-driver, and only once you've opened something
> > does it make sense to check for features and stuff (looking at properties,
> > or getcap flags, or whatever).
> > 
> > Cheers, Daniel
> > 
> > PS: Yes I know that some of the DRIVER_I915 | DRIVER_AMDGPU tests really
> > should have been converted to DRIVER_ANY instead. I didn't catch that in
> > review way back, but I think I explained to Harry et al meanwhile ...
> > 
> > > ---
> > >  lib/drmtest.c | 3 +++
> > >  lib/drmtest.h | 4 ++++
> > >  2 files changed, 7 insertions(+)
> > > 
> > > diff --git a/lib/drmtest.c b/lib/drmtest.c
> > > index 25f203530..17bb87d1f 100644
> > > --- a/lib/drmtest.c
> > > +++ b/lib/drmtest.c
> > > @@ -205,7 +205,10 @@ static const struct module {
> > >  	void (*modprobe)(const char *name);
> > >  } modules[] = {
> > >  	{ DRIVER_AMDGPU, "amdgpu" },
> > > +	{ DRIVER_HDLCD, "hdlcd" },
> > >  	{ DRIVER_INTEL, "i915", modprobe_i915 },
> > > +	{ DRIVER_KOMEDA, "komeda" },
> > > +	{ DRIVER_MALIDP, "mali_dp" },
> > >  	{ DRIVER_PANFROST, "panfrost" },
> > >  	{ DRIVER_V3D, "v3d" },
> > >  	{ DRIVER_VC4, "vc4" },
> > > diff --git a/lib/drmtest.h b/lib/drmtest.h
> > > index 6c4c3899c..952f0c4b6 100644
> > > --- a/lib/drmtest.h
> > > +++ b/lib/drmtest.h
> > > @@ -45,6 +45,10 @@
> > >  #define DRIVER_AMDGPU	(1 << 4)
> > >  #define DRIVER_V3D	(1 << 5)
> > >  #define DRIVER_PANFROST	(1 << 6)
> > > +#define DRIVER_HDLCD	(1 << 7)
> > > +#define DRIVER_MALIDP	(1 << 8)
> > > +#define DRIVER_KOMEDA	(1 << 9)
> > > +
> > >  /*
> > >   * Exclude DRVER_VGEM from DRIVER_ANY since if you run on a system
> > >   * with vgem as well as a supported driver, you can end up with a
> > > -- 
> > > 2.22.0
> > > 
> > > _______________________________________________
> > > igt-dev mailing list
> > > igt-dev at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> -- 
> ====================
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---------------
>     ¯\_(ツ)_/¯

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