[PATCH] drm/bridge: tc358767: Expose test mode functionality via debugfs
Tomi Valkeinen
tomi.valkeinen at ti.com
Wed Aug 28 05:48:04 UTC 2019
On 28/08/2019 01:51, Andrey Smirnov wrote:
>> The whole point of a
>> driver is to avoid needing detailed knowledge of the device's internals
>> in userspace.
>>
>
> You won't avoid needing detailed knowledge of the device's internals
> if you don't have a priori knowledge in the form of a agreed upon/well
> known abstraction you are exposing from the driver. There is no such
> abstraction in this case. Whether you present "tstctl" that takes a
> magic value or "red", "green", "blue" and "pattern" taking numbers and
> special strings, as a user, you still would have to go read the driver
> code in order to figure out how that stuff works.
>
> Given how this is an obscure _debug_ feature for a niche part, I think
> exposing raw register and leaving a comment in the driver source code
> explaining how it works is reasonably user-friendly (for all 10 - 15
> unique users that this feature would ever have).
>
> To avoid any further back and forth of this subject, how about the
> following. If this is up to me, then I'd like to move forward to v2
> with the interface as is. If you feel strongly about this and insist
> on your vision of the interface, please let me know what it looks like
> (e.g. is what I described above good enough) and I'll rework v2 to
> have that.
I agree, I don't see a point in adding a pile of code to make a device
specific debug feature to hide the device internals. If someone is going
to use this feature, most likely he either has the datasheet or he has
been asked by someone with the datasheet to try the feature.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
More information about the dri-devel
mailing list