On Tue, Jun 18, 2019 at 11:46:56PM +0200, Daniel Vetter wrote: > On Tue, Jun 18, 2019 at 08:01:13PM +0200, Greg Kroah-Hartman wrote: > > On Tue, Jun 18, 2019 at 07:32:20PM +0200, Daniel Vetter wrote: > > > On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman > > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote: > > > > > I could just "open code" a bunch of calls to debugfs_create_file() for > > > > > these drivers, which would solve this issue, but in a more "non-drm" > > > > > way. Is it worth to just do that instead of overthinking the whole > > > > > thing and trying to squish it into the drm "model" of drm debugfs calls? > > > > > > > > An example of "open coding" this is the patch below for the sor.c > > > > driver. > > > > > > I think open-coding is the way to go here. One of the todos is to > > > extend debugfs support for crtc/connectors, but looking at the > > > open-coded version we really don't need a drm-flavoured midlayer here. > > > > There already is debugfs support in the code for crtc/connectors, these > > files are "hanging" off of those locations already. I'll keep that, but > > indent it one more directory so that there's no namespace collisions. > > The todo was to have some drm wrappers here for the boilerplate, but after > looking at your version that's not a good idea. So not just making sure > crtcs/connectors have a debugfs directory made for them, but more. > > Wrt adding a new directory: debugfs isnt uapi, but there's usually a > massive pile of script relying on them, so it's not nice to shuffle paths > around. Plus the lifetimes match anyway (at least if you don't hotplug > connectors, which tegra doesn't do). So, I think you two already covered everything. From a Tegra perspective there's not really a need to care about the exact structure of debugfs because there are only a handful of scripts that use this and they are not exactly widely distributed. At the same time there's really no need to add another level of directories, since the connector really is the SOR, so an sor directory in the connector's directory is just redundant. Cleaning up and lifetime management aren't issues, really, so there are no good arguments for adding it, in my opinion. Historically, the sor.c driver is interesting because it used to be just plain debugfs calls. Only when I added a second debugfs file I decided to go with the built-in DRM infrastructure for this and then later went and converted the first file to it as well, for consistency. I do remember though that I was very unhappy about the fact that I had to do all this kmemdup()'ing just to make debugfs files per-instance (the DRM infrastructure doesn't allow that by default). In retrospect that was a poor decision and I should've just stuck with debugfs and perhaps just spin a couple of helpers around that instead. So I'm happy to see this effort. Thierry
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
