>-----Original Message----- >From: Intel-gfx [mailto:intel-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of >Chris Wilson >Sent: Monday, December 12, 2016 7:17 AM >To: Hiler, Arkadiusz <arkadiusz.hiler@xxxxxxxxx> >Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Michal Wajdeczko ><michal.wajdeczko@xxxxxxxxxxxxxxx> >Subject: Re: [PATCH 8/8] drm/i915/get_params: Add HuC status to >getparams > >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. 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.) > >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 > Thanks for explaining Chris.... Anusha >Chris Wilson, Intel Open Source Technology Centre >_______________________________________________ >Intel-gfx mailing list >Intel-gfx@xxxxxxxxxxxxxxxxxxxxx >https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
