linux-kernel - Re: [Freedreno] [PATCH v4 4/7] drm/msm/dp: Allow attaching a drm

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] [day] [month] [year] [list]

Message-ID: <CAD=FV=XxXGP+JEmi-rtW+sTS6K1fKAV79GQ61fw34QqNRwMT9Q@mail.gmail.com>
Date:   Fri, 8 Oct 2021 08:01:22 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Abhinav Kumar <abhinavk@...eaurora.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Kalyan Thota <kalyan_t@...eaurora.org>,
        Kuogee Hsieh <khsieh@...eaurora.org>,
        Rob Herring <robh+dt@...nel.org>,
        Stephen Boyd <swboyd@...omium.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        freedreno <freedreno@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Freedreno] [PATCH v4 4/7] drm/msm/dp: Allow attaching a drm_panel

Hi,

On Tue, Oct 5, 2021 at 5:35 PM <abhinavk@...eaurora.org> wrote:
>
> > +     parser->panel_bridge = devm_drm_panel_bridge_add(dev, panel);
> > +     if (IS_ERR(parser->panel_bridge)) {
> > +             DRM_ERROR("failed to create panel bridge\n");
> > +             return PTR_ERR(parser->panel_bridge);
> > +     }
>
> When we add a bridge using devm_drm_panel_bridge_add(), it will register
> with default bridge functions which is fine
> because we need the panel power to be controlled here.
>
>
> 140 static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
> 141     .attach = panel_bridge_attach,
> 142     .detach = panel_bridge_detach,
> 143     .pre_enable = panel_bridge_pre_enable,
> 144     .enable = panel_bridge_enable,
> 145     .disable = panel_bridge_disable,
> 146     .post_disable = panel_bridge_post_disable,
> 147     .get_modes = panel_bridge_get_modes,
>
> But what about the EDID related things, the DP/eDP driver already reads
> the EDID and gets the modes so we need to skip
> that in this case as otherwise it will end up calling the
> panel_get_modes in the eDP panel which will be redundant.
>
> Let me know if I am missing something in this proposal.

I haven't followed all the discussion of this patch series, but I've
been keenly involved in the EDID problem in ti-sn65dsi86. What we
ended up settling on for the TI bridge chip (ti-sn65dsi86.c) is:

1. If you have a panel, the panel driver is in charge of EDID reading.
This allows the panel to power itself up before it tries to read the
EDID.

2. The EDP controller is in charge of providing the DP AUX bus to the
panel driver.

3. If the EDP controller needs to be powered up for DP AUX bus reads
to happen, it should power itself up in the AUX bus transfer function
and use "autosuspend" to keep from turning off and on constantly.

The above not only solves the EDID problem but also allows the generic
eDP-panel code to work and also allows panels with DP AUX backlight
control to work.

For short term "getting something working", though, you could just
rely on a hardcoded mode in the panel driver for now and forget about
trying to read the EDID case for eDP.

NOTE: At the moment I think if you don't have a panel you should
continue to read the EDID in the DP driver. That could always be
changed in the future, but it was what Laurent was pushing for for
ti-sn65dsi86.c.

-Doug