Message-ID: <CACRpkdb6+2SLm1Ojw2jNkK9ejW66fw2Pcit-b3AL67wP4Hr_ow@mail.gmail.com>
Date:	Sun, 1 Apr 2012 19:22:46 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Russell King <linux@....linux.org.uk>,
	Grant Likely <grant.likely@...retlab.ca>,
	linux-arm-kernel@...ts.infradead.org,
	spi-devel-general@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH/RFC] ARM: amba: Remove AMBA level regulator support

On Sun, Apr 1, 2012 at 5:29 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:

> The AMBA bus regulator support is being used to model on/off switches
> for power domains which isn't terribly idiomatic for modern kernels with
> the generic power domain code and creates integration problems on platforms
> which don't use regulators for their power domains as it's hard to tell
> the difference between a regulator that is needed but failed to be provided
> and one that isn't supposed to be there (though DT does make that easier).
>
> Platforms that wish to use the regulator API to manage their power domains
> can indirect via the power domain interface.

I don't see how this solves the problem of AMBA PrimeCell probing.

If you look at the code in bus.c, you can see that it acquires and
enables the regulator - as it does with the clock.

The reason is that is does this *before* the device can probe,
since it needs to map up the memory to read out some magic
values at the end to figure out what device it is in the first place.

We need the current code replaced with something that
enables a power domain before probe instead, then implement
these power domains for the in-kernel AMBA devices that need it.

Is the default behaviour of power domains such that they will
be enabled as soon as devices are registered but before
any buses probe()? Because that is what is needed in this case.

(AMBA devices are special in this way: no other ARM things
support auto-detection of devices using magic numbers,
basically the DT stuff came about because noone was using
a thing like this.)

> The impact should be minimal since currently there are no mainline
> systems which actually provide a vcore regulator so none need updating.

Oh yes there are:
drivers/mfd/db8500-prcmu.c

This driver registers a number of voltage domain regulators,
among those:

static struct regulator_consumer_supply db8500_vape_consumers[] = {
       (...)
        REGULATOR_SUPPLY("vcore", "sdi0"),
        REGULATOR_SUPPLY("vcore", "sdi1"),
        REGULATOR_SUPPLY("vcore", "sdi2"),
        REGULATOR_SUPPLY("vcore", "sdi3"),
        REGULATOR_SUPPLY("vcore", "sdi4"),
        (...)
        REGULATOR_SUPPLY("vcore", "uart0"),
        REGULATOR_SUPPLY("vcore", "uart1"),
        REGULATOR_SUPPLY("vcore", "uart2"),

(I know the supplies should probably be moved up to the
platform but there they are.) The first array is MMC controllers
and the second is a number of UARTs.

IIRC the machine will not boot (i.e. these drivers cannot even
probe) without these regulators in place, so they get enabled by
the AMBA bus code.

So we need something that not just removes stuff from the
AMBA bus, but also adds a better power domain mechanism
and fixes up taking the above regulators.

That said I'm all for replacing it - but I'd need to figure out the
details on how to do that.

We do have code for ux500 power domains. If it will will be
enough to handle this I can try to hack it up and submit it.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists