Hi, On Thu, Feb 9, 2023 at 3:26 AM Kalyan Thota <kaly...@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 <diand...@chromium.org>; Kalyan Thota (QUIC) > ><quic_kaly...@quicinc.com> > >Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org; > >freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux- > >ker...@vger.kernel.org; robdcl...@chromium.org; swb...@chromium.org; > >Vinod Polimera (QUIC) <quic_vpoli...@quicinc.com>; > >dmitry.barysh...@linaro.org; Abhinav Kumar (QUIC) > ><quic_abhin...@quicinc.com>; marijn.suij...@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_kaly...@quicinc.com/ > > > >Thanks, > >Kalyan > > > >>-----Original Message----- > >>From: Doug Anderson <diand...@chromium.org> > >>Sent: Wednesday, February 8, 2023 10:44 PM > >>To: Kalyan Thota (QUIC) <quic_kaly...@quicinc.com> > >>Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org; > >>freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux- > >>ker...@vger.kernel.org; robdcl...@chromium.org; swb...@chromium.org; > >>Vinod Polimera (QUIC) <quic_vpoli...@quicinc.com>; > >>dmitry.barysh...@linaro.org; Abhinav Kumar (QUIC) > >><quic_abhin...@quicinc.com>; marijn.suij...@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_kaly...@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_kaly...@quicinc.com/
