[PATCH v3 31/32] drm/exynos: Move lvds bridge discovery into DP driver

[Tomasz Figa]

Hi Inki,

On Saturday 30 of November 2013 14:18:08 Inki Dae wrote:
> Hi Tomasz,
> 
> Thanks for review,

You're welcome.

> 
> 2013/11/30 Tomasz Figa <t.figa at samsung.com>:
> > Hi Sean,
> >
> > On Tuesday 29 of October 2013 12:13:17 Sean Paul wrote:
> >> This patch moves the lvds bridge discovery and connector pre-emption
> >> code from exynos common code into the dp driver (since the bridge is
> >> only applicable for dp).
> >>
> >> Signed-off-by: Sean Paul <seanpaul at chromium.org>
> >> ---
> >>
> >> Changes in v3:
> >>       - Added to the patchset
> >>
> >>  drivers/gpu/drm/exynos/exynos_dp_core.c  | 41 ++++++++++++++++++++++++++++++++
> >>  drivers/gpu/drm/exynos/exynos_drm_core.c | 41 --------------------------------
> >>  2 files changed, 41 insertions(+), 41 deletions(-)
> >>
> >
> > Well, DRM bridge infrastructure is useful for more than just DP. Currently
> > there are several platforms that could use it with DSI as well, e.g.
> 
> In case that some board with DSI bus needs this LVDS bridge, the
> bridge type would be MIPI-DSI to LVDS Display bridge. So I think
> moving this lvds stuff into eDP driver is reasonable becasue the
> normal DSI bus cannot use this LVDS bridge, and this bridge (eDP to
> LVDS) would be for eDP bus. BTW, Sean, why not implementing this lvds
> codes to eDP driver without previous related patch? that seems
> unnecessary work.

I don't mean this particular bridge chip, but rather the bridge binding
infrastructure. Anyway, having such hacks just in the DP driver is
better than in Exynos DRM core and since we don't use DP on our platforms
it doesn't bother me that much. So, if you really insist, I'm okay with
this, just place all the bridge related code in this driver already, as
Inki suggests.

> 
> > Trats, Trats2, Arndale. With a simple abstraction worth of one or at most
> > two days of work, we could get something that would cover much more than
> > just a single Chromebook.
> 
> I also thought a better way is to use simple abstraction layer. But
> the abstraction layer I thought was the case that lvds binding is done
> in this lvds driver itself so drm connector should call some bridge
> related functions of the abstraction layer. But it seems that other
> maintainers don't agree to this way. :(
> 
> Anyway, we can say the use of lvds bridge is dependent on board but
> actually, the use of lvds bridge would be more dependent on bus device
> or lcd panel attached to the board. So my opinion is to bind dt in the
> bus or lcd panel drivers that need lvds bridge. If dt binding of lvds
> bridge cannot be done itself, Sean's way is reasonable to me except
> the unnecessary patch.

Well, I don't see why DT bindings couldn't be made for this. We already
have bindings for video-interfaces (the so called v4l2 bindings), bindings
for the LVDS bridge itself would be mostly device-specific, although we
even already have bindings for display timings.

Anyway, if even DRM people don't care, why should I? Just do what you want
as long as it doesn't break other hardware.

Best regards,
Tomasz