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

[Daniel Vetter]

On Thu, Jun 20, 2019 at 3:12 PM Daniel Vetter <daniel at ffwll.ch> wrote:
>
> 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");

btw last autumn I've dropped the same review onto the vmwgfx folks,
and they adjusted their patches. I really do want igt to be
cross-vendor for kms, but we won't get there if we just keep piling up
vendor-only tests ...
-Daniel

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



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