On 01-05-22, 22:41, Marijn Suijten wrote:
On 2022-04-30 22:28:42, Dmitry Baryshkov wrote:
On 30/04/2022 21:58, Marijn Suijten wrote:
On 2022-04-30 20:55:33, Dmitry Baryshkov wrote:
The downstream uses read-modify-write for updating command mode compression registers. Let's follow this approach. This also fixes the following warning:
drivers/gpu/drm/msm/dsi/dsi_host.c:918:23: warning: variable 'reg_ctrl' set but not used [-Wunused-but-set-variable]
Reported-by: kernel test robot lkp@intel.com Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration") Signed-off-by: Dmitry Baryshkov dmitry.baryshkov@linaro.org
I pointed this out in review multiple times, so you'll obviously get my:
I think I might have also pointed this out once (and then forgot to check that the issue was fixed by Vinod).
Reviewed-by: Marijn Suijten marijn.suijten@somainline.org
(But are you sure there's nothing else to clear in the 1st CTRL register, only the lowest 16 bits? That should mean `reg` never contains anything in 0xffff0000)
Judging from the downstream the upper half conains the same fields, but used for other virtual channel. I didn't research what's the difference yet. All the dtsi files that I have here at hand use 'qcom,mdss-dsi-virtual-channel-id = <0>;'
As replied to Abhinav I'm simply asking whether we should be strict and add `reg & 0xffff` to prevent accidentally writing the top 16 bits, which are stream 1. It doesn't seem like the current code can hit that though, with all the macros using masks internally already; but it's
Since the macros were used I skipped setting that up explictly...
still a little scary since we're assuming the registers for VIDEO are identical to CMD (as mentioned in the reply to Abhinav: I wonder if it's
The documentation seems to indicate they are similar and that is the reason, I merged the code paths and set different registers required for video and cmd modes