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.
> 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
> Intel-gfx mailing list
Software Engineer, Intel Corporation
Intel-gfx mailing list