[Intel-gfx] [PATCH intel-gpu-tools 1/3] drmtest: Add non-i915 device open helpers

Micah Fedke micah.fedke at collabora.co.uk
Fri May 22 08:39:31 PDT 2015


Daniel,

Thanks.

I'm working to implement the driver name param and drm_require_driver 
now.  The prime stuff I'll have to familiarize myself with a bit more 
(and maybe dredge up some hw) but your suggestions sound reasonable enough.


-mf

On 05/22/2015 02:17 AM, Daniel Vetter wrote:
> Forgotten to add Thomas as the igt maintainer.
> -Daniel
>
> On Fri, May 8, 2015 at 3:03 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> On Tue, Apr 21, 2015 at 5:06 PM, Daniel Stone <daniel at fooishbar.org> wrote:
>>> On 21 April 2015 at 16:03, Micah Fedke <micah.fedke at collabora.co.uk> wrote:
>>>> + * drm_open_any_any:
>>>> + *
>>>> + * Literally the worst-named function I've ever written.
>>>
>>> And I stand by this. This is really an RFC, partly to find out whether
>>> it would be better to find a new name for these functions (open a
>>> modeset-capable DRM node, whether it's Intel or otherwise), or whether
>>> adding a flag to drm_open_any and friends to specify Intel or generic,
>>> with the resulting mega-Cocci run, would be better.
>>
>> Yeah I think a new param to restrict the driver name (i915, nouveau,
>> ...) would be better. Plus maybe a drm_require_driver so that testcase
>> could open a generic driver and then only skip specific subtest.
>> Initial pass could be done with cocci+ follow-up patches to convert
>> patches from i915 specific to generic.
>>
>> One thing to keep in mind is how we'll treat machines with more than 1
>> gpu. I do care about that at least for the prime testcases since I
>> have a box somewhere with i915+nouveau to run them, and that should
>> keep working. Aside: We should convert those tests to use
>> drm_open_any("nouveau") instead of the hand-rolled one. A possible
>> idea would be to convert the igt_main macros into a loop which would
>> go over all the available drm devices (well the different ones, we
>> don't want to separately test control/render/legacy nodes ofc). What
>> we definitely need is an enviroment variable to override the default
>> choice.
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
>

-- 

Micah Fedke
Collabora Ltd.
+44 1223 362967
https://www.collabora.com/
https://twitter.com/collaboraltd


More information about the Intel-gfx mailing list