On Thu, Dec 01, 2016 at 01:44:14PM +0530, swati.dhin...@intel.com wrote:
> From: Swati Dhingra <swati.dhin...@intel.com>
> 
> Currently, for the purpose of providing output debug/loggging/crc and various
> other kinds of data from DRM layer to userspace, we don't have a standard
> filesystem, which would suffice for all the usecases. The filesystems used
> currently such as debugfs/sysfs have their own constraints and are intended
> to output a particular type of data. For instance, sysfs is suitable for
> exporting only small data in form of attributes, thus not suitable to export
> large data such as error states/logs/crc etc. Likewise for debugfs, which is
> not available in production kernels, and may not be best place to hold certain
> kinds of data. As a result, we currently are creating certain files in these
> filesystems, which are not particularly suited there (For, i915, guc_log is a
> case in point, which is currently created in debugfs, but not particularly
> suited there).
> 
> Due to these constraints, there is a need for a new pseudo filesytem,
> customizable to DRM specific requirements and catering to the needs to DRM
> subsystem components. This will provide a unified location to hold various
> kinds of data from Linux DRM subsystems, for the files which can't really fit
> anywhere else into the existing filesystems.
> 
> In this patch series, we have introduced a pseudo filesystem named as 'drmfs'
> for now. The filesystem is introduced in the first patch, and the subsequent
> patches make use of the filesystem interfaces, in drm driver, and making them
> available for use by the drm subsystem components, one of which is i915.
> We've moved the location of i915 GuC logs from debugfs to drmfs in the third
> patch. Subsequently, more such files such as pipe_crc, error states, memory
> stats, etc. can be move to this filesystem, if the idea introduced here is
> acceptable per se. The filesystem introduced is being used to house the data
> generated by i915 driver in this patch series, but will hopefully be generic
> enough to provide scope for usage by any other drm subsystem component.
> 
> The patch series is being floated as RFC to gather feedback on the idea and
> infrastructure proposed here and it's suitability to address the specific
> problem statement/use case.
> 
> v2: fix the bat failures caused due to missing config check

This needs to be cc'ed to dri-devel for discussion of the drmfs part.
Please cc the entire patch series so that everyone has the full context.
-Daniel

> 
> Swati Dhingra (3):
>   fs: Introduce drmfs pseudo filesystem interfaces
>   drm: Register drmfs filesystem from drm init
>   drm/i915: Creating guc log file in drmfs instead of debugfs
> 
>  drivers/gpu/drm/drm_drv.c                  |  23 ++
>  drivers/gpu/drm/i915/i915_guc_submission.c |  31 +-
>  fs/Kconfig                                 |   9 +
>  fs/Makefile                                |   1 +
>  fs/drmfs/Makefile                          |   4 +
>  fs/drmfs/inode.c                           | 561 
> +++++++++++++++++++++++++++++
>  include/drm/drm_drv.h                      |   3 +
>  include/linux/drmfs.h                      |  56 +++
>  include/uapi/linux/magic.h                 |   3 +
>  9 files changed, 670 insertions(+), 21 deletions(-)
>  create mode 100644 fs/drmfs/Makefile
>  create mode 100644 fs/drmfs/inode.c
>  create mode 100644 include/linux/drmfs.h
> 
> -- 
> 2.7.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to