[v3,0/4] Reserve DSPPs based on user request

  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(-)
  

Hi,

On Wed, Feb 8, 2023 at 5:42 AM Kalyan Thota <quic_kalyant@quicinc.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@quicinc.com/
  

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@chromium.org>
>Sent: Wednesday, February 8, 2023 10:44 PM
>To: Kalyan Thota (QUIC) <quic_kalyant@quicinc.com>
>Cc: dri-devel@lists.freedesktop.org; linux-arm-msm@vger.kernel.org;
>freedreno@lists.freedesktop.org; devicetree@vger.kernel.org; linux-
>kernel@vger.kernel.org; robdclark@chromium.org; swboyd@chromium.org;
>Vinod Polimera (QUIC) <quic_vpolimer@quicinc.com>;
>dmitry.baryshkov@linaro.org; Abhinav Kumar (QUIC)
><quic_abhinavk@quicinc.com>; marijn.suijten@somainline.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@quicinc.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@quicinc.com/
  

Hi,

On Wed, Feb 8, 2023 at 8:16 PM Kalyan Thota <kalyant@qti.qualcomm.com> wrote:
>
> 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/

I didn't pick v11 of it like you link, but I did pick v12 of the same
patch. In my response I said that I picked 5 patches, this series plus
[1] where [1] is:

[1] https://lore.kernel.org/all/1674814487-2112-1-git-send-email-quic_kalyant@quicinc.com/


> Thanks,
> Kalyan
>
> >-----Original Message-----
> >From: Doug Anderson <dianders@chromium.org>
> >Sent: Wednesday, February 8, 2023 10:44 PM
> >To: Kalyan Thota (QUIC) <quic_kalyant@quicinc.com>
> >Cc: dri-devel@lists.freedesktop.org; linux-arm-msm@vger.kernel.org;
> >freedreno@lists.freedesktop.org; devicetree@vger.kernel.org; linux-
> >kernel@vger.kernel.org; robdclark@chromium.org; swboyd@chromium.org;
> >Vinod Polimera (QUIC) <quic_vpolimer@quicinc.com>;
> >dmitry.baryshkov@linaro.org; Abhinav Kumar (QUIC)
> ><quic_abhinavk@quicinc.com>; marijn.suijten@somainline.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@quicinc.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@quicinc.com/
  

Kindly ignore my previous email. Sent too early !!

We have tested the changes on top of tip: https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/refs/heads/chromeos-5.15 + 5 CTM patches ( that you have quoted )
We didn’t see the issue that you have reported on herobrine. Night light always came up on primary display as the reservation with dspp was successful.  Are you seeing any reservation failures for primary display ?

Attached a debug patch, can you share the logs when you see the issue.

Thanks,
Kalyan

>-----Original Message-----
>From: Kalyan Thota
>Sent: Thursday, February 9, 2023 9:47 AM
>To: Doug Anderson <dianders@chromium.org>; Kalyan Thota (QUIC)
><quic_kalyant@quicinc.com>
>Cc: dri-devel@lists.freedesktop.org; linux-arm-msm@vger.kernel.org;
>freedreno@lists.freedesktop.org; devicetree@vger.kernel.org; linux-
>kernel@vger.kernel.org; robdclark@chromium.org; swboyd@chromium.org;
>Vinod Polimera (QUIC) <quic_vpolimer@quicinc.com>;
>dmitry.baryshkov@linaro.org; Abhinav Kumar (QUIC)
><quic_abhinavk@quicinc.com>; marijn.suijten@somainline.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@chromium.org>
>>Sent: Wednesday, February 8, 2023 10:44 PM
>>To: Kalyan Thota (QUIC) <quic_kalyant@quicinc.com>
>>Cc: dri-devel@lists.freedesktop.org; linux-arm-msm@vger.kernel.org;
>>freedreno@lists.freedesktop.org; devicetree@vger.kernel.org; linux-
>>kernel@vger.kernel.org; robdclark@chromium.org; swboyd@chromium.org;
>>Vinod Polimera (QUIC) <quic_vpolimer@quicinc.com>;
>>dmitry.baryshkov@linaro.org; Abhinav Kumar (QUIC)
>><quic_abhinavk@quicinc.com>; marijn.suijten@somainline.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@quicinc.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@quicinc.com/
  

Hi,

On Thu, Feb 9, 2023 at 3:26 AM Kalyan Thota <kalyant@qti.qualcomm.com> wrote:
>
> Kindly ignore my previous email. Sent too early !!
>
> We have tested the changes on top of tip: https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/refs/heads/chromeos-5.15 + 5 CTM patches ( that you have quoted )
> We didn’t see the issue that you have reported on herobrine. Night light always came up on primary display as the reservation with dspp was successful.  Are you seeing any reservation failures for primary display ?
>
> Attached a debug patch, can you share the logs when you see the issue.

Sounds good. Since officially this hardware is not available to the
public at this time, I have shared the `dmesg` privately to your (and
Abhinav's) Google partner accounts. Yell if you don't see the
notificatioin. I don't have any reason to believe there's anything
secret in the dmesg, but it didn't seem worth the time to fully audit
it.

For that dmesg, I:

1. Made sure that night light was off.

2. Updated the kernel with the 5 patches + the debug patch.

3. Booted up and logged into ChromeOS

4. Tried turning night light off/on several times and saw nothing on
dmesg while I did this (and night light didn't work)

5. Unplugged power and servo (just to make sure they didn't interfere)

6. Echoed "DOUG: plug in external display now" several times to "/dev/kmsg"

7. Plugged in my external display, which is behind a Type C dock

8. Turned night light on/off several times. Night light worked on the
internal display.

In case it matters, my ChromeOS root filesystem is R111-15328.0.0


> >-----Original Message-----
> >From: Kalyan Thota
> >Sent: Thursday, February 9, 2023 9:47 AM
> >To: Doug Anderson <dianders@chromium.org>; Kalyan Thota (QUIC)
> ><quic_kalyant@quicinc.com>
> >Cc: dri-devel@lists.freedesktop.org; linux-arm-msm@vger.kernel.org;
> >freedreno@lists.freedesktop.org; devicetree@vger.kernel.org; linux-
> >kernel@vger.kernel.org; robdclark@chromium.org; swboyd@chromium.org;
> >Vinod Polimera (QUIC) <quic_vpolimer@quicinc.com>;
> >dmitry.baryshkov@linaro.org; Abhinav Kumar (QUIC)
> ><quic_abhinavk@quicinc.com>; marijn.suijten@somainline.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@chromium.org>
> >>Sent: Wednesday, February 8, 2023 10:44 PM
> >>To: Kalyan Thota (QUIC) <quic_kalyant@quicinc.com>
> >>Cc: dri-devel@lists.freedesktop.org; linux-arm-msm@vger.kernel.org;
> >>freedreno@lists.freedesktop.org; devicetree@vger.kernel.org; linux-
> >>kernel@vger.kernel.org; robdclark@chromium.org; swboyd@chromium.org;
> >>Vinod Polimera (QUIC) <quic_vpolimer@quicinc.com>;
> >>dmitry.baryshkov@linaro.org; Abhinav Kumar (QUIC)
> >><quic_abhinavk@quicinc.com>; marijn.suijten@somainline.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@quicinc.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@quicinc.com/