From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
dri-devel@lists.freedesktop.org, jsarha@ti.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] drm/omap: displays: encoder-tpd12s015: Support for hot plug detection
Date: Tue, 23 May 2017 13:42:25 +0300 [thread overview]
Message-ID: <2146476.yg7iIlQTUW@avalon> (raw)
In-Reply-To: <7be9f55e-7d81-d9c8-9e30-1ddc284137e3@ti.com>
Hi Tomi,
On Tuesday 23 May 2017 13:25:34 Tomi Valkeinen wrote:
> On 23/05/17 12:48, Laurent Pinchart wrote:
> > As the connector code can handle GPIO HPD thanks to patch 2/3, why does it
> > have to be duplicated here ? I agree that encoders should support
> > reporting of hotplug events when the HPD signal is connected to an
> > encoder, but if it's connected to a GPIO, it seems to me that it should
> > be the sole responsibility of the connector code to handle it.
>
> The HPD line goes from the connector to TPD12S015. From TPD12S015
> another line goes to the SoCs GPIO.
Isn't it the same signal, just with glitches filtered ? The TPD12S015 is an
ESD clamp, level shifter and DC-DC converter, if it wasn't for the two control
inputs CT_CP_HPD and LS_OE, we could probably do without a driver. I wouldn't
add HPD support to this driver, as the chip really can't detect HPD.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
airlied@linux.ie, jsarha@ti.com, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] drm/omap: displays: encoder-tpd12s015: Support for hot plug detection
Date: Tue, 23 May 2017 13:42:25 +0300 [thread overview]
Message-ID: <2146476.yg7iIlQTUW@avalon> (raw)
In-Reply-To: <7be9f55e-7d81-d9c8-9e30-1ddc284137e3@ti.com>
Hi Tomi,
On Tuesday 23 May 2017 13:25:34 Tomi Valkeinen wrote:
> On 23/05/17 12:48, Laurent Pinchart wrote:
> > As the connector code can handle GPIO HPD thanks to patch 2/3, why does it
> > have to be duplicated here ? I agree that encoders should support
> > reporting of hotplug events when the HPD signal is connected to an
> > encoder, but if it's connected to a GPIO, it seems to me that it should
> > be the sole responsibility of the connector code to handle it.
>
> The HPD line goes from the connector to TPD12S015. From TPD12S015
> another line goes to the SoCs GPIO.
Isn't it the same signal, just with glitches filtered ? The TPD12S015 is an
ESD clamp, level shifter and DC-DC converter, if it wasn't for the two control
inputs CT_CP_HPD and LS_OE, we could probably do without a driver. I wouldn't
add HPD support to this driver, as the chip really can't detect HPD.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2017-05-23 10:42 UTC|newest]
Thread overview: 24+ 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 ` Peter Ujfalusi
2017-05-15 9:03 ` [PATCH 1/3] drm/omap: Support for HDMI hot plug detection Peter Ujfalusi
2017-05-15 9:03 ` Peter Ujfalusi
2017-05-22 11:59 ` Tomi Valkeinen
2017-05-22 11:59 ` Tomi Valkeinen
2017-05-23 9:36 ` Laurent Pinchart
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-15 9:03 ` Peter Ujfalusi
2017-05-23 9:45 ` Laurent Pinchart
2017-05-23 9:45 ` Laurent Pinchart
2017-05-24 9:14 ` Peter Ujfalusi
2017-05-24 9:14 ` Peter Ujfalusi
2017-05-15 9:03 ` [PATCH 3/3] drm/omap: displays: encoder-tpd12s015: " Peter Ujfalusi
2017-05-15 9:03 ` Peter Ujfalusi
2017-05-23 9:48 ` Laurent Pinchart
2017-05-23 9:48 ` Laurent Pinchart
2017-05-23 10:25 ` Tomi Valkeinen
2017-05-23 10:25 ` Tomi Valkeinen
2017-05-23 10:42 ` Laurent Pinchart [this message]
2017-05-23 10:42 ` Laurent Pinchart
2017-05-23 11:23 ` Tomi Valkeinen
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=2146476.yg7iIlQTUW@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsarha@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.ujfalusi@ti.com \
--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 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.