Hi,
On Mon, Apr 11, 2022 at 1:34 AM Jani Nikula jani.nikula@linux.intel.com wrote:
On Fri, 08 Apr 2022, Douglas Anderson dianders@chromium.org wrote:
As talked about in the kerneldoc for "struct dp_aux_ep_client" in this patch and also in the past in commit a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev"), to use the DP AUX bus properly we really need two "struct device"s. One "struct device" is in charge of providing the DP AUX bus and the other is where we'll try to get a reference to the newly probed endpoint devices.
In ti-sn65dsi86 this wasn't too difficult to accomplish. That driver is already broken up into several "struct devices" anyway because it also provides a PWM and some GPIOs. Adding one more wasn't that difficult / ugly.
When I tried to do the same solution in parade-ps8640, it felt like I was copying too much boilerplate code. I made the realization that I didn't _really_ need a separate "driver" for each person that wanted to do the same thing. By putting all the "driver" related code in a common place then we could save a bit of hassle. This change effectively adds a new "ep_client" driver that can be used by anyone. The devices instantiated by this driver will just call through to the probe/remove/shutdown calls provided.
At the moment, the "ep_client" driver is backed by the Linux auxiliary bus (unfortunate naming--this has nothing to do with DP AUX). I didn't want to expose this to clients, though, so as far as clients are concerned they get a vanilla "struct device".
Signed-off-by: Douglas Anderson dianders@chromium.org
What is an "EP" client or device?
The DP AUX EndPoint (or DP AUX EP) is just the generic name I called the thing on the other side of the DP AUX bus, AKA the "panel".
The "DP AUX EP client" (ep_client) is the code that needs a reference to the panel.
I'll beef up the patch description and the comments around the structure to try to make this clearer.
-Doug