From: Vinod Koul <vkoul@kernel.org>
To: Marijn Suijten <marijn.suijten@somainline.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Stephen Boyd <swboyd@chromium.org>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v2] drm/msm/dsi: use RMW cycles in dsi_update_dsc_timing
Date: Wed, 4 May 2022 19:08:30 +0530 [thread overview]
Message-ID: <YnKB1nYLSVUSbSUJ@matsya> (raw)
In-Reply-To: <20220501204102.3xijmadbcrxwyu3x@SoMainline.org>
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
--
~Vinod
WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vkoul@kernel.org>
To: Marijn Suijten <marijn.suijten@somainline.org>
Cc: freedreno@lists.freedesktop.org,
kernel test robot <lkp@intel.com>,
David Airlie <airlied@linux.ie>,
linux-arm-msm@vger.kernel.org,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
dri-devel@lists.freedesktop.org,
Stephen Boyd <swboyd@chromium.org>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Sean Paul <sean@poorly.run>
Subject: Re: [PATCH v2] drm/msm/dsi: use RMW cycles in dsi_update_dsc_timing
Date: Wed, 4 May 2022 19:08:30 +0530 [thread overview]
Message-ID: <YnKB1nYLSVUSbSUJ@matsya> (raw)
In-Reply-To: <20220501204102.3xijmadbcrxwyu3x@SoMainline.org>
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
--
~Vinod
next prev parent reply other threads:[~2022-05-04 13:38 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-30 17:55 [PATCH v2] drm/msm/dsi: use RMW cycles in dsi_update_dsc_timing Dmitry Baryshkov
2022-04-30 17:55 ` Dmitry Baryshkov
2022-04-30 18:42 ` Abhinav Kumar
2022-04-30 18:42 ` Abhinav Kumar
2022-04-30 18:58 ` Marijn Suijten
2022-04-30 18:58 ` Marijn Suijten
2022-04-30 19:25 ` [Freedreno] " Abhinav Kumar
2022-04-30 19:25 ` Abhinav Kumar
2022-05-01 20:06 ` Marijn Suijten
2022-05-01 20:06 ` Marijn Suijten
2022-05-01 23:56 ` Abhinav Kumar
2022-05-01 23:56 ` Abhinav Kumar
2022-05-02 8:02 ` Dmitry Baryshkov
2022-05-02 8:02 ` Dmitry Baryshkov
2022-05-02 8:34 ` Marijn Suijten
2022-05-02 8:34 ` Marijn Suijten
2022-05-02 10:02 ` Dmitry Baryshkov
2022-05-02 10:02 ` Dmitry Baryshkov
2022-05-02 21:56 ` Marijn Suijten
2022-05-02 21:56 ` Marijn Suijten
2022-04-30 19:28 ` Dmitry Baryshkov
2022-04-30 19:28 ` Dmitry Baryshkov
2022-05-01 20:41 ` Marijn Suijten
2022-05-01 20:41 ` Marijn Suijten
2022-05-01 22:44 ` Dmitry Baryshkov
2022-05-01 22:44 ` Dmitry Baryshkov
2022-05-02 8:43 ` Marijn Suijten
2022-05-02 8:43 ` Marijn Suijten
2022-05-02 9:41 ` Dmitry Baryshkov
2022-05-02 9:41 ` Dmitry Baryshkov
2022-05-02 21:53 ` Marijn Suijten
2022-05-02 21:53 ` Marijn Suijten
2022-05-04 13:41 ` [Freedreno] " Vinod Koul
2022-05-04 13:41 ` Vinod Koul
2022-05-04 13:38 ` Vinod Koul [this message]
2022-05-04 13:38 ` Vinod Koul
2022-05-04 13:35 ` Vinod Koul
2022-05-04 13:35 ` Vinod Koul
2022-05-04 13:31 ` [Freedreno] " Vinod Koul
2022-05-04 13:31 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YnKB1nYLSVUSbSUJ@matsya \
--to=vkoul@kernel.org \
--cc=airlied@linux.ie \
--cc=bjorn.andersson@linaro.org \
--cc=daniel@ffwll.ch \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=lkp@intel.com \
--cc=marijn.suijten@somainline.org \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=swboyd@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.