[Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

Arkadiusz Hiler arkadiusz.hiler at intel.com
Mon Dec 12 15:27:39 UTC 2016


On Mon, Dec 12, 2016 at 03:17:16PM +0000, Chris Wilson wrote:
> On Mon, Dec 12, 2016 at 03:52:05PM +0100, Arkadiusz Hiler wrote:
> > On Mon, Dec 12, 2016 at 02:21:41PM +0000, Chris Wilson wrote:
> > > As for userspace simply asking where huc is enabled, we already have
> > > that in the ABI via the module parameter, so you need to justify why
> > > this is preferred (in addition to the available information).
> > 
> > Yeah, we do change the values of module parameters. But a lot of them
> > are uid 0 only and we have PARAMS for those.
> > 
> > Do anything userspace use those actually? Do we plan to use them instead
> > of the getparams since now on?
> 
> I've done both from userspace... I don't really have a preference, once
> you have an fd, an ioctl/GETPARAM is trivial. But for quick querying and
> reporting of driver state, reading the module parameter is easier. So I
> have a tendency to use an ioctl in production code and module parameter
> in igt. (And I would say that for one-off validation purposes, i.e. did
> hte module actually enable huc?, just check the module parameter.

Thank you for explaining it :)

> If  userspace is expected to interact and respond to the setting
> during its early probe, make it an ioctl so it fits in with the
> similar code also being run at that time.)

Okay. Seems like the scenario Anusha's got.

> It is just worth explaining the intended usecase in the cover note, so
> that the use can be sanity checked and reflected upon later if need be.
> -Chris

The cover letter links patches from the libva which is pretty much a
template usecase, but I agree, it wold be nice if it used
words/pseudocode instead of portions of code from some other project.

> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
Cheers,
Arek


More information about the Intel-gfx mailing list