linux-kernel - RE: [PATCH v3 0/4] Reserve DSPPs based on user request

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]

Date:   Thu, 9 Feb 2023 04:16:41 +0000
From:   Kalyan Thota <kalyant@....qualcomm.com>
To:     Doug Anderson <dianders@...omium.org>,
        "Kalyan Thota (QUIC)" <quic_kalyant@...cinc.com>
CC:     "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "freedreno@...ts.freedesktop.org" <freedreno@...ts.freedesktop.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "robdclark@...omium.org" <robdclark@...omium.org>,
        "swboyd@...omium.org" <swboyd@...omium.org>,
        "Vinod Polimera (QUIC)" <quic_vpolimer@...cinc.com>,
        "dmitry.baryshkov@...aro.org" <dmitry.baryshkov@...aro.org>,
        "Abhinav Kumar (QUIC)" <quic_abhinavk@...cinc.com>,
        "marijn.suijten@...ainline.org" <marijn.suijten@...ainline.org>
Subject: RE: [PATCH v3 0/4] Reserve DSPPs based on user request

Hi Doug,

Have you picked the core change to program dspp's  (below) ? the current series will go on top of it.
https://patchwork.kernel.org/project/linux-arm-msm/patch/1671542719-12655-1-git-send-email-quic_kalyant@quicinc.com/

Thanks,
Kalyan

>-----Original Message-----
>From: Doug Anderson <dianders@...omium.org>
>Sent: Wednesday, February 8, 2023 10:44 PM
>To: Kalyan Thota (QUIC) <quic_kalyant@...cinc.com>
>Cc: dri-devel@...ts.freedesktop.org; linux-arm-msm@...r.kernel.org;
>freedreno@...ts.freedesktop.org; devicetree@...r.kernel.org; linux-
>kernel@...r.kernel.org; robdclark@...omium.org; swboyd@...omium.org;
>Vinod Polimera (QUIC) <quic_vpolimer@...cinc.com>;
>dmitry.baryshkov@...aro.org; Abhinav Kumar (QUIC)
><quic_abhinavk@...cinc.com>; marijn.suijten@...ainline.org
>Subject: Re: [PATCH v3 0/4] Reserve DSPPs based on user request
>
>WARNING: This email originated from outside of Qualcomm. Please be wary of
>any links or attachments, and do not enable macros.
>
>Hi,
>
>On Wed, Feb 8, 2023 at 5:42 AM Kalyan Thota <quic_kalyant@...cinc.com>
>wrote:
>>
>> This series will enable color features on sc7280 target which has
>> primary panel as eDP
>>
>> The series removes DSPP allocation based on encoder type and allows
>> the DSPP reservation based on user request via CTM.
>>
>> The series will release/reserve the dpu resources when ever there is a
>> topology change to suit the new requirements.
>>
>> Kalyan Thota (4):
>>   drm/msm/dpu: clear DSPP reservations in rm release
>>   drm/msm/dpu: add DSPPs into reservation upon a CTM request
>>   drm/msm/dpu: avoid unnecessary check in DPU reservations
>>   drm/msm/dpu: reserve the resources on topology change
>>
>>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h    |  2 +
>>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 58 ++++++++++++++++------
>-------
>>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c      |  2 +
>>  3 files changed, 37 insertions(+), 25 deletions(-)
>
>I tried out your changes, but unfortunately it seems like there's something wrong.
>:( I did this:
>
>1. Picked your 5 patches to the chromeos-5.15 tree (this series plus [1])
>
>2. Put them on herobrine villager.
>
>3. Booted up with no external display plugged in.
>
>4. Tried to enable night light in the ChromeOS UI.
>
>5. Night light didn't turn on for the internal display.
>
>
>I also tried applying them to the top of msm-next (had to resolve some small
>conflicts). Same thing, night light didn't work.
>
>
>I thought maybe this was because the Chrome browser hasn't been updated to
>properly use atomic_check for testing for night light, so I hacked my herobrine
>device tree to not mark "mdss_dp" as "okay". Now there's _only_ an eDP display.
>Same thing, night light didn't work.
>
>
>I could only get night light to work for the internal display if I plugged and
>unplugged an external display in.
>
>
>Is the above the behavior that's expected right now?
>
>
>[1] https://lore.kernel.org/all/1674814487-2112-1-git-send-email-
>quic_kalyant@...cinc.com/