linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Gmeiner <christian.gmeiner@gmail.com>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	David Airlie <airlied@linux.ie>,
	The etnaviv authors <etnaviv@lists.freedesktop.org>,
	stable@vger.kernel.org,
	DRI mailing list <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Russell King <linux+etnaviv@armlinux.org.uk>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [PATCH] drm/etnaviv: rework perfmon query infrastructure
Date: Fri, 28 Feb 2020 11:39:05 +0100	[thread overview]
Message-ID: <CAH9NwWe85qELoLisKgVdZYeeBkngAk9qQVNDA3=cp4_uRwXsEw@mail.gmail.com> (raw)
In-Reply-To: <78e5e739269ee8f7467284ad88d2097e2ad991ba.camel@pengutronix.de>

Hi Lucas,

Am Mi., 26. Feb. 2020 um 16:19 Uhr schrieb Lucas Stach <l.stach@pengutronix.de>:
>
> Hi Christian,
>
> sorry for taking so long to get around to this.
>

No problem...

> On Mo, 2020-01-06 at 11:43 +0100, Christian Gmeiner wrote:
> > Report the correct perfmon domains and signals depending
> > on the supported feature flags.
> >
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > Fixes: 9e2c2e273012 ("drm/etnaviv: add infrastructure to query perf counter")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
> > ---
> >  drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 57 ++++++++++++++++++++---
> >  1 file changed, 50 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > index 8adbf2861bff..7ae8f347ca06 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > @@ -32,6 +32,7 @@ struct etnaviv_pm_domain {
> >  };
> >
> >  struct etnaviv_pm_domain_meta {
> > +     unsigned int feature;
> >       const struct etnaviv_pm_domain *domains;
> >       u32 nr_domains;
> >  };
> > @@ -410,36 +411,78 @@ static const struct etnaviv_pm_domain doms_vg[] = {
> >
> >  static const struct etnaviv_pm_domain_meta doms_meta[] = {
> >       {
> > +             .feature = chipFeatures_PIPE_3D,
> >               .nr_domains = ARRAY_SIZE(doms_3d),
> >               .domains = &doms_3d[0]
> >       },
> >       {
> > +             .feature = chipFeatures_PIPE_2D,
> >               .nr_domains = ARRAY_SIZE(doms_2d),
> >               .domains = &doms_2d[0]
> >       },
> >       {
> > +             .feature = chipFeatures_PIPE_VG,
> >               .nr_domains = ARRAY_SIZE(doms_vg),
> >               .domains = &doms_vg[0]
> >       }
> >  };
> >
> > +static unsigned int num_pm_domains(const struct etnaviv_gpu *gpu)
> > +{
> > +     unsigned int num = 0, i;
> > +
> > +     for (i = 0; i < ARRAY_SIZE(doms_meta); i++) {
> > +             const struct etnaviv_pm_domain_meta *meta = &doms_meta[i];
> > +
> > +             if (gpu->identity.features & meta->feature)
> > +                     num += meta->nr_domains;
> > +     }
> > +
> > +     return num;
> > +}
> > +
> > +static const struct etnaviv_pm_domain *pm_domain(const struct etnaviv_gpu *gpu,
> > +     unsigned int index)
> > +{
> > +     const struct etnaviv_pm_domain *domain = NULL;
> > +     unsigned int offset = 0, i;
> > +
> > +     for (i = 0; i < ARRAY_SIZE(doms_meta); i++) {
> > +             const struct etnaviv_pm_domain_meta *meta = &doms_meta[i];
> > +
> > +             if (!(gpu->identity.features & meta->feature))
> > +                     continue;
> > +
> > +             if (meta->nr_domains < (index - offset)) {
> > +                     offset += meta->nr_domains;
> > +                     continue;
> > +             }
> > +
> > +             domain = meta->domains + (index - offset);
> > +     }
> > +
> > +     BUG_ON(!domain);
>
> This is a no-go. BUG_ON is reserved for only the most severe kernel
> bugs where you can't possibly continue without risking a corruption of
> non-volatile state. This isn't the case here, please instead just make
> the callers handle a NULL return gracefully.
>

Fixed it in V2.

-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info/privacypolicy

      reply	other threads:[~2020-02-28 10:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-06 10:43 [PATCH] drm/etnaviv: rework perfmon query infrastructure Christian Gmeiner
2020-02-21  8:28 ` Christian Gmeiner
2020-02-26 15:19 ` Lucas Stach
2020-02-28 10:39   ` Christian Gmeiner [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='CAH9NwWe85qELoLisKgVdZYeeBkngAk9qQVNDA3=cp4_uRwXsEw@mail.gmail.com' \
    --to=christian.gmeiner@gmail.com \
    --cc=airlied@linux.ie \
    --cc=dan.carpenter@oracle.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=l.stach@pengutronix.de \
    --cc=linux+etnaviv@armlinux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).