linux-kernel - Re: [Freedreno] [PATCH] drm/msm/dp: move add fail safe mode to dp_connector_get

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]

Date:   Tue, 26 Apr 2022 11:48:02 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Abhinav Kumar <quic_abhinavk@...cinc.com>
Cc:     freedreno <freedreno@...ts.freedesktop.org>,
        Sankeerth Billakanti <quic_sbillaka@...cinc.com>,
        David Airlie <airlied@...ux.ie>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Kuogee Hsieh <quic_khsieh@...cinc.com>,
        Vinod Koul <vkoul@...nel.org>, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        "Aravind Venkateswaran (QUIC)" <quic_aravindh@...cinc.com>,
        Stephen Boyd <swboyd@...omium.org>, Sean Paul <sean@...rly.run>
Subject: Re: [Freedreno] [PATCH] drm/msm/dp: move add fail safe mode to dp_connector_get_mode()

Hi,

On Tue, Apr 26, 2022 at 8:37 AM Abhinav Kumar <quic_abhinavk@...cinc.com> wrote:
>
> > Can you provide the exact EDID from the failing test case? Maybe that
> > will help shed some light on what's going on. I looked at the original
> > commit and it just referred to 4.2.2.1, which I assume is "EDID Read
> > upon HPD Plug Event", but that doesn't give details that seem relevant
> > to the discussion here.
>
> Yes so it is 4.2.2.1 and 4.2.2.6.
>
> That alone wont give the full picture.
>
> So its a combination of things.
>
> While running the test, the test equipment published only one mode.
> But we could not support that mode because of 2 lanes.
> Equipment did not add 640x480 to the list of modes.
> DRM fwk will also not add it because count_modes is not 0 ( there was
> one mode ).
> So we ended up making these changes.

Ah! This is useful context and makes tons of sense.

This really feels like something that could be handled in the core. OK, See:

https://lore.kernel.org/r/20220426114627.2.I4ac7f55aa446699f8c200a23c10463256f6f439f@changeid


> > I guess maybe what's happening is that the test case is giving an EDID
> > where all the modes are not supportable by the current clock rate /
> > lanes? ...and then somehow we're not falling back to 640x480. It's
> > always possible that this is a userspace problem.
> >
> > In any case, would you object to a revert of the patches in the short term?
>
> Not sure, if you saw this change kuogee posted last night.
> https://patchwork.freedesktop.org/patch/483415/
> We did decided to remove all the code related to these test cases and
> handle them in IGT.

I hadn't seen it yet and I wasn't CCed. :( I'll take a look now.