All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Jyri Sarha <jsarha@ti.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 03/24] drm/omap: add HPD support to connector-dvi
Date: Wed, 28 Feb 2018 11:00:07 +0200	[thread overview]
Message-ID: <24faef29-f192-77c4-62db-2a8ee1dfa442@ti.com> (raw)
In-Reply-To: <6068777.X8XE7Hrmi7@avalon>

On 27/02/18 14:58, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Monday, 12 February 2018 11:44:33 EET Tomi Valkeinen wrote:
>> Add HPD support to the DVI connector driver. The code is almost
>> identical to the HPD code in the HDMI connector driver.
> 
> Would it make sense to share a single implementation then ? Or is that an 
> exercise left for the reader (that is, me) ? :-)

It would, but I suspect all these will go away soon with the
drm_bridge/panel work, so I didn't want to start doing a bigger refactoring.

>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>>  drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 114 ++++++++++++++++++++
>>  1 file changed, 114 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
>> b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c index
>> 391d80364346..f9f8700223c3 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
>> @@ -13,6 +13,7 @@
>>  #include <linux/module.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/slab.h>
>> +#include <linux/gpio/consumer.h>
> 
> Could you please keep headers alphabetically sorted ?

Sure.

>>  #include <drm/drm_edid.h>
>>
>> @@ -44,6 +45,13 @@ struct panel_drv_data {
>>  	struct videomode vm;
>>
>>  	struct i2c_adapter *i2c_adapter;
>> +
>> +	struct gpio_desc *hpd_gpio;
>> +
>> +	void (*hpd_cb)(void *cb_data, enum drm_connector_status status);
>> +	void *hpd_cb_data;
>> +	bool hpd_enabled;
>> +	struct mutex hpd_lock;
> 
> Locks should have a comment that describes which fields they protect.

Added.
>>  };
>>
>>  #define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
>> @@ -189,6 +197,9 @@ static int dvic_read_edid(struct omap_dss_device
>> *dssdev, struct panel_drv_data *ddata = to_panel_data(dssdev);
>>  	int r, l, bytes_read;
>>
>> +	if (ddata->hpd_gpio && !gpiod_get_value_cansleep(ddata->hpd_gpio))
>> +		return -ENODEV;
>> +
>>  	if (!ddata->i2c_adapter)
>>  		return -ENODEV;
>>
>> @@ -220,6 +231,9 @@ static bool dvic_detect(struct omap_dss_device *dssdev)
>>  	unsigned char out;
>>  	int r;
>>
>> +	if (ddata->hpd_gpio)
>> +		return gpiod_get_value_cansleep(ddata->hpd_gpio);
>> +
>>  	if (!ddata->i2c_adapter)
>>  		return true;
>>
>> @@ -228,6 +242,60 @@ static bool dvic_detect(struct omap_dss_device *dssdev)
>> return r == 0;
>>  }
>>
>> +static int dvic_register_hpd_cb(struct omap_dss_device *dssdev,
>> +				 void (*cb)(void *cb_data,
>> +					    enum drm_connector_status status),
>> +				 void *cb_data)
>> +{
>> +	struct panel_drv_data *ddata = to_panel_data(dssdev);
>> +
>> +	if (!ddata->hpd_gpio)
>> +		return -ENOTSUPP;
>> +
>> +	mutex_lock(&ddata->hpd_lock);
>> +	ddata->hpd_cb = cb;
>> +	ddata->hpd_cb_data = cb_data;
>> +	mutex_unlock(&ddata->hpd_lock);
>> +	return 0;
>> +}
>> +
>> +static void dvic_unregister_hpd_cb(struct omap_dss_device *dssdev)
>> +{
>> +	struct panel_drv_data *ddata = to_panel_data(dssdev);
>> +
>> +	if (!ddata->hpd_gpio)
>> +		return;
>> +
>> +	mutex_lock(&ddata->hpd_lock);
>> +	ddata->hpd_cb = NULL;
>> +	ddata->hpd_cb_data = NULL;
>> +	mutex_unlock(&ddata->hpd_lock);
>> +}
>> +
>> +static void dvic_enable_hpd(struct omap_dss_device *dssdev)
>> +{
>> +	struct panel_drv_data *ddata = to_panel_data(dssdev);
>> +
>> +	if (!ddata->hpd_gpio)
>> +		return;
>> +
>> +	mutex_lock(&ddata->hpd_lock);
>> +	ddata->hpd_enabled = true;
>> +	mutex_unlock(&ddata->hpd_lock);
>> +}
>> +
>> +static void dvic_disable_hpd(struct omap_dss_device *dssdev)
>> +{
>> +	struct panel_drv_data *ddata = to_panel_data(dssdev);
>> +
>> +	if (!ddata->hpd_gpio)
>> +		return;
>> +
>> +	mutex_lock(&ddata->hpd_lock);
>> +	ddata->hpd_enabled = false;
>> +	mutex_unlock(&ddata->hpd_lock);
>> +}
>> +
>>  static struct omap_dss_driver dvic_driver = {
>>  	.connect	= dvic_connect,
>>  	.disconnect	= dvic_disconnect,
>> @@ -241,14 +309,60 @@ static struct omap_dss_driver dvic_driver = {
>>
>>  	.read_edid	= dvic_read_edid,
>>  	.detect		= dvic_detect,
>> +
>> +	.register_hpd_cb	= dvic_register_hpd_cb,
>> +	.unregister_hpd_cb	= dvic_unregister_hpd_cb,
>> +	.enable_hpd		= dvic_enable_hpd,
>> +	.disable_hpd		= dvic_disable_hpd,
>>  };
>>
>> +static irqreturn_t dvic_hpd_isr(int irq, void *data)
>> +{
>> +	struct panel_drv_data *ddata = data;
>> +
>> +	mutex_lock(&ddata->hpd_lock);
>> +	if (ddata->hpd_enabled && ddata->hpd_cb) {
>> +		enum drm_connector_status status;
>> +
>> +		if (dvic_detect(&ddata->dssdev))
>> +			status = connector_status_connected;
>> +		else
>> +			status = connector_status_disconnected;
>> +
>> +		ddata->hpd_cb(ddata->hpd_cb_data, status);
>> +	}
>> +	mutex_unlock(&ddata->hpd_lock);
>> +
>> +	return IRQ_HANDLED;
>> +}
>> +
>>  static int dvic_probe_of(struct platform_device *pdev)
>>  {
>>  	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
>>  	struct device_node *node = pdev->dev.of_node;
>>  	struct device_node *adapter_node;
>>  	struct i2c_adapter *adapter;
>> +	struct gpio_desc *gpio;
>> +	int r;
>> +
>> +	gpio = devm_gpiod_get_optional(&pdev->dev, "hpd", GPIOD_IN);
>> +	if (IS_ERR(gpio)) {
>> +		dev_err(&pdev->dev, "failed to parse HPD gpio\n");
>> +		return PTR_ERR(gpio);
>> +	}
>> +
>> +	ddata->hpd_gpio = gpio;
>> +
>> +	mutex_init(&ddata->hpd_lock);
> 
> Shouldn't you also have a mutex_destroy ?

Yep. Interestingly, we don't destroy any of the mutexes in omapdss/drm.
Luckily mutex_destroy doesn't seem to do much (just for debug purposes),
but still, we need to add those at some point.

 Tomi

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

  reply	other threads:[~2018-02-28  9:00 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-12  9:44 [PATCH 00/24] drm/omap: misc patches Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 01/24] drm/omap: fix omap_fbdev_free() when omap_fbdev_create() wasn't called Tomi Valkeinen
2018-02-27 11:28   ` Laurent Pinchart
2018-02-27 11:53     ` Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 02/24] drm/omap: cleanup fbdev init/free Tomi Valkeinen
2018-02-27 11:38   ` Laurent Pinchart
2018-02-28  8:49     ` Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 03/24] drm/omap: add HPD support to connector-dvi Tomi Valkeinen
2018-02-27 12:58   ` Laurent Pinchart
2018-02-28  9:00     ` Tomi Valkeinen [this message]
     [not found] ` <1518428694-18018-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2018-02-12  9:44   ` [PATCH 04/24] dt-bindings: display: add HPD gpio to DVI connector Tomi Valkeinen
2018-02-19  0:11     ` Rob Herring
2018-02-27 13:01     ` Laurent Pinchart
2018-02-12  9:44 ` [PATCH 05/24] drm/omap: Use devm_kzalloc() to allocate omap_drm_private Tomi Valkeinen
2018-02-27 13:03   ` Laurent Pinchart
2018-02-12  9:44 ` [PATCH 06/24] drm/omap: Allocate drm_device earlier and unref it as last step Tomi Valkeinen
2018-02-27 13:07   ` Laurent Pinchart
2018-02-12  9:44 ` [PATCH 07/24] drm/omap: Manage the usable omap_dss_device list within omap_drm_private Tomi Valkeinen
2018-02-27 13:19   ` Laurent Pinchart
2018-02-12  9:44 ` [PATCH 08/24] drm/omap: Separate the dssdevs array setup from the connect function Tomi Valkeinen
2018-02-27 13:23   ` Laurent Pinchart
2018-02-12  9:44 ` [PATCH 09/24] drm/omap: Do dss_device (display) ordering in omap_drv.c Tomi Valkeinen
2018-02-27 13:26   ` Laurent Pinchart
2018-02-12  9:44 ` [PATCH 10/24] drm/omap: dss: Remove display ordering from dss/display.c Tomi Valkeinen
2018-02-27 13:30   ` Laurent Pinchart
2018-02-12  9:44 ` [PATCH 11/24] drm/omap: Add kernel parameter to specify the desired display order Tomi Valkeinen
2018-02-27 13:35   ` Laurent Pinchart
2018-02-28  9:16     ` Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 12/24] drm/omap: Init fbdev emulation only when we have displays Tomi Valkeinen
2018-02-27 13:36   ` Laurent Pinchart
2018-02-12  9:44 ` [PATCH 13/24] drm/omap: remove leftover enums Tomi Valkeinen
2018-02-27 13:36   ` Laurent Pinchart
2018-02-12  9:44 ` [PATCH 14/24] drm/omap: dispc: disp_wb_setup to check return code Tomi Valkeinen
2018-02-27 13:38   ` Laurent Pinchart
2018-02-12  9:44 ` [PATCH 15/24] drm/omap: Add pclk setting case when channel is DSS_WB Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 16/24] drm/omap: set WB channel-in in wb_setup() Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 17/24] drm/omap: fix WBDELAYCOUNT for HDMI Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 18/24] drm/omap: fix WBDELAYCOUNT with interlace Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 19/24] drm/omap: fix WB height " Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 20/24] drm/omap: fix scaling limits for WB Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 21/24] drm/omap: add writeback funcs to dispc_ops Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 22/24] drm/omap: fix maximum sizes Tomi Valkeinen
2018-02-27 13:42   ` Laurent Pinchart
2018-02-28  9:10     ` Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 23/24] drm/omap: Allow HDMI audio setup even if we do not have video configured Tomi Valkeinen
2018-02-12  9:44 ` [PATCH 24/24] drm/omap: cleanup color space conversion Tomi Valkeinen
2018-02-27 14:08   ` Laurent Pinchart
2018-02-28 10:09     ` Tomi Valkeinen
2018-02-28 10:13       ` Laurent Pinchart
2018-02-28 10:22         ` Tomi Valkeinen

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=24faef29-f192-77c4-62db-2a8ee1dfa442@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jsarha@ti.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=peter.ujfalusi@ti.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.