Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Yakir Yang <ykk@rock-chips.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3023 bytes --]

Hi Thierry,

在 09/03/2015 05:04 PM, Thierry Reding 写道:
> On Thu, Sep 03, 2015 at 12:27:47PM +0800, Yakir Yang wrote:
>> Hi Rob,
>>
>> 在 09/03/2015 04:17 AM, Rob Herring 写道:
>>> On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang <ykk@rock-chips.com> wrote:
>>>> Some edp screen do not have hpd signal, so we can't just return
>>>> failed when hpd plug in detect failed.
>>> This is a property of the panel (or connector perhaps), so this
>>> property should be located there. At least, it is a common issue and
>>> not specific to this chip. We could have an HDMI connector and failed
>>> to hook up HPD for example. A connector node is also where hpd-gpios
>>> should be located instead (and are already defined by
>>> ../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector
>>> binding, too.
>> Yep, I agree with your front point, it is a property of panel, not specific
>> to eDP controller, so this code should handle in connector logic.
>  From your description it sounds more like this is in fact a property of
> the panel. Or maybe I should say "quirk". If the panel doesn't generate
> the HPD signal, then that should be a property of the panel, not the
> connector. The eDP specification mandates that connectors have a HPD
> signal, though it allows the "HPD conductor in the connector cable" to
> be omitted if not used by the source. I'd consider the cable to belong
> to the panel rather than the connector, so absence of HPD, either
> because the cable doesn't have the conductor or because the panel does
> not generate the signal, should be a quirk of the panel.
>
> That said you could have a panel that supports HPD connected via a cable
> that doesn't transmit it, so this would be a per-board variant and hence
> should be a device tree property rather than hard-coded in some panel
> driver.
>
> Conversely, if the panel isn't capable of generating an HPD signal, then
> I don't think it would be appropriate to make it a DT property. It would
> be better to hard-code it in the driver, lest someone forget to set the
> property in DT and get stuck with a device that isn't operational.

Oh, you're right, if it's a cable quirk, then DT property would be okay, 
if it
is a problem of panel, then maybe hard-code in driver would be better.

After look up for the document of panel "innolux,n116bge", I haven't see
any description of hot plug signal, and even not found in PIN ASSIGNMENT.
So I believe it's a panel problem, that's to say it should handle in 
panel driver.

Hmm... But I don't know how to cover the whole hpd situation in panel 
detect,
it looks complicate  *_*

And Russell have remind that DRM .force is another way to handle this one,
but I haven't understand it very well. I see we need make connector->force =
DRM_FORCE_ON, then we can enable eDP in connector->funcs->force(). But
I don't how to handle connector->force automatically without DT property,
could some guys help here    :-D

Thanks,
- Yakir

[-- Attachment #1.2: Type: text/html, Size: 4013 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel