linux-kernel - Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+E=qVdsYV2Bxk245=Myq=otd7-7WHzUnSJN8_1dciAzvSOG8g@mail.gmail.com>
Date:   Mon, 8 Jul 2019 17:49:21 -0700
From:   Vasily Khoruzhick <anarsoul@...il.com>
To:     Maxime Ripard <maxime.ripard@...tlin.com>
Cc:     Andrzej Hajda <a.hajda@...sung.com>, Torsten Duwe <duwe@....de>,
        Harald Geyer <harald@...ib.org>, Chen-Yu Tsai <wens@...e.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Thierry Reding <thierry.reding@...il.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Icenowy Zheng <icenowy@...c.io>,
        Sean Paul <seanpaul@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        devicetree <devicetree@...r.kernel.org>,
        arm-linux <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge
 on Teres-I

On Mon, Jul 1, 2019 at 2:58 AM Maxime Ripard <maxime.ripard@...tlin.com> wrote:
>
> Hi!
>
> On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
> > On 12.06.2019 17:20, Maxime Ripard wrote:
> > >> I am not sure if I understand whole discussion here, but I also do not
> > >> understand whole edp-connector thing.
> > > The context is this one:
> > > https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
> > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
> > > https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
> > >
> > > TL;DR: This bridge is being used on ARM laptops that can come with
> > > different eDP panels. Some of these panels require a regulator to be
> > > enabled for the panel to work, and this is obviously something that
> > > should be in the DT.
> > >
> > > However, we can't really describe the panel itself, since the vendor
> > > uses several of them and just relies on the eDP bus to do its job at
> > > retrieving the EDIDs. A generic panel isn't really working either
> > > since that would mean having a generic behaviour for all the panels
> > > connected to that bus, which isn't there either.
> > >
> > > The connector allows to expose this nicely.
> >
> > As VESA presentation says[1] eDP is based on DP but is much more
> > flexible, it is up to integrator (!!!) how the connection, power
> > up/down, initialization sequence should be performed. Trying to cover
> > every such case in edp-connector seems to me similar to panel-simple
> > attempt failure. Moreover there is no such thing as physical standard
> > eDP connector. Till now I though DT connector should describe physical
> > connector on the device, now I am lost, are there some DT bindings
> > guidelines about definition of a connector?
>
> This might be semantics but I guess we're in some kind of grey area?
>
> Like, for eDP, if it's soldered I guess we could say that there's no
> connector. But what happens if for some other board, that signal is
> routed through a ribbon?
>
> You could argue that there's no physical connector in both cases, or
> that there's one in both, or one for the ribbon and no connector for
> the one soldered in.
>
> > Maybe instead of edp-connector one would introduce integrator's specific
> > connector, for example with compatible "olimex,teres-edp-connector"
> > which should follow edp abstract connector rules? This will be at least
> > consistent with below presentation[1] - eDP requirements depends on
> > integrator. Then if olimex has standard way of dealing with panels
> > present in olimex/teres platforms the driver would then create
> > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > Anyway it still looks fishy for me :), maybe because I am not
> > familiarized with details of these platforms.
>
> That makes sense yes

Actually, it makes no sense at all. Current implementation for anx6345
driver works fine as is with any panel specified assuming panel delays
are long enough for connected panel. It just doesn't use panel timings
from the driver. Creating a platform driver for connector itself looks
redundant since it can't be reused, it doesn't describe actual
hardware and it's just defeats purpose of DT by introducing
board-specific code.

There's another issue: if we introduce edp-connector we'll have to
specify power up delays somewhere (in dts? or in platform driver?), so
edp-connector doesn't really solve the issue of multiple panels with
same motherboard.

I'd say DT overlays should be preferred solution here, not another
connector binding.

> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com