From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Rob Clark <robdclark@gmail.com>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Sean Paul <sean@poorly.run>, 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, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] drm/msm/dp: Only create debugfs for PRIMARY minor
Date: Mon, 20 Dec 2021 16:02:30 -0800 [thread overview]
Message-ID: <YcEZljENYJQAk9We@ripper> (raw)
In-Reply-To: <CAA8EJpoYJFfB5qfFMoc3-QsmYZzO16C28MOrPyokANQyPBhdyg@mail.gmail.com>
On Mon 20 Dec 15:53 PST 2021, Dmitry Baryshkov wrote:
> On Fri, 17 Dec 2021 at 03:19, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> >
> > dpu_kms_debugfs_init() is invoked for each minor being registered. Most
> > of the files created are unrelated to the minor, so there's no reason to
> > present them per minor.
> > The exception to this is the DisplayPort code, which ends up invoking
> > dp_debug_get() for each minor, each time associate the allocated object
> > with dp->debug.
> >
> > As such dp_debug will create debugfs files in both the PRIMARY and the
> > RENDER minor's debugfs directory, but only the last reference will be
> > remembered.
> >
> > The only use of this reference today is in the cleanup path in
> > dp_display_deinit_sub_modules() and the dp_debug_private object does
> > outlive the debugfs entries in either case, so there doesn't seem to be
> > any adverse effects of this, but per the code the current behavior is
> > unexpected, so change it to only create debugfs files for the PRIMARY
> > minor.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >
> > Changes since v1:
> > - Moved the check up from msm_dp_debugfs_init() to dpu_kms_debugfs_init()
> >
> > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > index 2ee70072a1b4..a54f7d373f14 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > @@ -193,6 +193,10 @@ static int dpu_kms_debugfs_init(struct msm_kms *kms, struct drm_minor *minor)
> > if (!p)
> > return -EINVAL;
> >
> > + /* Only create one set of debugfs per DP instance */
>
> The comment is misleading. Could you please fix it?
>
I agree, and as Abhinav pointed out I didn't update $subject fully
either.
Will resubmit.
Regards,
Bjorn
> > + if (minor->type != DRM_MINOR_PRIMARY)
> > + return 0;
> > +
> > dev = dpu_kms->dev;
> > priv = dev->dev_private;
> >
> > --
> > 2.33.1
> >
>
>
> --
> With best wishes
> Dmitry
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: freedreno@lists.freedesktop.org, David Airlie <airlied@linux.ie>,
linux-arm-msm@vger.kernel.org,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Sean Paul <sean@poorly.run>
Subject: Re: [PATCH v2] drm/msm/dp: Only create debugfs for PRIMARY minor
Date: Mon, 20 Dec 2021 16:02:30 -0800 [thread overview]
Message-ID: <YcEZljENYJQAk9We@ripper> (raw)
In-Reply-To: <CAA8EJpoYJFfB5qfFMoc3-QsmYZzO16C28MOrPyokANQyPBhdyg@mail.gmail.com>
On Mon 20 Dec 15:53 PST 2021, Dmitry Baryshkov wrote:
> On Fri, 17 Dec 2021 at 03:19, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> >
> > dpu_kms_debugfs_init() is invoked for each minor being registered. Most
> > of the files created are unrelated to the minor, so there's no reason to
> > present them per minor.
> > The exception to this is the DisplayPort code, which ends up invoking
> > dp_debug_get() for each minor, each time associate the allocated object
> > with dp->debug.
> >
> > As such dp_debug will create debugfs files in both the PRIMARY and the
> > RENDER minor's debugfs directory, but only the last reference will be
> > remembered.
> >
> > The only use of this reference today is in the cleanup path in
> > dp_display_deinit_sub_modules() and the dp_debug_private object does
> > outlive the debugfs entries in either case, so there doesn't seem to be
> > any adverse effects of this, but per the code the current behavior is
> > unexpected, so change it to only create debugfs files for the PRIMARY
> > minor.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >
> > Changes since v1:
> > - Moved the check up from msm_dp_debugfs_init() to dpu_kms_debugfs_init()
> >
> > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > index 2ee70072a1b4..a54f7d373f14 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > @@ -193,6 +193,10 @@ static int dpu_kms_debugfs_init(struct msm_kms *kms, struct drm_minor *minor)
> > if (!p)
> > return -EINVAL;
> >
> > + /* Only create one set of debugfs per DP instance */
>
> The comment is misleading. Could you please fix it?
>
I agree, and as Abhinav pointed out I didn't update $subject fully
either.
Will resubmit.
Regards,
Bjorn
> > + if (minor->type != DRM_MINOR_PRIMARY)
> > + return 0;
> > +
> > dev = dpu_kms->dev;
> > priv = dev->dev_private;
> >
> > --
> > 2.33.1
> >
>
>
> --
> With best wishes
> Dmitry
next prev parent reply other threads:[~2021-12-21 0:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-17 0:20 [PATCH v2] drm/msm/dp: Only create debugfs for PRIMARY minor Bjorn Andersson
2021-12-17 0:20 ` Bjorn Andersson
2021-12-20 19:51 ` Abhinav Kumar
2021-12-20 19:51 ` Abhinav Kumar
2021-12-20 23:53 ` Dmitry Baryshkov
2021-12-20 23:53 ` Dmitry Baryshkov
2021-12-21 0:02 ` Bjorn Andersson [this message]
2021-12-21 0:02 ` Bjorn Andersson
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=YcEZljENYJQAk9We@ripper \
--to=bjorn.andersson@linaro.org \
--cc=airlied@linux.ie \
--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=linux-kernel@vger.kernel.org \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
/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.