[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c68e92ea-ee92-6aeb-1d51-5e265052ef43@quicinc.com>
Date: Fri, 22 Apr 2022 10:35:13 -0700
From: Abhinav Kumar <quic_abhinavk@...cinc.com>
To: Doug Anderson <dianders@...omium.org>
CC: Sankeerth Billakanti <quic_sbillaka@...cinc.com>,
quic_kalyant <quic_kalyant@...cinc.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
quic_vproddut <quic_vproddut@...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>,
Stephen Boyd <swboyd@...omium.org>,
Sean Paul <sean@...rly.run>, Sean Paul <seanpaul@...omium.org>,
Steev Klimaszewski <steev@...i.org>,
"Dmitry Baryshkov" <dmitry.baryshkov@...aro.org>,
"Aravind Venkateswaran (QUIC)" <quic_aravindh@...cinc.com>,
"Kuogee Hsieh (QUIC)" <quic_khsieh@...cinc.com>,
freedreno <freedreno@...ts.freedesktop.org>
Subject: Re: [PATCH v9 2/4] drm/msm/dp: Support only IRQ_HPD and REPLUG
interrupts for eDP
Hi Doug
On 4/22/2022 9:10 AM, Doug Anderson wrote:
> Hi,
>
> On Fri, Apr 22, 2022 at 9:05 AM Abhinav Kumar <quic_abhinavk@...cinc.com> wrote:
>>
>> Hi Doug
>>
>> For the lockdep error, the splat looks similar to what kuogee fixed
>> recently.
>>
>> Can you please check if below patch is present in your tree?
>>
>> https://patchwork.freedesktop.org/patch/481396/
>
> Indeed I did have that in my tree already, but the lockdep splat is
> still there. I think the problem is that we're now calling
> dp_hpd_plug_handle() directly in dp_bridge_enable()
>
> -Doug
Yes, now i understood this particular issue better and not sure how this
wasn't caught. Perhaps some difference in the USE flags. Sankeerth didnt
have lockdebug and thats why didnt hit this.
I have discussed with kuogee about why this change is needed and why
this wasnt being done in get_modes().
It seems like originally, this was done for a quirk in the DP compliance
equipment that it did not publish the fail safe mode ( even though some
other modes were present ). Typically, any sink (as long as EDID read
went through ) adds the 640x480 fail safe mode.
We could have done it in get_modes() even earlier but not sure how it
was missed or was there some other reason.
Nonetheless, kuogee will post the change to move this to get_modes()
shortly.
Thanks
Abhinav
Powered by blists - more mailing lists