public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: abhinavk@codeaurora.org
Cc: Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Kuogee Hsieh <khsieh@codeaurora.org>,
	Stephen Boyd <swboyd@chromium.org>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [Freedreno] [PATCH] drm/msm/dp: Only create debugfs for PRIMARY minor
Date: Fri, 15 Oct 2021 23:29:50 -0500	[thread overview]
Message-ID: <YWpVPshOT6k1MI2r@yoga> (raw)
In-Reply-To: <48f35ef1f90bc7c23599e98a5c1e2c09@codeaurora.org>

On Fri 15 Oct 18:44 CDT 2021, abhinavk@codeaurora.org wrote:

> On 2021-10-15 16:13, Bjorn Andersson wrote:
> > dpu_kms_debugfs_init() and hence dp_debug_get() gets invoked for each
> > minor being registered. But dp_debug_get() will allocate a new struct
> > dp_debug for each call and this will be associated as 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 dp_debug for the PRIMARY minor.
> > 
> 
> If i understand correctly, today because of this, we get redundant debugfs
> nodes right?
> 
> /sys/kernel/debug/dri/<minor_x>/dp_debug
> /sys/kernel/debug/dri/<minor_y>/dp_debug
> 
> Both of these will hold the same information as they are for the same DP
> controller right?

That's correct, all the dp_debug debugfs files end up in both minors.

The problem is that dp->debug points to the dp_debug struct for one of
them, which afaict doesn't have any really bad effects today - unless
you try to clean up the dp_debug state, but that will clear out the
entire dri/<minor_y>...

> In that case, this is true even for the other DPU kms information too.
> 
> Why not move this check one level up to dpu_kms_debugfs_init?
> 

I was expecting that perhaps some of this information was
minor-specific, but if that isn't the case it sounds reasonable that we
should push this one step up.

Regards,
Bjorn

> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >  drivers/gpu/drm/msm/dp/dp_display.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> > b/drivers/gpu/drm/msm/dp/dp_display.c
> > index 3aa67c53dbc0..06773b58bb60 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_display.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> > @@ -10,6 +10,7 @@
> >  #include <linux/component.h>
> >  #include <linux/of_irq.h>
> >  #include <linux/delay.h>
> > +#include <drm/drm_file.h>
> >  #include <drm/drm_panel.h>
> > 
> >  #include "msm_drv.h"
> > @@ -1463,6 +1464,10 @@ void msm_dp_debugfs_init(struct msm_dp
> > *dp_display, struct drm_minor *minor)
> >  	dp = container_of(dp_display, struct dp_display_private, dp_display);
> >  	dev = &dp->pdev->dev;
> > 
> > +	/* Only create one set of debugfs per DP instance */
> > +	if (minor->type != DRM_MINOR_PRIMARY)
> > +		return;
> > +
> >  	dp->debug = dp_debug_get(dev, dp->panel, dp->usbpd,
> >  					dp->link, dp->dp_display.connector,
> >  					minor);

      reply	other threads:[~2021-10-16  4:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-15 23:13 [PATCH] drm/msm/dp: Only create debugfs for PRIMARY minor Bjorn Andersson
2021-10-15 23:44 ` [Freedreno] " abhinavk
2021-10-16  4:29   ` Bjorn Andersson [this message]

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=YWpVPshOT6k1MI2r@yoga \
    --to=bjorn.andersson@linaro.org \
    --cc=abhinavk@codeaurora.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=khsieh@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox