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). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
