linux-kernel - Re: [PATCH v5 4/4] arm64: dts: qcom: Add Acer Aspire 1

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: <476b27c4a77118837931dc65ab511d75@trvn.ru>
Date:   Sat, 08 Apr 2023 12:50:52 +0500
From:   Nikita Travkin <nikita@...n.ru>
To:     Doug Anderson <dianders@...omium.org>
Cc:     agross@...nel.org, andersson@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, konrad.dybcio@...aro.org,
        quic_srivasam@...cinc.com, judyhsiao@...omium.org,
        mka@...omium.org, cros-qcom-dts-watchers@...omium.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH v5 4/4] arm64: dts: qcom: Add Acer Aspire 1

Doug Anderson писал(а) 07.04.2023 22:06:
> Hi,
> 
> On Fri, Apr 7, 2023 at 9:46 AM Nikita Travkin <nikita@...n.ru> wrote:
>>
>> > HPD might very well be hooked up on your board, but the current Linux
>> > ti-sn65dsi86 driver does not look at its own HPD line because it's
>> > actually slower than just pretending that HPD isn't there. On trogdor
>> > boards we ended up routing HPD to a GPIO.
>> >
>>
>> Oh, this makes so much sense then! The line is hooked up on
>> the board indeed and I remember being confused why trogdor boards
>> don't use it.
>>
>> I will try to add the suggestions (annotating the reason)
>> and verify that it works, would prefer the panel power to be
>> gated when possible. I hope this would also fix the initial
>> EDID reading issues I occasionally have and carry a hack for
>> as of now...
>>
>> Thank you a lot for this insight!
>>
>> Nikita
>>
>> > I guess your other option would be to implement HPD support in
>> > ti-sn65dsi86. That would probably be an overall slower boot for you,
>> > but is technically more correct. In the past people have posted up
>> > patches to get ti-sn65dsi86 working as a full DP port and they added
>> > HPD support for that, but none of those patch series ever go to the
>> > point of landing...
> 
> Yeah, see the big comment in ti_sn65dsi86_enable_comms().
> 
> Actually, looking at how the code has evolved in the meantime, you
> could probably get away with:
> 
> 1. Making sure you have an "hpd-absent-delay-ms" in the device tree
> for the panel.
> 
> 2. Implement "wait_hpd_asserted" in ti-sn65dsi86 to simply be a msleep
> with the passed in delay.
> 
> Then I think you don't need "no-hpd" anywhere which keeps the device
> tree pretty.
> 

Yes, implementing a dummy wait_hpd_asserted seems to indeed fix my
issues here. (Can actually see the panel dying for 200ms on boot
due to the violent takeover if the backlight driver was not built
in, so had to change my kernel config a little)

Will have the "hpd-absent-delay-ms" in v6 and submit a driver fix
alongside it.

Thanks!
Nikita

> 
> -Doug