From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: <tomi.valkeinen@ti.com>, <airlied@linux.ie>, <jsarha@ti.com>,
<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] drm/omap: displays: connector-hdmi: Support for hot plug detection
Date: Wed, 24 May 2017 12:14:07 +0300 [thread overview]
Message-ID: <8a447d5c-b7ed-9d1a-9865-27d0acebdb2c@ti.com> (raw)
In-Reply-To: <3265236.TtRcDxutng@avalon>
On 2017-05-23 12:45, Laurent Pinchart wrote:
> Hi Peter,
>
> Thank you for the patch.
>
> On Monday 15 May 2017 12:03:11 Peter Ujfalusi wrote:
>> If the hpd_gpio is valid, use interrupt handler to react to HPD changes.
>> In case the hpd_gpio is not valid, try to enable hpd detection on the
>> encoder if it supports it.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>> drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 104 +++++++++++++++++++
>> 1 file changed, 104 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
>> b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c index
>> 1ef130641bae..3a90f89ada77 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
>> @@ -15,6 +15,7 @@
>> #include <linux/platform_device.h>
>> #include <linux/of.h>
>> #include <linux/of_gpio.h>
>> +#include <linux/spinlock.h>
>
> Did you mean linux/mutex.h ?
Oops, yes I mean linux/mutex.h.
>> +static irqreturn_t hdmic_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 (hdmic_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);
>
> Shouldn't ddata->hpd_cb() be called without the mutex held ? I don't think
> core code should rely on callers to handle locking in this case.
the mutex is for protecting the internal data of the driver (hpd_cb
mainly). W/o keeping the mutex there might be a chance that we are going
to get an unregister call (unlikely, but in theory it can happen) which
would NULL out the hpd_cb, if we save the hpd_cb and data while holding
the mux, it is possible that the omap DRM driver was removed already
causing other type of crash.
>
>
>> + return IRQ_HANDLED;
>> +}
>> +
>> static int hdmic_probe_of(struct platform_device *pdev)
>> {
>> struct panel_drv_data *ddata = platform_get_drvdata(pdev);
>> @@ -249,11 +342,22 @@ static int hdmic_probe(struct platform_device *pdev)
>> if (r)
>> return r;
>>
>> + mutex_init(&ddata->hpd_lock);
>> +
>> if (gpio_is_valid(ddata->hpd_gpio)) {
>> r = devm_gpio_request_one(&pdev->dev, ddata->hpd_gpio,
>> GPIOF_DIR_IN, "hdmi_hpd");
>> if (r)
>> goto err_reg;
>> +
>> + r = devm_request_threaded_irq(&pdev->dev,
>> + gpio_to_irq(ddata->hpd_gpio),
>
> What is hpd_gpio is valid but has no IRQ support ?
>
>> + NULL, hdmic_hpd_isr,
>> + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
>> + IRQF_ONESHOT,
>> + "hdmic hpd", ddata);
>> + if (r)
>> + goto err_reg;
>> }
>>
>> ddata->vm = hdmic_default_vm;
>
- Péter
next prev parent reply other threads:[~2017-05-24 9:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-15 9:03 [PATCH 0/3] drm/omap: Support for hotplug detection Peter Ujfalusi
2017-05-15 9:03 ` [PATCH 1/3] drm/omap: Support for HDMI hot plug detection Peter Ujfalusi
2017-05-22 11:59 ` Tomi Valkeinen
2017-05-23 9:36 ` Laurent Pinchart
2017-05-15 9:03 ` [PATCH 2/3] drm/omap: displays: connector-hdmi: Support for " Peter Ujfalusi
2017-05-23 9:45 ` Laurent Pinchart
2017-05-24 9:14 ` Peter Ujfalusi [this message]
2017-05-15 9:03 ` [PATCH 3/3] drm/omap: displays: encoder-tpd12s015: " Peter Ujfalusi
2017-05-23 9:48 ` Laurent Pinchart
2017-05-23 10:25 ` Tomi Valkeinen
2017-05-23 10:42 ` Laurent Pinchart
2017-05-23 11:23 ` 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=8a447d5c-b7ed-9d1a-9865-27d0acebdb2c@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsarha@ti.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tomi.valkeinen@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®