From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Andrey Smirnov <andrew.smirnov@gmail.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: <dri-devel@lists.freedesktop.org>,
Andrzej Hajda <a.hajda@samsung.com>,
Cory Tusar <cory.tusar@zii.aero>, Chris Healy <cphealy@gmail.com>,
Lucas Stach <l.stach@pengutronix.de>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/bridge: tc358767: Expose test mode functionality via debugfs
Date: Wed, 28 Aug 2019 08:48:04 +0300 [thread overview]
Message-ID: <75c9c9b2-b5b2-44bc-3ffa-e69e069cf2bd@ti.com> (raw)
In-Reply-To: <CAHQ1cqHqKvjB51UUbAHcm-=vp1O2-ncE23H8UuOz5gUJDP1wXQ@mail.gmail.com>
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
next prev parent reply other threads:[~2019-08-28 5:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-26 18:25 Andrey Smirnov
2019-08-26 22:08 ` Laurent Pinchart
2019-08-27 4:24 ` Andrey Smirnov
2019-08-27 8:06 ` Laurent Pinchart
2019-08-27 22:51 ` Andrey Smirnov
2019-08-28 5:48 ` Tomi Valkeinen [this message]
2019-08-27 5:46 ` Tomi Valkeinen
2019-08-27 22:55 ` Andrey Smirnov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=75c9c9b2-b5b2-44bc-3ffa-e69e069cf2bd@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=a.hajda@samsung.com \
--cc=andrew.smirnov@gmail.com \
--cc=cory.tusar@zii.aero \
--cc=cphealy@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=l.stach@pengutronix.de \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome