All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Clément Péron" <peron.clem@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Rob Herring <robh@kernel.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Steven Price <steven.price@arm.com>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Maxime Ripard <mripard@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 05/15] drm/panfrost: use spinlock instead of atomic
Date: Fri, 29 May 2020 14:35:08 +0200	[thread overview]
Message-ID: <CAJiuCcemwM-11ZT5+-4JfyTgTRD-_JjWz=HDCme8743M5Epf0g@mail.gmail.com> (raw)
In-Reply-To: <788ac664-e426-d307-f81e-9632de09887c@arm.com>

Hi Robin,

On Fri, 29 May 2020 at 14:20, Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2020-05-10 17:55, Clément Péron wrote:
> > Convert busy_count to a simple int protected by spinlock.
>
> A little more reasoning might be nice.

I have follow the modification requested for lima devfreq and clearly
don't have any argument to switch to spinlock.

The Lima Maintainer asked to change witht the following reason :
"Better make this count a normal int which is also protected by the spinlock,
because current implementation can't protect atomic ops for state change
and busy idle check and we are using spinlock already"

>
> > Signed-off-by: Clément Péron <peron.clem@gmail.com>
> > ---
> [...]
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
> > index 0697f8d5aa34..e6629900a618 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
> > +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
> > @@ -4,6 +4,7 @@
> >   #ifndef __PANFROST_DEVFREQ_H__
> >   #define __PANFROST_DEVFREQ_H__
> >
> > +#include <linux/spinlock.h>
> >   #include <linux/ktime.h>
> >
> >   struct devfreq;
> > @@ -14,10 +15,17 @@ struct panfrost_device;
> >   struct panfrost_devfreq {
> >       struct devfreq *devfreq;
> >       struct thermal_cooling_device *cooling;
> > +
> >       ktime_t busy_time;
> >       ktime_t idle_time;
> >       ktime_t time_last_update;
> > -     atomic_t busy_count;
> > +     int busy_count;
> > +     /*
> > +      * Protect busy_time, idle_time, time_last_update and busy_count
> > +      * because these can be updated concurrently, for example by the GP
> > +      * and PP interrupts.
> > +      */
>
> Nit: this comment is clearly wrong, since we only have Job, GPU and MMU
> interrupts here. I guess if there is a race it would be between
> submission/completion/timeout on different job slots.

It's copy/paste from lima I will update it,

>
> Given that, should this actually be considered a fix for 9e62b885f715
> ("drm/panfrost: Simplify devfreq utilisation tracking")?

I can't say if it can be considered as a fix, I didn't see any
improvement on my board before and after this patch.
I'm still facing some issue and didn't have time to fully investigate it.

Thanks for you review,


>
> Robin.

WARNING: multiple messages have this Message-ID (diff)
From: "Clément Péron" <peron.clem@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Nishanth Menon <nm@ti.com>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Viresh Kumar <vireshk@kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Steven Price <steven.price@arm.com>, Chen-Yu Tsai <wens@csie.org>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Subject: Re: [PATCH 05/15] drm/panfrost: use spinlock instead of atomic
Date: Fri, 29 May 2020 14:35:08 +0200	[thread overview]
Message-ID: <CAJiuCcemwM-11ZT5+-4JfyTgTRD-_JjWz=HDCme8743M5Epf0g@mail.gmail.com> (raw)
In-Reply-To: <788ac664-e426-d307-f81e-9632de09887c@arm.com>

Hi Robin,

On Fri, 29 May 2020 at 14:20, Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2020-05-10 17:55, Clément Péron wrote:
> > Convert busy_count to a simple int protected by spinlock.
>
> A little more reasoning might be nice.

I have follow the modification requested for lima devfreq and clearly
don't have any argument to switch to spinlock.

The Lima Maintainer asked to change witht the following reason :
"Better make this count a normal int which is also protected by the spinlock,
because current implementation can't protect atomic ops for state change
and busy idle check and we are using spinlock already"

>
> > Signed-off-by: Clément Péron <peron.clem@gmail.com>
> > ---
> [...]
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
> > index 0697f8d5aa34..e6629900a618 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
> > +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
> > @@ -4,6 +4,7 @@
> >   #ifndef __PANFROST_DEVFREQ_H__
> >   #define __PANFROST_DEVFREQ_H__
> >
> > +#include <linux/spinlock.h>
> >   #include <linux/ktime.h>
> >
> >   struct devfreq;
> > @@ -14,10 +15,17 @@ struct panfrost_device;
> >   struct panfrost_devfreq {
> >       struct devfreq *devfreq;
> >       struct thermal_cooling_device *cooling;
> > +
> >       ktime_t busy_time;
> >       ktime_t idle_time;
> >       ktime_t time_last_update;
> > -     atomic_t busy_count;
> > +     int busy_count;
> > +     /*
> > +      * Protect busy_time, idle_time, time_last_update and busy_count
> > +      * because these can be updated concurrently, for example by the GP
> > +      * and PP interrupts.
> > +      */
>
> Nit: this comment is clearly wrong, since we only have Job, GPU and MMU
> interrupts here. I guess if there is a race it would be between
> submission/completion/timeout on different job slots.

It's copy/paste from lima I will update it,

>
> Given that, should this actually be considered a fix for 9e62b885f715
> ("drm/panfrost: Simplify devfreq utilisation tracking")?

I can't say if it can be considered as a fix, I didn't see any
improvement on my board before and after this patch.
I'm still facing some issue and didn't have time to fully investigate it.

Thanks for you review,


>
> Robin.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-05-29 12:35 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-10 16:55 [PATCH 00/15][RFC] Add regulator devfreq support to Panfrost Clément Péron
2020-05-10 16:55 ` Clément Péron
2020-05-10 16:55 ` [PATCH 01/15] drm/panfrost: avoid static declaration Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-28 13:22   ` Steven Price
2020-05-28 13:22     ` Steven Price
2020-05-10 16:55 ` [PATCH 02/15] drm/panfrost: clean headers in devfreq Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-28 13:22   ` Steven Price
2020-05-28 13:22     ` Steven Price
2020-05-10 16:55 ` [PATCH 03/15] drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-28 13:22   ` Steven Price
2020-05-28 13:22     ` Steven Price
2020-05-10 16:55 ` [PATCH 04/15] drm/panfrost: introduce panfrost_devfreq struct Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-28 13:22   ` Steven Price
2020-05-28 13:22     ` Steven Price
2020-05-10 16:55 ` [PATCH 05/15] drm/panfrost: use spinlock instead of atomic Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-28 13:22   ` Steven Price
2020-05-28 13:22     ` Steven Price
2020-05-29 12:20   ` Robin Murphy
2020-05-29 12:20     ` Robin Murphy
2020-05-29 12:35     ` Clément Péron [this message]
2020-05-29 12:35       ` Clément Péron
2020-05-29 12:47       ` Steven Price
2020-05-29 12:47         ` Steven Price
2020-05-10 16:55 ` [PATCH 06/15] drm/panfrost: properly handle error in probe Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-28 13:22   ` Steven Price
2020-05-28 13:22     ` Steven Price
2020-05-10 16:55 ` [PATCH 07/15] drm/panfrost: use device_property_present to check for OPP Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-28 13:22   ` Steven Price
2020-05-28 13:22     ` Steven Price
2020-05-29 12:45     ` Clément Péron
2020-05-29 12:45       ` Clément Péron
2020-05-10 16:55 ` [PATCH 08/15] drm/panfrost: move devfreq_init()/fini() in device Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-28 13:22   ` Steven Price
2020-05-28 13:22     ` Steven Price
2020-05-29 12:38     ` Clément Péron
2020-05-29 12:38       ` Clément Péron
2020-06-08 11:55       ` Tomeu Vizoso
2020-06-08 11:55         ` Tomeu Vizoso
2020-05-10 16:55 ` [PATCH 09/15] drm/panfrost: dynamically alloc regulators Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-28 13:22   ` Steven Price
2020-05-28 13:22     ` Steven Price
2020-05-10 16:55 ` [PATCH 10/15] drm/panfrost: add regulators to devfreq Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-28 13:23   ` Steven Price
2020-05-28 13:23     ` Steven Price
2020-05-29 12:37     ` Clément Péron
2020-05-29 12:37       ` Clément Péron
2020-05-10 16:55 ` [PATCH 11/15] drm/panfrost: set devfreq clock name Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-28 13:23   ` Steven Price
2020-05-28 13:23     ` Steven Price
2020-05-29 12:35     ` Clément Péron
2020-05-29 12:35       ` Clément Péron
2020-05-10 16:55 ` [PATCH 12/15] arm64: defconfig: Enable devfreq cooling device Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-10 16:55 ` [PATCH 13/15] arm64: dts: allwinner: h6: Add cooling map for GPU Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-10 16:55 ` [PATCH 14/15] [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-10 16:55 ` [PATCH 15/15] [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be always Clément Péron
2020-05-10 16:55   ` Clément Péron
2020-05-11  5:43 ` [PATCH 00/15][RFC] Add regulator devfreq support to Panfrost Tomeu Vizoso
2020-05-11  5:43   ` Tomeu Vizoso

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='CAJiuCcemwM-11ZT5+-4JfyTgTRD-_JjWz=HDCme8743M5Epf0g@mail.gmail.com' \
    --to=peron.clem@gmail.com \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mripard@kernel.org \
    --cc=nm@ti.com \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sboyd@kernel.org \
    --cc=steven.price@arm.com \
    --cc=tomeu.vizoso@collabora.com \
    --cc=vireshk@kernel.org \
    --cc=wens@csie.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.