Re: [PATCH v3 2/2] drm/bridge: tc358767: Expose test mode functionality via debugfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(Cc'ing Daniel for the last paragraph)

On 09/12/2019 07:08, Andrey Smirnov wrote:
Presently, the driver code artificially limits test pattern mode to a
single pattern with fixed color selection. It being a kernel module
parameter makes switching "test pattern" <-> "proper output" modes
on-the-fly clunky and outright impossible if the driver is built into
the kernel.

That's not correct, /sys/module/tc358767/parameters/test is there even if the driver is built-in.

I think the bigger problems are that there's just one value, even if there are multiple devices, and that with kernel parameter the driver can't act on it dynamically (afaik).

To improve the situation a bit, convert current test pattern code to
use debugfs instead by exposing "TestCtl" register. This way old
"tc_test_pattern=1" functionality can be emulated via:

     echo -n 0x78146302 > tstctl

and switch back to regular mode can be done with:

     echo -n 0x78146300 > tstctl

In the comment in the code you have 0 as return-to-regular-mode.

With my setup, enabling test mode seems to work, but when I return to regular mode, the first echo results in black display, but echoing 0 a second time will restore the display.

Hmm, actually, just echoing 0 to tstctl multiple times, it makes the screen go black and then restores it with every other echo.

+	debugfs = debugfs_create_dir(dev_name(dev), NULL);
+	if (!IS_ERR(debugfs)) {
+		debugfs_create_file_unsafe("tstctl", 0200, debugfs, tc,
+					   &tc_tstctl_fops);
+		devm_add_action_or_reset(dev, tc_remove_debugfs, debugfs);
+	}
+

For me this creates debugfs/3-000f/tstctl. I don't think that's a clear or usable path, and could even cause a name conflict in the worst case.

Not sure what's a good solution here, but only two semi-good ones come to mind: have it in sysfs under the device's dir, or debugfs/dri/something. The latter probably needs some thought and common agreement on how to handle bridge and panel debugfs files. But that would be a good thing to have, as I'm sure there are other similar cases (at least I have a few).

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux