All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dong Aisheng <dongas86@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Dong Aisheng <aisheng.dong@nxp.com>,
	linux-kernel@vger.kernel.org, shawnguo@kernel.org,
	linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
	lgirdwood@gmail.com, yibin.gong@nxp.com
Subject: Re: [PATCH 2/6] regulator: anatop: only set supply regulator when it actually exists
Date: Thu, 13 Apr 2017 15:11:01 +0800	[thread overview]
Message-ID: <20170413071101.GA23163@b29396-OptiPlex-7040> (raw)
In-Reply-To: <20170411203124.y7cwyttqfu4a2aov@sirena.org.uk>

Hi Mark,

On Tue, Apr 11, 2017 at 09:31:24PM +0100, Mark Brown wrote:
> On Wed, Apr 12, 2017 at 09:58:43AM +0800, Dong Aisheng wrote:
> > Mandatorily set the initdata->supply_regulator while it actually not
> > exist will cause regulator core to resolve supply each time whenever
> > a new regulator registered which is meaningless and waste CPU mips.
> > 
> > We can observe more than one hundred times of iteration of resolving
> > during a MX6Q SDB board booting up.
> > 
> > This patch adds the condition check for vin-supply to avoid the issue.
> 
> This is an obvious abstraction failure - there is nothing magical about
> your driver which means that we need special casing in it to handle
> badly written DTs that don't specify supplies.  Exactly the same
> argument applies to all other regulators so if this is worth fixing it's
> worth fixing in the core so we substitute in a dummy regulator if the
> supply is genuinely missing.  Which is something we in fact have code to
> do already though for some reason I can't see we bypass it, I'll send a
> patch just now...

You're absolutely right!
I did this because there're some where else did the same thing.
e.g. drivers/regulator/fixed.c.

But it's obviously none of any platform specific and is perfectly
to be handled in regulator core.

Regards
Dong Aisheng

WARNING: multiple messages have this Message-ID (diff)
From: dongas86@gmail.com (Dong Aisheng)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] regulator: anatop: only set supply regulator when it actually exists
Date: Thu, 13 Apr 2017 15:11:01 +0800	[thread overview]
Message-ID: <20170413071101.GA23163@b29396-OptiPlex-7040> (raw)
In-Reply-To: <20170411203124.y7cwyttqfu4a2aov@sirena.org.uk>

Hi Mark,

On Tue, Apr 11, 2017 at 09:31:24PM +0100, Mark Brown wrote:
> On Wed, Apr 12, 2017 at 09:58:43AM +0800, Dong Aisheng wrote:
> > Mandatorily set the initdata->supply_regulator while it actually not
> > exist will cause regulator core to resolve supply each time whenever
> > a new regulator registered which is meaningless and waste CPU mips.
> > 
> > We can observe more than one hundred times of iteration of resolving
> > during a MX6Q SDB board booting up.
> > 
> > This patch adds the condition check for vin-supply to avoid the issue.
> 
> This is an obvious abstraction failure - there is nothing magical about
> your driver which means that we need special casing in it to handle
> badly written DTs that don't specify supplies.  Exactly the same
> argument applies to all other regulators so if this is worth fixing it's
> worth fixing in the core so we substitute in a dummy regulator if the
> supply is genuinely missing.  Which is something we in fact have code to
> do already though for some reason I can't see we bypass it, I'll send a
> patch just now...

You're absolutely right!
I did this because there're some where else did the same thing.
e.g. drivers/regulator/fixed.c.

But it's obviously none of any platform specific and is perfectly
to be handled in regulator core.

Regards
Dong Aisheng

  reply	other threads:[~2017-04-12 15:14 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-12  1:58 [PATCH 1/6] regulator: anatop: check return value of of_get_regulator_init_data Dong Aisheng
2017-04-12  1:58 ` Dong Aisheng
2017-04-11 20:42 ` Applied "regulator: anatop: check return value of of_get_regulator_init_data" to the regulator tree Mark Brown
2017-04-11 20:42   ` Mark Brown
2017-04-12  1:58 ` [PATCH 2/6] regulator: anatop: only set supply regulator when it actually exists Dong Aisheng
2017-04-12  1:58   ` Dong Aisheng
2017-04-11 20:31   ` Mark Brown
2017-04-11 20:31     ` Mark Brown
2017-04-13  7:11     ` Dong Aisheng [this message]
2017-04-13  7:11       ` Dong Aisheng
2017-04-12 15:53       ` Mark Brown
2017-04-12 15:53         ` Mark Brown
2017-04-12 16:00         ` Dong Aisheng
2017-04-12 16:00           ` Dong Aisheng
2017-04-12 16:06           ` Mark Brown
2017-04-12 16:06             ` Mark Brown
2017-04-12  1:58 ` [PATCH 3/6] regulator: anatop: use of_property_read_string to read the name Dong Aisheng
2017-04-12  1:58   ` Dong Aisheng
2017-04-11 20:42   ` Applied "regulator: anatop: use of_property_read_string to read the name" to the regulator tree Mark Brown
2017-04-11 20:42     ` Mark Brown
2017-04-12  1:58 ` [PATCH 4/6] regulator: anatop: remove unneeded name field of struct anatop_regulator Dong Aisheng
2017-04-12  1:58   ` Dong Aisheng
2017-04-11 20:42   ` Applied "regulator: anatop: remove unneeded name field of struct anatop_regulator" to the regulator tree Mark Brown
2017-04-11 20:42     ` Mark Brown
2017-04-12  1:58 ` [PATCH 5/6] regulator: anatop-regulator: make regulator-name using optionally Dong Aisheng
2017-04-12  1:58   ` Dong Aisheng
2017-04-11 20:38   ` Mark Brown
2017-04-11 20:38     ` Mark Brown
2017-04-13  7:31     ` Dong Aisheng
2017-04-13  7:31       ` Dong Aisheng
2017-04-12  1:58 ` [PATCH 6/6] regulator: anatop: set default voltage selector for pcie Dong Aisheng
2017-04-12  1:58   ` Dong Aisheng
2017-04-11 20:40   ` Mark Brown
2017-04-11 20:40     ` Mark Brown
2017-04-13  7:41     ` Dong Aisheng
2017-04-13  7:41       ` Dong Aisheng
2017-04-12 15:49       ` Mark Brown
2017-04-12 15:49         ` Mark Brown
2017-04-12 16:11         ` Dong Aisheng
2017-04-12 16:11           ` Dong Aisheng
2017-04-12 16:11       ` Lucas Stach
2017-04-12 16:11         ` Lucas Stach
2017-04-12 16:16         ` Mark Brown
2017-04-12 16:16           ` Mark Brown

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=20170413071101.GA23163@b29396-OptiPlex-7040 \
    --to=dongas86@gmail.com \
    --cc=aisheng.dong@nxp.com \
    --cc=broonie@kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=yibin.gong@nxp.com \
    /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.