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
