[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200822093959.GD430436@ravnborg.org>
Date: Sat, 22 Aug 2020 11:39:59 +0200
From: Sam Ravnborg <sam@...nborg.org>
To: Enric Balletbo i Serra <enric.balletbo@...labora.com>
Cc: Jernej Skrabec <jernej.skrabec@...l.net>, drinkcat@...omium.org,
Jonas Karlman <jonas@...boo.se>,
David Airlie <airlied@...ux.ie>,
Neil Armstrong <narmstrong@...libre.com>,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
Andrzej Hajda <a.hajda@...sung.com>,
Boris Brezillon <boris.brezillon@...labora.com>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
hsinyi@...omium.org, matthias.bgg@...il.com,
Collabora Kernel ML <kernel@...labora.com>
Subject: Re: [PATCH 3/3] drm/bridge: ps8640: Rework power state handling
Hi Enric.
On Fri, Aug 21, 2020 at 01:38:09PM +0200, Sam Ravnborg wrote:
> Hi Enric.
>
> >
> > Let me reformulate the question for if it was not clear.
> >
> > What I did is be able to read the EDID every time userspace asks for it (so
> > kernel enables all the required) and Sam is proposing to just fail if all is not
> > setup. I can obviously do this but my question is, at which point I should leave
> > all the logic enabled to be able to read the EDID (after probe?, after
> > pre_enable, after enable?) It is not clear for me from the API.
>
> I am not clear if my suggestion is a good suggestion.
>
> I recall I saw something similar in another bridge driver.
I have noew checked - and there is several bridge drivers that
do a power_on to read get_edid - so I was mistaken. Sorry!
Sam
Powered by blists - more mailing lists