On 7/10/2013 2:09 AM, Daniel Vetter wrote: > On Wed, Jul 10, 2013 at 04:01:49PM +1000, Dave Airlie wrote: >> On Wed, Jul 10, 2013 at 7:45 AM, Rhyland Klein <rklein@xxxxxxxxxx> wrote: >>> We are currently looking into exporting some information from the linux >>> kernel to userspace about the GPU. This information is specific per >>> board as the data can vary depending on the fuses burnt on the board. >>> >>> Right now we are leaning towards adding sysfs properties to our existing >>> nodes to share this information. >>> >>> Before we write up the patches and update our userspace apps to check >>> the new locations, we wanted to make sure there wasn't a more >>> accepted/proper way to export information already. >>> >>> Right now for instance we want to export a property to say how many >>> pixel pipes there are. This could then be exported in something like: >>> >>> /sys/bus/platform/drivers/gr3d/54180000.gr3d/num_pixel_pipes >>> >>> Is this the best approach to take right now or is there another way we >>> should export this and similar HW specific information? >> >> All the x86 GPU drivers use gpu specific get param ioctls for this so far. >> >> e.g. drivers/gpu/drm/radeon/radeon_kms.c:radeon_info_ioctl > > In drm/i915 we also expose a bunch of thing to sysfs, but everything that > the userspace drivers need for operation is exposed through the getparam > ioctl. We add sysfs interfaces on top if there's a legit reason for the > user to script changes (e.g. gpu error state collection or tuning the > frequency scaling and related read-only statistics). > -Daniel > Thank you both for your helpful responses. I was considering an ioctl as another option, and it seems that is likely the best approach to take for this type of information. Thanks, -rhyland -- nvpublic _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
