> tc358767 driver doesn't have any HPD handling at the moment, as it was
> originally developed to support only eDP.
> This patch implements a naive, polling-based HPD handling, which is used
> when the driver is in DP mode.
> Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>
> ---
> drivers/gpu/drm/bridge/tc358767.c | 56 +++++++++++++++++++++----------
> 1 file changed, 38 insertions(+), 18 deletions(-)
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index 8606de29c9b2..2b252f7ac070 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1095,6 +1095,12 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
> struct tc_data *tc = bridge_to_tc(bridge);
> int ret;
> + ret = tc_get_display_props(tc);
> + if (ret < 0) {
> + dev_err(tc->dev, "failed to read display props: %d\n", ret);
> + return;
> + }
> +
> ret = tc_main_link_enable(tc);
> if (ret < 0) {
> dev_err(tc->dev, "main link enable error: %d\n", ret);
> @@ -1200,19 +1206,35 @@ static int tc_connector_get_modes(struct
> drm_connector *connector)
> return count;
> }
> -static void tc_connector_set_polling(struct tc_data *tc,
> - struct drm_connector *connector)
> -{
> - /* TODO: add support for HPD */
> - connector->polled = DRM_CONNECTOR_POLL_CONNECT |
> - DRM_CONNECTOR_POLL_DISCONNECT;
> -}
> -
> static const struct drm_connector_helper_funcs tc_connector_helper_funcs = {
> .get_modes = tc_connector_get_modes,
> };
> +static enum drm_connector_status tc_connector_detect(struct drm_connector
> *connector, bool force)
> +{
> + struct tc_data *tc = connector_to_tc(connector);
> + u32 val;
> + int ret;
> + bool conn;
> +
> + tc_read(GPIOI, &val);
> +
> + conn = val & BIT(0);
TC358767 has two GPIO pins that can be used for HPD signal. I think
instead of hardcoding GPIO0 here it would be more flexible to expose
boths gpios as a gpiochip and use gpiolib API to query the value of
HPD as well as use "hpd-gpios" binidng in DT to select which input to
use.
Another argument in favour of this solution is that Toshiba's FAEs (at
least some) recommend thier customers to connect HPD signal to SoC's
GPIOs and bypass TC358767 entirely. Their reasoning being that
TC358767 implements a generic GPIO contoller and there's no advantage
in going through TC358767 if you could use your "normal" GPIOs.
Using gpiolib API would allow us to handle both usecase with the same
code.
Lastly, by treating "hpd-gpios" as an optional property, we can
preserve old driver behaviour regardless if it is connected to DP or
eDP panel. Not saying that this is really worth doing, just pointing
out that this option would be on the table as well.
Thanks,
Andrey Smirnov
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
