public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: alex.aring@gmail.com (Alexander Aring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] ARM: bcm2835: add rpi power domain driver
Date: Tue, 1 Dec 2015 22:00:42 +0100	[thread overview]
Message-ID: <20151201210037.GB2074@omega> (raw)
In-Reply-To: <7hr3j782qr.fsf@deeprootsystems.com>

Hi,

On Mon, Nov 30, 2015 at 03:51:56PM -0800, Kevin Hilman wrote:
> Alexander Aring <alex.aring@gmail.com> writes:
> 
> > This patch adds support for RPi several Power Domains and enable support
> > to enable the USB Power Domain when it's not enabled before.
> >
> > This patch based on Eric Anholt's patch to support Power Domains. He had
> > an issue about -EPROBE_DEFER inside the power domain subsystem, this
> > issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER
> > if we fail to init or turn-on domain").
> 
> [...]
> 
> > +#define RPI_POWER_DOMAIN(_domain, _name)			\
> > +	[_domain] = {						\
> 
> Using _domain as the array index is going to create a sparsely filled
> array here, wasting memory.   I'm not sure what the other domain numbers
> are for other domains to know if this is a big waste or not, but it's
> still a bit wasteful.
> 
> In any case, AFAICT, it doesn't look like you need to have the array
> index match the domain number anyways since you're using container_of().
> 
> So I suggest just removing this array index part, and just creating them
> in arrary order.  Then your _probe function isn't going to try to setup
> 3 non-enabled domains before it finally hits the USB domain.
> 

The idea is here to keeping the _same_ power domains indexes for
device-tree power domain API like the RPi firmware provides it.

If somebody dumps the devicetree and see the power domain index, if
he/she does then a firmware API power domain index mapping it is wrong.
Because we need then a separate mapping:

$ARRAY_DEFINED_INDEX <-> $RPI_FIRMWARE_POWER_DOMAIN_API_INDEX

With the current solution to make a 1:1 mapping it there is no
confusing anymore, because:

$ARRAY_DEFINED_INDEX == $RPI_FIRMWARE_POWER_DOMAIN_API_INDEX


Also there exists power domains 1-10 (so far I know), 1-2 are currently
not used (and dummy-calls inside the rpi firmware implementation). So
later they should be provided anyway.

There exists a little improvement to let the for (i = 0; i < num_domains
...) start@"i = 1", the entry with index "0" will be a waste of memory
then and it's not provided by the firmware API as a power domain.


These are my arguments to keeping the current way of registering power
domains, if you still want that I should change it then I will do it or
maybe I show here some "good" arguments here to keeping this behaviour.

Please let me know. Thanks.

- Alex

  reply	other threads:[~2015-12-01 21:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-19 18:08 [PATCH 0/3] ARM: bcm2835: add support for rpi power domain driver Alexander Aring
2015-11-19 18:08 ` [PATCH 1/3] power: domain: add pm_genpd_uninit Alexander Aring
2015-11-24 20:22   ` Ulf Hansson
2015-11-30 23:19   ` Kevin Hilman
2015-11-19 18:08 ` [PATCH 2/3] ARM: bcm2835: add rpi power domain driver Alexander Aring
2015-11-24 20:44   ` Ulf Hansson
2015-11-24 21:02     ` Alexander Aring
2015-11-25 19:33       ` Eric Anholt
2015-11-24 21:43   ` Eric Anholt
2015-11-30 23:51   ` Kevin Hilman
2015-12-01 21:00     ` Alexander Aring [this message]
2015-12-01 23:27       ` Kevin Hilman
2015-12-04  9:22         ` Alexander Aring
2015-11-19 18:08 ` [PATCH 3/3] devicetree: add rpi power domain driver bindings Alexander Aring
2015-11-20 16:14   ` Rob Herring

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=20151201210037.GB2074@omega \
    --to=alex.aring@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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