* [PATCH v3 00/13] pinctrl: mvebu: restructure resource allocation
From: Thomas Petazzoni @ 2014-02-13 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392220776-30851-1-git-send-email-sebastian.hesselbarth@gmail.com>
Dear Sebastian Hesselbarth,
Thanks again for working on this! I have boot tested this successfully
on an Armada XP platform, and it seems to behave normally, the debugfs
pinctrl contents make sense.
I have a few comments below, though.
On Wed, 12 Feb 2014 16:59:23 +0100, Sebastian Hesselbarth wrote:
> Also, in the meantime, pinctrl driver stubs for new Armada 375/28x have
> been posted [3]. Before any of this patches move to a stable branch, I
> plan to send an updated version comprising the required patches for the
> new SoCs. As the new driver stubs are very much like what we already have
> for Armada 370/XP, let's only discuss the general approach now and add
> the branch dependency and patches later.
I am not sure what you mean here in terms of the ordering for the
patches. I'm attaching several patches, and the first three patches
adapt your patch series to also cover 375 and 38x, assuming the pinctrl
support for 375 and 38x is merged before your patch series.
With these patches, I have
> Patches 1-3 first deal with the way we handle unnamed "generic" mpp
> controls. Patch 1 consolidates the per-control allocation of name buffers
> to counting unnamed controls first and then allocate a global name buffer
> for all those controls. Patch 2 then removes the now obsolete per-control
> allocation of name buffers. Patch 3 then makes the common driver to
> identify "generic" mpp controls by an empty name and adds some valuable
> comments about that special treatment.
I must say I dislike quite a bit this unnamed mpp controls mechanism.
Why isn't the name statically defined in the source code by the
MPP_MODE macro, which already takes as first argument the pin number?
All the calculation of the buffer size, generating the names and so on,
looks like a lot of unnecessary code to me. But well, this unnamed
thing was already here, so I'm not saying your patch series should do
anything about it.
> Patch 4 removes passing struct mvebu_mpp_ctrl to the special callback
> as the only relevant information in that struct for the callback is the
> pin number which is passed directly instead.
>
> Patches 5-9 then add some global defines and provide SoC specific
> callbacks even for the "generic" mpp controls. This allows Patch 10 to
> move resource allocation to SoC specific drivers and remove the common
> generic callbacks in Patch 11.
This is definitely good, but I'm wondering why the core cannot provide
helper functions for the generic case where we have 4 bits per pin in
contiguous registers. This would avoid duplicating the helper function
six times (you have four in your patch series, and we'll need two more
for A375 and A38x).
I've also attached other patches:
* One patch that fixes your Armada XP handling, which missed the
mv78230 and mv78260 cases (PATCH 4)
* One patch that removes MPP_REG_CTRL (PATCH 5)
* One patch that adjusts a comment in the code that was no longer true
(PATCH 6)
Feel free to squash these patches into the appropriate patches.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-pinctrl-mvebu-armada-375-provide-generic-mpp-callbac.patch
Type: text/x-patch
Size: 1659 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140213/9f210261/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-pinctrl-mvebu-armada-38x-provide-generic-mpp-callbac.patch
Type: text/x-patch
Size: 1604 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140213/9f210261/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-fixup-pinctrl-mvebu-move-resource-allocation-to-SoC-.patch
Type: text/x-patch
Size: 2639 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140213/9f210261/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-fixup-pinctrl-mvebu-move-resource-allocation-to-SoC-.patch
Type: text/x-patch
Size: 1255 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140213/9f210261/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-pinctrl-mvebu-remove-MPP_REG_CTRL-macro.patch
Type: text/x-patch
Size: 1299 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140213/9f210261/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-pinctrl-mvebu-update-comment-about-mvebu_mpp_ctrl.patch
Type: text/x-patch
Size: 1293 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140213/9f210261/attachment-0005.bin>
^ permalink raw reply
* [PATCH v2 3/3] PCI: ARM: add support for generic PCI host controller
From: Will Deacon @ 2014-02-13 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BA5E6077-77F8-4BE8-80E5-BAB9FE111387@codeaurora.org>
On Thu, Feb 13, 2014 at 04:22:25PM +0000, Kumar Gala wrote:
> On Feb 13, 2014, at 5:07 AM, Will Deacon <will.deacon@arm.com> wrote:
> >>> +
> >>> +- compatible : Must be "arm,pci-cam-generic" or "arm,pci-ecam-generic"
> >>> + depending on the layout of configuration space (CAM vs
> >>> + ECAM respectively)
> >>
> >> What?s arm specific here? I don?t have a great suggestion, but seems odd
> >> for this to be vendor prefixed with "arm".
> >
> > Happy to change it, but I'm also struggling for names. Maybe "linux,?"?
>
> I was thinking that as well, I?d say go with ?linux,?.
Great, I'll make that change.
> >>> +- ranges : As described in IEEE Std 1275-1994, but must provide
> >>> + at least a definition of one or both of IO and Memory
> >>> + Space.
> >>> +
> >>> +- #address-cells : Must be 3
> >>> +
> >>> +- #size-cells : Must be 2
> >>> +
> >>> +- reg : The Configuration Space base address, as accessed by the
> >>> + parent bus.
> >>
> >> Isn?t the size fixed here for cam or ecam?
> >
> > Yes, which is why reg just specifies the base address.
>
> Huh? The reg property clearly has the size in it (as shown in the example
> below). I guess I was just asking for the description here to say what
> the size was for the 2 compatibles since its fixed and known.
Actually, the example just has a 64-bit CPU physical address with no size.
Do I have to add a size to the binding? It's not at all useful for the driver.
> >> Examples are always nice :)
> >
> > Not in this case! kvmtool generates the following:
> >
> > pci {
> > #address-cells = <0x3>;
> > #size-cells = <0x2>;
> > #interrupt-cells = <0x1>;
> > compatible = "arm,pci-cam-generic";
> > reg = <0x0 0x40000000>;
> > ranges = <0x1000000 0x0 0x0 0x0 0x0 0x0 0x10000 0x2000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000>;
> > interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0x4 0x1 0x800 0x0 0x0 0x1 0x1 0x0 0x5 0x1 0x1000 0x0 0x0 0x1 0x1 0x0 0x6 0x1 0x1800 0x0 0x0 0x1 0x1 0x0 0x7 0x1>;
> > interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> > };
> >
> > I can add it if you like, but it looks like a random bunch of numbers to me.
>
> You could clean it up a bit to be human readable even if its kvmtool that?s creating it.
>
> pci {
> compatible = "arm,pci-cam-generic?;
> #address-cells = <3>;
> #size-cells = <2>;
> #interrupt-cells = <1>
> reg = <0x0 0x40000000>;
> ranges = <
> 0x1000000 0x0 0x00000000 0x0 0x00000000 0x0 0x00010000
> 0x2000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000
> >;
> interrupt-map = <
> ...
> >;
>
> interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
Sure, if you think it helps.
Will
^ permalink raw reply
* [PATCH v2 3/3] PCI: ARM: add support for generic PCI host controller
From: Kumar Gala @ 2014-02-13 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213110721.GC13576@mudshark.cambridge.arm.com>
On Feb 13, 2014, at 5:07 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Feb 12, 2014 at 09:51:48PM +0000, Kumar Gala wrote:
>>
>> On Feb 12, 2014, at 2:16 PM, Will Deacon <will.deacon@arm.com> wrote:
>>
>>> This patch adds support for a generic PCI host controller, such as a
>>> firmware-initialised device with static windows or an emulation by
>>> something such as kvmtool.
>>>
>>> The controller itself has no configuration registers and has its address
>>> spaces described entirely by the device-tree (using the bindings from
>>> ePAPR). Both CAM and ECAM are supported for Config Space accesses.
>>>
>>> Corresponding documentation is added for the DT binding.
>>>
>>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>>> ---
>>> .../devicetree/bindings/pci/arm-generic-pci.txt | 51 ++++
>>> drivers/pci/host/Kconfig | 7 +
>>> drivers/pci/host/Makefile | 1 +
>>> drivers/pci/host/pci-arm-generic.c | 318 +++++++++++++++++++++
>>> 4 files changed, 377 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/pci/arm-generic-pci.txt
>>> create mode 100644 drivers/pci/host/pci-arm-generic.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/arm-generic-pci.txt b/Documentation/devicetree/bindings/pci/arm-generic-pci.txt
>>> new file mode 100644
>>> index 000000000000..cc7a35ecfa2d
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/pci/arm-generic-pci.txt
>>> @@ -0,0 +1,51 @@
>>> +* ARM generic PCI host controller
>>> +
>>> +Firmware-initialised PCI host controllers and PCI emulations, such as the
>>> +virtio-pci implementations found in kvmtool and other para-virtualised
>>> +systems, do not require driver support for complexities such as regulator and
>>> +clock management. In fact, the controller may not even require the
>>> +configuration of a control interface by the operating system, instead
>>> +presenting a set of fixed windows describing a subset of IO, Memory and
>>> +Configuration Spaces.
>>> +
>>> +Such a controller can be described purely in terms of the standardized device
>>> +tree bindings communicated in pci.txt:
>>> +
>>> +- compatible : Must be "arm,pci-cam-generic" or "arm,pci-ecam-generic"
>>> + depending on the layout of configuration space (CAM vs
>>> + ECAM respectively)
>>
>> What?s arm specific here? I don?t have a great suggestion, but seems odd
>> for this to be vendor prefixed with "arm".
>
> Happy to change it, but I'm also struggling for names. Maybe "linux,?"?
I was thinking that as well, I?d say go with ?linux,?.
>>> +- ranges : As described in IEEE Std 1275-1994, but must provide
>>> + at least a definition of one or both of IO and Memory
>>> + Space.
>>> +
>>> +- #address-cells : Must be 3
>>> +
>>> +- #size-cells : Must be 2
>>> +
>>> +- reg : The Configuration Space base address, as accessed by the
>>> + parent bus.
>>
>> Isn?t the size fixed here for cam or ecam?
>
> Yes, which is why reg just specifies the base address.
Huh? The reg property clearly has the size in it (as shown in the example below). I guess I was just asking for the description here to say what the size was for the 2 compatibles since its fixed and known.
>
>>> +Configuration Space is assumed to be memory-mapped (as opposed to being
>>> +accessed via an ioport) and laid out with a direct correspondence to the
>>> +geography of a PCI bus address by concatenating the various components to form
>>> +an offset.
>>> +
>>> +For CAM, this 24-bit offset is:
>>> +
>>> + cfg_offset(bus, device, function, register) =
>>> + bus << 16 | device << 11 | function << 8 | register
>>> +
>>> +Whilst ECAM extends this by 4 bits to accomodate 4k of function space:
>>> +
>>> + cfg_offset(bus, device, function, register) =
>>> + bus << 20 | device << 15 | function << 12 | register
>>> +
>>> +Interrupt mapping is exactly as described in `Open Firmware Recommended
>>> +Practice: Interrupt Mapping' and requires the following properties:
>>> +
>>> +- #interrupt-cells : Must be 1
>>> +
>>> +- interrupt-map : <see aforementioned specification>
>>> +
>>> +- interrupt-map-mask : <see aforementioned specification>
>>
>> Examples are always nice :)
>
> Not in this case! kvmtool generates the following:
>
> pci {
> #address-cells = <0x3>;
> #size-cells = <0x2>;
> #interrupt-cells = <0x1>;
> compatible = "arm,pci-cam-generic";
> reg = <0x0 0x40000000>;
> ranges = <0x1000000 0x0 0x0 0x0 0x0 0x0 0x10000 0x2000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000>;
> interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0x4 0x1 0x800 0x0 0x0 0x1 0x1 0x0 0x5 0x1 0x1000 0x0 0x0 0x1 0x1 0x0 0x6 0x1 0x1800 0x0 0x0 0x1 0x1 0x0 0x7 0x1>;
> interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> };
>
> I can add it if you like, but it looks like a random bunch of numbers to me.
You could clean it up a bit to be human readable even if its kvmtool that?s creating it.
pci {
compatible = "arm,pci-cam-generic?;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>
reg = <0x0 0x40000000>;
ranges = <
0x1000000 0x0 0x00000000 0x0 0x00000000 0x0 0x00010000
0x2000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000
>;
interrupt-map = <
...
>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
>
> Will
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Arnd Bergmann @ 2014-02-13 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213144106.GW26684@n2100.arm.linux.org.uk>
On Thursday 13 February 2014 14:41:06 Russell King - ARM Linux wrote:
> On Thu, Feb 13, 2014 at 01:48:55PM +0100, Arnd Bergmann wrote:
> > On Thursday 13 February 2014 10:42:48 Russell King - ARM Linux wrote:
> > >
> > > What if we have a platform where things subtly change, like for instance,
> > > the wiring on the SD slot to fix a problem with UHS-1 cards, which means
> > > you don't have UHS-1 support for some platforms but do for others.
> > >
> > > What if you have a platform which uses a brcm4329 chip for Wifi, but then
> > > later in the production run switch to using a different Wifi chipset?
> >
> > As far as I can tell, the power sequencing is normally really
> > dependent on the device. If someone has an on-board brcm4329
> > that requires a specific set of clocks, resets, voltages etc
> > to be routed to the chip and enabled in the correct order to
> > allow probing, it seems unlikely that changing the wifi chipset
> > to something else would keep the exact same requirements.
>
> That's your assertion - however, do we /know/ whether there's a situation
> where Olof's solution doesn't work because the sequencing is wrong?
>
> I see nothing unreasonable about the sequence:
>
> 1. hold reset at low level
> 2. apply power
> 3. turn clock on
> 4. apply reset
> 5. release reset
I was thinking of cases where you may need a more complex sequence:
- wait for a device specific time between some of the steps
(the cw1200 driver seems to need that, but we could probably
get away with waiting long enough for everyone)
- have more than one of each, and turn them on in the right order.
cw1200 seems to need two voltages, two gpio resets ("reset"
and "powerup").
Again, we could specify a larger number of clocks that can be
provided to the host, but if we make it a device specific
property, we already know how many we need.
I can't think of anything that would require significant changes
to the procedure though, just refinements as we run into problems.
> The points being:
> * never set a signal to a high level before power is applied, otherwise
> we can end up supplying power through that signal (which may cause
> damage.) That goes for the reset and clock.
> * devices normally want clocks running to complete their reset sequencing.
>
> This is actually the sequence which MMC/SD cards do (except without the
> reset) anyway - it's spec'd that on the MMC/SD bus, power will be applied
> and will be stable before the clock signal is applied, and then the clock
> signal runs for a certain number of cycles before you even start talking
> to the card.
It may be dangerous to refer to the spec, since we are talking
specifically about devices that require something beyond what the
spec says ;-) For instance in SD/MMC cards I'd assume the device clock
to be derived from the bus clock. However we can expect that clock
to work already (any working mmc host driver would provide that),
but we may need to drive the device clock. It still sounds reasonable
to assume that the sequencing is the same as for the bus clock.
> That all said, we do have the problem that once we decide, we need to
> support it because it becomes part of DT - this is one of the things I
> hate about DT, it requires over-design.
Yes, I agree. It is a problem that we have to face all the time.
We have in the past defined bindings of both types, overdesigned
and not thought through enough.
> Your point is "Olof's solution
> may break if we have a device which requires a different sequence" which
> is a valid point which has to be considered from the DT perspective and
> addressed whether or not we actually have a device which meets that
> criteria. I don't see an easy solution to this.
I think either one will work. With Olof's suggestion that may mean we
have to keep adding support for increasingly complex cases when we
run into them, or it may all be easy. With my suggestion, we give
more room for function drivers to mess things up, but at least we
can keep the complexity in the places that need them and only need
to change the core once.
Aside from the power-on problem, my suggestion would at the same
time solve the second problem of having a place to stick arbitrary
DT properties for the sdio function. Again looking at the cw1200
example, they may require passing an IRQ descriptor, a MAC address,
the device clock rate, and two flags for things that are not
detectable by looking at the device ID (whether a 5GHz antenna is
connected and something about odd block size transfers).
This is probably the main difference between the two approaches.
Arnd
^ permalink raw reply
* [RESEND][PATCH v4] gpio: davinci: reuse for keystone soc
From: Grygorii Strashko @ 2014-02-13 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FBB6BC.2060801@ti.com>
The similar GPIO HW block is used by keystone SoCs as
in Davinci SoCs.
Hence, reuse Davinci GPIO driver for Keystone taking into
account that Keystone contains ARM GIC IRQ controller which
is implemented using IRQ Chip.
Documentation:
http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
- rebased on top of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
branch: devel
top commit: ef70bbe gpio: make gpiod_direction_output take a logical value
.../devicetree/bindings/gpio/gpio-davinci.txt | 4 +-
drivers/gpio/gpio-davinci.c | 48 ++++++++++++++++----
2 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index a2e839d..4ce9862 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -1,7 +1,7 @@
-Davinci GPIO controller bindings
+Davinci/Keystone GPIO controller bindings
Required Properties:
-- compatible: should be "ti,dm6441-gpio"
+- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"
- reg: Physical base address of the controller and the size of memory mapped
registers.
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 7629b4f..d0f135d 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -37,6 +37,8 @@ struct davinci_gpio_regs {
u32 intstat;
};
+typedef struct irq_chip *(*gpio_get_irq_chip_cb_t)(unsigned int irq);
+
#define BINTEN 0x8 /* GPIO Interrupt Per-Bank Enable Register */
#define chip2controller(chip) \
@@ -413,6 +415,26 @@ static const struct irq_domain_ops davinci_gpio_irq_ops = {
.xlate = irq_domain_xlate_onetwocell,
};
+static struct irq_chip *davinci_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip_type gpio_unbanked;
+
+ gpio_unbanked = *container_of(irq_get_chip(irq),
+ struct irq_chip_type, chip);
+
+ return &gpio_unbanked.chip;
+};
+
+static struct irq_chip *keystone_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip gpio_unbanked;
+
+ gpio_unbanked = *irq_get_chip(irq);
+ return &gpio_unbanked;
+};
+
+static const struct of_device_id davinci_gpio_ids[];
+
/*
* NOTE: for suspend/resume, probably best to make a platform_device with
* suspend_late/resume_resume calls hooking into results of the set_wake()
@@ -433,6 +455,18 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
struct davinci_gpio_platform_data *pdata = dev->platform_data;
struct davinci_gpio_regs __iomem *g;
struct irq_domain *irq_domain = NULL;
+ const struct of_device_id *match;
+ struct irq_chip *irq_chip;
+ gpio_get_irq_chip_cb_t gpio_get_irq_chip;
+
+ /*
+ * Use davinci_gpio_get_irq_chip by default to handle non DT cases
+ */
+ gpio_get_irq_chip = davinci_gpio_get_irq_chip;
+ match = of_match_device(of_match_ptr(davinci_gpio_ids),
+ dev);
+ if (match)
+ gpio_get_irq_chip = (gpio_get_irq_chip_cb_t)match->data;
ngpio = pdata->ngpio;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
@@ -489,8 +523,6 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
* IRQ mux conflicts; gpio_irq_type_unbanked() is only for GPIOs.
*/
if (pdata->gpio_unbanked) {
- static struct irq_chip_type gpio_unbanked;
-
/* pass "bank 0" GPIO IRQs to AINTC */
chips[0].chip.to_irq = gpio_to_irq_unbanked;
chips[0].gpio_irq = bank_irq;
@@ -499,10 +531,9 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
/* AINTC handles mask/unmask; GPIO handles triggering */
irq = bank_irq;
- gpio_unbanked = *container_of(irq_get_chip(irq),
- struct irq_chip_type, chip);
- gpio_unbanked.chip.name = "GPIO-AINTC";
- gpio_unbanked.chip.irq_set_type = gpio_irq_type_unbanked;
+ irq_chip = gpio_get_irq_chip(irq);
+ irq_chip->name = "GPIO-AINTC";
+ irq_chip->irq_set_type = gpio_irq_type_unbanked;
/* default trigger: both edges */
g = gpio2regs(0);
@@ -511,7 +542,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
/* set the direct IRQs up to use that irqchip */
for (gpio = 0; gpio < pdata->gpio_unbanked; gpio++, irq++) {
- irq_set_chip(irq, &gpio_unbanked.chip);
+ irq_set_chip(irq, irq_chip);
irq_set_handler_data(irq, &chips[gpio / 32]);
irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
}
@@ -554,7 +585,8 @@ done:
#if IS_ENABLED(CONFIG_OF)
static const struct of_device_id davinci_gpio_ids[] = {
- { .compatible = "ti,dm6441-gpio", },
+ { .compatible = "ti,keystone-gpio", keystone_gpio_get_irq_chip},
+ { .compatible = "ti,dm6441-gpio", davinci_gpio_get_irq_chip},
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, davinci_gpio_ids);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] arm64: smp: Add a memory barrier before we start secondary cores
From: Mark Brown @ 2014-02-13 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <F28028BE-865B-4338-BA62-3F766B922A63@arm.com>
On Wed, Feb 12, 2014 at 06:23:14PM +0000, Catalin Marinas wrote:
> I think we should aim to understand the code better rather than just
> adding the spinlocks. Some simple questions:
I agree that understanding the code is good, my point is that if the
code needs serious thinking about to understand then it's probably not
good code even if it is correct given that it's not super performance
critical.
> - Who uses the topology information and when? (the scheduler? first time after or
> before secondaries are started?)
It's used directly by the architecture topology code only (to generate
information read by the scheduler). The scheduler appears to deal with
its own concurrency requirements and it appears to use information it
gets immediately.
> - Who updates the topology information? (primary and secondary startup
> code?)
Each CPU that comes on line.
> - What about hotplug?
Removal currently doesn't do anything to these data structures (nor is
it expected to). Starting the CPU will redo the startup code which
should produce the same result again (anything dynamic would need work
to support dynamic topology information anyway).
> - Can any of the above happen in parallel on different CPUs?
Everything looks serialised, though I may be missing some cases or have
lost something in an indirection.
A lack of locking also seems reasonably consistent with other
architectures from a quick survey.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140213/07be9ae2/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx6qdl-sabresd: Provide min/max voltages for codec regulator
From: Fabio Estevam @ 2014-02-13 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392306839-10736-1-git-send-email-fabio.estevam@freescale.com>
Currently the following message is observed during boot:
wm8962-supply: no parameters
Provide min/max properties for the codec regulator.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index a802265..086f770 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -47,6 +47,8 @@
compatible = "regulator-fixed";
reg = <2>;
regulator-name = "wm8962-supply";
+ regulator-min-microvolt = <4200000>;
+ regulator-max-microvolt = <4200000>;
gpio = <&gpio4 10 0>;
enable-active-high;
};
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6qdl-sabresd: Add hog entry for GPIO4_10
From: Fabio Estevam @ 2014-02-13 15:53 UTC (permalink / raw)
To: linux-arm-kernel
GPIO4_10 is the GPIO used to turn on the regulator that powers up the codec.
Add a hog entry for it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 0d816d3..a802265 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -303,6 +303,7 @@
MX6QDL_PAD_ENET_TXD1__GPIO1_IO29 0x80000000
MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x80000000
MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x80000000
+ MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x80000000
>;
};
--
1.8.1.2
^ permalink raw reply related
* [PATCH 08/14] net: axienet: Removed checkpatch errors/warnings
From: Joe Perches @ 2014-02-13 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff5b1f6a-a6a7-405c-9e83-59ad33852b93@TX2EHSMHS044.ehs.local>
On Thu, 2014-02-13 at 08:19 +0100, Michal Simek wrote:
> On 02/13/2014 01:31 AM, Joe Perches wrote:
> > On Wed, 2014-02-12 at 16:55 +0100, Michal Simek wrote:
Hi again Michal.
> >> + netdev_warn(lp->ndev,
> >> + "Could not find clock ethernet controller property.");
> >
> > here too. (and alignment)
>
> This is problematic. I would like to keep 80 char limits and keeping
> this align just break it. That's why I was using tab alignment.
> Probably the solution is just to shorten message.
(overly long, tiresomely trivial stuff below)
Your choice. I'm not an 80 column zealot but
please don't shorten the message just to fit
80 columns if it impacts intelligibility.
Generally, I'd write this something like:
netdev_warn(lp->ndev,
"Could not find clock ethernet controller property\n");
(without the period) which is 83 columns.
checkpatch makes exceptions for 80 column line
length maximums for format strings.
I've no real issue if you indent it back one.
fyi: this is 77 columns
netdev_warn(lp->ndev,
"No clock ethernet controller property found\n");
About the message itself.
You dropped the "axienet_mdio_setup" function name.
I believe the dmesg output will look something like:
xilinx_temac 0000:01:00.0 (unregistered net_device): Could not find clock ethernet controller property.
xilinx_temac 0000:01:00.0 (unregistered net_device): Setting MDIO clock divisor to default 29
Because these 2 messages are effectively linked,
my preference would be to emit them on a single line,
Something like:
xilinx_temac 0000:01:00.0 (unregistered net_device): of_get_property("clock-frequency") not found - setting MDIO clock divisor to default 29
or
netdev_warn(lp->ndev,
"of_get_property(\"clock-frequency\") not found - setting MDIO clock divisor to default %u\n",
DEFAULT_CLOCK_DIVISOR);
^ permalink raw reply
* [PATCH 01/18] arm64: initial support for GICv3
From: Marc Zyngier @ 2014-02-13 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <loom.20140207T065340-308@post.gmane.org>
Hi Arnab,
Please do not trim the CC list. I missed this email (lost in the
traffic), and contributors to the other MLs may also have comments.
On 07/02/14 08:59, Arnab Basu wrote:
> Hi Marc
>
> Marc Zyngier <marc.zyngier <at> arm.com> writes:
>
>> +
>> +static inline void __iomem *gic_dist_base(struct irq_data *d)
>
> I would suggest that this function be renamed (something like
> gic_base_for_irq?) since it returns dist or redist sgi base address. The
> name suggests it always returns the dist base address.
I may rename it to gic_get_irq_base.
>> +{
>> + if (d->hwirq < 32) /* SGI+PPI -> SGI_base for this CPU */
>> + return gic_data_rdist_sgi_base();
>> +
>> + if (d->hwirq <= 1023) /* SPI -> dist_base */
>> + return gic_data.dist_base;
>> +
>> + if (d->hwirq >= 8192)
>> + BUG(); /* LPI Detected!!! */
>> +
>> + return NULL;
>> +}
>> +
>> +static inline unsigned int gic_irq(struct irq_data *d)
>> +{
>> + return d->hwirq;
>> +}
>> +
>> +static void gic_do_wait_for_rwp(void __iomem *base)
>> +{
>> + u32 val;
>> +
>> + do {
>> + val = readl_relaxed(base + GICD_CTLR);
>
> Maybe rename GICD_CTLR to GICx_CTLR since it is being used for both the
> distributor and the redistributor.
I really hate the "GICx" bit. I think instead, I'll add a comment so
people don't get confuse about the name.
>> + cpu_relax();
>> + } while (val & GICD_CTLR_RWP);
>
> Similar to above GICx_CTLR_RWP
>
>
>> +
>> +static int gic_irq_domain_xlate(struct irq_domain *d,
>> + struct device_node *controller,
>> + const u32 *intspec, unsigned int intsize,
>> + unsigned long *out_hwirq, unsigned int *out_type)
>> +{
>> + if (d->of_node != controller)
>> + return -EINVAL;
>> + if (intsize < 3)
>> + return -EINVAL;
>> +
>> + switch(intspec[0]) {
>> + case 0: /* SPI */
>> + *out_hwirq = intspec[1] + 32;
>> + break;
>> + case 1: /* PPI */
>> + *out_hwirq = intspec[1] + 16;
>> + break;
>
> I wonder if there is any value to syncing these with the defines in
> "include/dt-bindings/interrupt-controller/arm-gic.h" somehow.
I'd expect the whole DTS stuff to vanish from the kernel some day, so
I'm keen on not depending on it.
Thanks for the review,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 03/22] efi: add helper function to get UEFI params from FDT
From: Mark Salter @ 2014-02-13 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213111637.GE20717@console-pimps.org>
On Thu, 2014-02-13 at 11:17 +0000, Matt Fleming wrote:
> On Wed, 05 Feb, at 05:03:54PM, Leif Lindholm wrote:
> > From: Mark Salter <msalter@redhat.com>
> >
> > ARM and ARM64 architectures use the device tree to pass UEFI parameters
> > from stub to kernel. These parameters are things known to the stub but
> > not discoverable by the kernel after the stub calls ExitBootSerives().
> > There is a helper function in:
> >
> > drivers/firmware/efi/fdt.c
> >
> > which the stub uses to add the UEFI parameters to the device tree.
> > This patch adds a complimentary helper function which UEFI runtime
> > support may use to retrieve the parameters from the device tree.
> > If an architecture wants to use this helper, it should select
> > CONFIG_UEFI_PARAMS_FROM_FDT.
> >
> > Signed-off-by: Mark Salter <msalter@redhat.com>
> > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
> > ---
> > drivers/firmware/efi/Kconfig | 7 ++++
> > drivers/firmware/efi/efi.c | 79 ++++++++++++++++++++++++++++++++++++++++++
> > include/linux/efi.h | 9 +++++
> > 3 files changed, 95 insertions(+)
>
> Is there a particular reason this change is being added to
> drivers/firmware/efi/efi.c and not drivers/firmware/efi/fdt.c?
>
drivers/firmware/efi/fdt.c is included by the stub which may or may not
be linked into kernel image. This helper is used by runtime services and
needs to be built into kernel.
--Mark
^ permalink raw reply
* [PATCH v2 4/4] Documentation: dt: OMAP: Update Overo/Tobi
From: Nishanth Menon @ 2014-02-13 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392287116-4548-5-git-send-email-florian.vaussard@epfl.ch>
On 02/13/2014 04:25 AM, Florian Vaussard wrote:
> Update the compatible string for Overo/Tobi to reflect the latest
> changes.
>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> ---
> Documentation/devicetree/bindings/arm/omap/omap.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index 34dc40c..af9b4a0 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -91,7 +91,7 @@ Boards:
> compatible = "ti,omap3-beagle", "ti,omap3"
>
> - OMAP3 Tobi with Overo : Commercial expansion board with daughter board
> - compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
> + compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3"
omap3-overo-storm-tobi.dts is not covered here, so, I wonder as the
number of boards supported keep increasing, is'nt it better we drop
the board information from omap.txt?
>
> - OMAP4 SDP : Software Development Board
> compatible = "ti,omap4-sdp", "ti,omap4430"
>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v2 3/4] ARM: dts: Add support for both OMAP35xx and OMAP36xx Overo/Tobi
From: Nishanth Menon @ 2014-02-13 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392287116-4548-4-git-send-email-florian.vaussard@epfl.ch>
On 02/13/2014 04:25 AM, Florian Vaussard wrote:
> Unfortunatly the device tree for older OMAP35xx Overo cannot be used
> with newer OMAP36xx and vice-versa. To address this issue, move most of
> the Tobi DTS to a common include file, and create model-specific Tobi
> DTS.
>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> Tested-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/boot/dts/Makefile | 3 ++-
> arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 22 ++++++++++++++++++++++
> ...omap3-tobi.dts => omap3-overo-tobi-common.dtsi} | 6 ------
> arch/arm/boot/dts/omap3-overo-tobi.dts | 22 ++++++++++++++++++++++
> 4 files changed, 46 insertions(+), 7 deletions(-)
> create mode 100644 arch/arm/boot/dts/omap3-overo-storm-tobi.dts
> rename arch/arm/boot/dts/{omap3-tobi.dts => omap3-overo-tobi-common.dtsi} (91%)
> create mode 100644 arch/arm/boot/dts/omap3-overo-tobi.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b9d6a8b..e8355f4 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -208,7 +208,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> omap3-n900.dtb \
> omap3-n9.dtb \
> omap3-n950.dtb \
> - omap3-tobi.dtb \
> + omap3-overo-tobi.dtb \
> + omap3-overo-storm-tobi.dtb \
> omap3-gta04.dtb \
> omap3-igep0020.dtb \
> omap3-igep0030.dtb \
> diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
> new file mode 100644
> index 0000000..966b5c9
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 2012 Florian Vaussard, EPFL Mobots group
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/*
> + * Tobi expansion board is manufactured by Gumstix Inc.
> + */
> +
> +/dts-v1/;
> +
> +#include "omap36xx.dtsi"
> +#include "omap3-overo-tobi-common.dtsi"
> +
> +/ {
> + model = "OMAP36xx/AM37xx/DM37xx Gumstix Overo on Tobi";
> + compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap36xx", "ti,omap3";
> +};
> +
> diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
> similarity index 91%
> rename from arch/arm/boot/dts/omap3-tobi.dts
> rename to arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
> index c742afa..4edc013 100644
> --- a/arch/arm/boot/dts/omap3-tobi.dts
> +++ b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
> @@ -10,15 +10,9 @@
> * Tobi expansion board is manufactured by Gumstix Inc.
> */
>
> -/dts-v1/;
> -
> -#include "omap36xx.dtsi"
> #include "omap3-overo.dtsi"
>
> / {
> - model = "TI OMAP3 Gumstix Overo on Tobi";
> - compatible = "gumstix,omap3-tobi", "gumstix,omap3-overo", "ti,omap36xx", "ti,omap3";
> -
> leds {
> compatible = "gpio-leds";
> heartbeat {
> diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts b/arch/arm/boot/dts/omap3-overo-tobi.dts
> new file mode 100644
> index 0000000..de5653e
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-overo-tobi.dts
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 2012 Florian Vaussard, EPFL Mobots group
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/*
> + * Tobi expansion board is manufactured by Gumstix Inc.
> + */
> +
> +/dts-v1/;
> +
> +#include "omap34xx.dtsi"
> +#include "omap3-overo-tobi-common.dtsi"
> +
> +/ {
> + model = "OMAP35xx Gumstix Overo on Tobi";
> + compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3430", "ti,omap3";
> +};
> +
>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: omap3-tobi: Use the correct vendor prefix
From: Nishanth Menon @ 2014-02-13 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392287116-4548-3-git-send-email-florian.vaussard@epfl.ch>
On 02/13/2014 04:25 AM, Florian Vaussard wrote:
> Gumstix is the correct vendor for all Overo related products.
>
> Reported-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Acked-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/boot/dts/omap3-tobi.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
> index 0e3b8bf..c742afa 100644
> --- a/arch/arm/boot/dts/omap3-tobi.dts
> +++ b/arch/arm/boot/dts/omap3-tobi.dts
> @@ -17,7 +17,7 @@
>
> / {
> model = "TI OMAP3 Gumstix Overo on Tobi";
> - compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap36xx", "ti,omap3";
> + compatible = "gumstix,omap3-tobi", "gumstix,omap3-overo", "ti,omap36xx", "ti,omap3";
>
> leds {
> compatible = "gpio-leds";
>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v2 1/4] ARM: dts: omap3-tobi: Fix boot with OMAP36xx-based Overo
From: Nishanth Menon @ 2014-02-13 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392287116-4548-2-git-send-email-florian.vaussard@epfl.ch>
On 02/13/2014 04:25 AM, Florian Vaussard wrote:
> Tobi expansion board can be used with both OMAP35xx-based Overo,
> and OMAP36xx-based Overo. Currently the boot is broken with newer
> OMAP36xx-based Overo (Storm and alike). Fix include file and
> compatible string to be able to boot newer models.
>
> This will break older models. This will be addressed later.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> Tested-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/boot/dts/omap3-overo.dtsi | 3 ---
> arch/arm/boot/dts/omap3-tobi.dts | 5 ++++-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
> index a461d2f..5970999 100644
> --- a/arch/arm/boot/dts/omap3-overo.dtsi
> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
> @@ -9,9 +9,6 @@
> /*
> * The Gumstix Overo must be combined with an expansion board.
> */
> -/dts-v1/;
> -
> -#include "omap34xx.dtsi"
>
> / {
> pwmleds {
> diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
> index 7e4ad2a..0e3b8bf 100644
> --- a/arch/arm/boot/dts/omap3-tobi.dts
> +++ b/arch/arm/boot/dts/omap3-tobi.dts
> @@ -10,11 +10,14 @@
> * Tobi expansion board is manufactured by Gumstix Inc.
> */
>
> +/dts-v1/;
> +
> +#include "omap36xx.dtsi"
> #include "omap3-overo.dtsi"
>
> / {
> model = "TI OMAP3 Gumstix Overo on Tobi";
> - compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3";
> + compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap36xx", "ti,omap3";
>
> leds {
> compatible = "gpio-leds";
>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Russell King - ARM Linux @ 2014-02-13 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2874395.Ul86gYA57i@wuerfel>
On Thu, Feb 13, 2014 at 01:48:55PM +0100, Arnd Bergmann wrote:
> On Thursday 13 February 2014 10:42:48 Russell King - ARM Linux wrote:
> >
> > What if we have a platform where things subtly change, like for instance,
> > the wiring on the SD slot to fix a problem with UHS-1 cards, which means
> > you don't have UHS-1 support for some platforms but do for others.
> >
> > What if you have a platform which uses a brcm4329 chip for Wifi, but then
> > later in the production run switch to using a different Wifi chipset?
>
> As far as I can tell, the power sequencing is normally really
> dependent on the device. If someone has an on-board brcm4329
> that requires a specific set of clocks, resets, voltages etc
> to be routed to the chip and enabled in the correct order to
> allow probing, it seems unlikely that changing the wifi chipset
> to something else would keep the exact same requirements.
That's your assertion - however, do we /know/ whether there's a situation
where Olof's solution doesn't work because the sequencing is wrong?
I see nothing unreasonable about the sequence:
1. hold reset at low level
2. apply power
3. turn clock on
4. apply reset
5. release reset
The points being:
* never set a signal to a high level before power is applied, otherwise
we can end up supplying power through that signal (which may cause
damage.) That goes for the reset and clock.
* devices normally want clocks running to complete their reset sequencing.
This is actually the sequence which MMC/SD cards do (except without the
reset) anyway - it's spec'd that on the MMC/SD bus, power will be applied
and will be stable before the clock signal is applied, and then the clock
signal runs for a certain number of cycles before you even start talking
to the card.
That all said, we do have the problem that once we decide, we need to
support it because it becomes part of DT - this is one of the things I
hate about DT, it requires over-design. Your point is "Olof's solution
may break if we have a device which requires a different sequence" which
is a valid point which has to be considered from the DT perspective and
addressed whether or not we actually have a device which meets that
criteria. I don't see an easy solution to this.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v2 7/7] ARM: dts: imx6sl: Add power-domain information to gpc node
From: Philipp Zabel @ 2014-02-13 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392302350-11729-1-git-send-email-p.zabel@pengutronix.de>
The PGC that is part of GPC controls isolation and power sequencing of the
power domains. The PU power domain will be handled by the generic pm domain
framework and needs a phandle to the PU regulator to turn off power when
the domain is disabled.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
arch/arm/boot/dts/imx6sl.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 28558f1..774e1fb 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -529,9 +529,27 @@
};
gpc: gpc at 020dc000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
compatible = "fsl,imx6sl-gpc", "fsl,imx6q-gpc";
reg = <0x020dc000 0x4000>;
interrupts = <0 89 0x04>;
+ pu-supply = <®_pu>;
+
+ pd_display: display-power-domain at 020dc240 {
+ compatible = "fsl,imx6q-power-domain";
+ reg = <0x020dc240 0x10>;
+ };
+
+ pd_pu: pu-power-domain at 020dc260 {
+ compatible = "fsl,imx6q-power-domain";
+ reg = <0x020dc260 0x10>;
+ };
+
+ pd_arm: cpu-power-domain at 020dc2a0 {
+ compatible = "fsl,imx6q-power-domain";
+ reg = <0x020dc2a0 0x10>;
+ };
};
gpr: iomuxc-gpr at 020e0000 {
--
1.8.5.3
^ permalink raw reply related
* [PATCH v2 6/7] ARM: dts: imx6qdl: Add power-domain information to gpc node
From: Philipp Zabel @ 2014-02-13 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392302350-11729-1-git-send-email-p.zabel@pengutronix.de>
The PGC that is part of GPC controls isolation and power sequencing of the
power domains. The PU power domain will be handled by the generic pm domain
framework and needs a phandle to the PU regulator to turn off power when
the domain is disabled.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
Changes since v1:
- Renamed power-domain to pu-power-domain and added
cpu-power-domain
---
arch/arm/boot/dts/imx6qdl.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 253d82c..fd1be55 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -598,9 +598,22 @@
};
gpc: gpc at 020dc000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
compatible = "fsl,imx6q-gpc";
reg = <0x020dc000 0x4000>;
interrupts = <0 89 0x04 0 90 0x04>;
+ pu-supply = <®_pu>;
+
+ pd_pu: pu-power-domain at 020dc260 {
+ compatible = "fsl,imx6q-power-domain";
+ reg = <0x020dc260 0x10>;
+ };
+
+ pd_arm: cpu-power-domain at 020dc2a0 {
+ compatible = "fsl,imx6q-power-domain";
+ reg = <0x020dc2a0 0x10>;
+ };
};
gpr: iomuxc-gpr at 020e0000 {
--
1.8.5.3
^ permalink raw reply related
* [PATCH v2 5/7] ARM: dts: imx6qdl: Allow disabling the PU regulator, add a enable ramp delay
From: Philipp Zabel @ 2014-02-13 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392302350-11729-1-git-send-email-p.zabel@pengutronix.de>
The PU regulator is enabled during boot, but not necessarily always-on.
It can be disabled by the generic pm domain framework when the PU power
domain is shut down. The ramp delay of 150 us might be a bit conservative,
the value is taken from the Freescale kernel.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
arch/arm/boot/dts/imx6qdl.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index fb28b2e..253d82c 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -515,7 +515,8 @@
regulator-name = "vddpu";
regulator-min-microvolt = <725000>;
regulator-max-microvolt = <1450000>;
- regulator-always-on;
+ regulator-enable-ramp-delay = <150>;
+ regulator-boot-on;
anatop-reg-offset = <0x140>;
anatop-vol-bit-shift = <9>;
anatop-vol-bit-width = <5>;
--
1.8.5.3
^ permalink raw reply related
* [PATCH v2 4/7] ARM: imx6: gpc: Add observed worst case latencies
From: Philipp Zabel @ 2014-02-13 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392302350-11729-1-git-send-email-p.zabel@pengutronix.de>
This avoids the "... latency exceeded, new value ..." warnings
emitted by the power domain framework code whenever the PU domain
is enabled or disabled.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
arch/arm/mach-imx/gpc.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 607a6ea..cbac099 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -225,6 +225,8 @@ static struct generic_pm_domain imx6q_pu_domain = {
.name = "PU",
.power_off = imx6q_pm_pu_power_off,
.power_on = imx6q_pm_pu_power_on,
+ .power_off_latency_ns = 25000,
+ .power_on_latency_ns = 2000000,
};
int imx6q_pm_clk_add(struct device *dev)
@@ -289,6 +291,13 @@ int imx6q_pm_clk_remove(struct device *dev)
return 0;
}
+static struct gpd_timing_data pu_timing_data = {
+ .stop_latency_ns = 2000,
+ .start_latency_ns = 2000,
+ .save_state_latency_ns = 5000,
+ .restore_state_latency_ns = 20000000, /* VPU firmware reload */
+};
+
static int imx6q_pm_notifier_call(struct notifier_block *nb,
unsigned long event, void *data)
{
@@ -303,7 +312,7 @@ static int imx6q_pm_notifier_call(struct notifier_block *nb,
if (!np || np != imx6q_pu_domain.of_node)
return NOTIFY_DONE;
- ret = pm_genpd_of_add_device(np, dev);
+ ret = __pm_genpd_of_add_device(np, dev, &pu_timing_data);
if (ret)
dev_err(dev, "failed to add to power domain: %d\n",
ret);
--
1.8.5.3
^ permalink raw reply related
* [PATCH v2 3/7] ARM: imx6: gpc: Add pm clock support to PU power domain
From: Philipp Zabel @ 2014-02-13 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392302350-11729-1-git-send-email-p.zabel@pengutronix.de>
Drivers still handle clocks themselves, we only enable pm clocks of the
GPU and VPU devices in the PU power domain temporarily during powerup
so that the reset machinery can work.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
arch/arm/mach-imx/gpc.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 74 insertions(+)
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 1dc4301..607a6ea 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -18,6 +18,7 @@
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/platform_device.h>
+#include <linux/pm_clock.h>
#include <linux/pm_domain.h>
#include <linux/regulator/consumer.h>
#include <linux/irqchip/arm-gic.h>
@@ -182,6 +183,7 @@ static int imx6q_pm_pu_power_off(struct generic_pm_domain *genpd)
static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
{
+ struct pm_domain_data *pdd;
int ret;
u32 val;
int sw, sw2iso;
@@ -192,6 +194,10 @@ static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
return ret;
}
+ /* Enable PM clocks for all devices in the PU domain */
+ list_for_each_entry(pdd, &genpd->dev_list, list_node)
+ pm_clk_resume(pdd->dev);
+
/* Gate off PU domain when GPU/VPU when powered down */
writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
@@ -208,6 +214,10 @@ static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
/* Wait ISO + ISO2SW IPG clock cycles */
ndelay((sw + sw2iso) * 1000 / 66);
+ /* Disable PM clocks for all devices in the PU domain */
+ list_for_each_entry(pdd, &genpd->dev_list, list_node)
+ pm_clk_suspend(pdd->dev);
+
return 0;
}
@@ -217,6 +227,68 @@ static struct generic_pm_domain imx6q_pu_domain = {
.power_on = imx6q_pm_pu_power_on,
};
+int imx6q_pm_clk_add(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ const char *con_id;
+ struct clk *clk;
+ int i = 0;
+
+ /* Add and prepare named clocks */
+ while (!of_property_read_string_index(np, "clock-names", i, &con_id)) {
+ pm_clk_add(dev, con_id);
+ clk = of_clk_get(np, i);
+ if (!IS_ERR(clk)) {
+ clk_prepare(clk);
+ clk_put(clk);
+ }
+ i++;
+ }
+
+ /* If no named clocks are given, add and prepare unnamed clock */
+ if (i == 1 && of_find_property(dev->of_node, "clocks", NULL)) {
+ pm_clk_add(dev, NULL);
+ clk = of_clk_get(np, 0);
+ if (!IS_ERR(clk)) {
+ clk_prepare(clk);
+ clk_put(clk);
+ }
+ }
+
+ return 0;
+}
+
+int imx6q_pm_clk_remove(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ const char *con_id;
+ struct clk *clk;
+ int i = 0;
+
+ /* Remove and unprepare named clocks */
+ while (!of_property_read_string_index(np, "clock-names", i, &con_id)) {
+ pm_clk_remove(dev, con_id);
+ clk = of_clk_get(np, i);
+ if (!IS_ERR(clk)) {
+ clk_unprepare(clk);
+ clk_put(clk);
+ }
+ i++;
+ }
+
+ /* If no named clocks are given, remove and unprepare unnamed clock */
+ if (i == 1 && of_find_property(dev->of_node, "clocks", NULL)) {
+ pm_clk_remove(dev, NULL);
+ clk = of_clk_get(np, 0);
+ if (!IS_ERR(clk)) {
+ clk_unprepare(clk);
+ clk_put(clk);
+ }
+ }
+
+ return 0;
+}
+
static int imx6q_pm_notifier_call(struct notifier_block *nb,
unsigned long event, void *data)
{
@@ -235,6 +307,7 @@ static int imx6q_pm_notifier_call(struct notifier_block *nb,
if (ret)
dev_err(dev, "failed to add to power domain: %d\n",
ret);
+ imx6q_pm_clk_add(dev);
break;
case BUS_NOTIFY_UNBOUND_DRIVER:
genpd = dev_to_genpd(dev);
@@ -245,6 +318,7 @@ static int imx6q_pm_notifier_call(struct notifier_block *nb,
if (ret)
dev_err(dev, "failed to remove from power domain: %d\n",
ret);
+ imx6q_pm_clk_remove(dev);
break;
}
--
1.8.5.3
^ permalink raw reply related
* [PATCH v2 2/7] ARM: imx6: gpc: Add PU power domain for GPU/VPU
From: Philipp Zabel @ 2014-02-13 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392302350-11729-1-git-send-email-p.zabel@pengutronix.de>
When generic pm domain support is enabled, the PGC can be used
to completely gate power to the PU power domain containing GPU3D,
GPU2D, and VPU cores.
This code triggers the PGC powerdown sequence to disable the GPU/VPU
isolation cells and gate power and then disables the PU regulator.
To reenable, the reverse powerup sequence is triggered after the PU
regulaotor is enabled again.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
Changes since v1:
- Removed superfluous comment
- Link PU domain with its DT node, check for PU domain in bus notifier
- Turn off the PU power domain on boot
---
arch/arm/mach-imx/Kconfig | 2 +
arch/arm/mach-imx/gpc.c | 170 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 172 insertions(+)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 33567aa..3c58f2e 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -808,6 +808,7 @@ config SOC_IMX6Q
select PL310_ERRATA_727915 if CACHE_PL310
select PL310_ERRATA_769419 if CACHE_PL310
select PM_OPP if PM
+ select PM_GENERIC_DOMAINS if PM
help
This enables support for Freescale i.MX6 Quad processor.
@@ -827,6 +828,7 @@ config SOC_IMX6SL
select PL310_ERRATA_588369 if CACHE_PL310
select PL310_ERRATA_727915 if CACHE_PL310
select PL310_ERRATA_769419 if CACHE_PL310
+ select PM_GENERIC_DOMAINS if PM
help
This enables support for Freescale i.MX6 SoloLite processor.
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 586e017..1dc4301 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -10,19 +10,32 @@
* http://www.gnu.org/copyleft/gpl.html
*/
+#include <linux/clk.h>
+#include <linux/delay.h>
#include <linux/io.h>
#include <linux/irq.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/regulator/consumer.h>
#include <linux/irqchip/arm-gic.h>
#include "common.h"
+#include "hardware.h"
+#define GPC_CNTR 0x000
#define GPC_IMR1 0x008
+#define GPC_PGC_GPU_PDN 0x260
+#define GPC_PGC_GPU_PUPSCR 0x264
+#define GPC_PGC_GPU_PDNSCR 0x268
#define GPC_PGC_CPU_PDN 0x2a0
#define IMR_NUM 4
+#define GPU_VPU_PUP_REQ BIT(1)
+#define GPU_VPU_PDN_REQ BIT(0)
+
static void __iomem *gpc_base;
static u32 gpc_wake_irqs[IMR_NUM];
static u32 gpc_saved_imrs[IMR_NUM];
@@ -138,3 +151,160 @@ void __init imx_gpc_init(void)
gic_arch_extn.irq_unmask = imx_gpc_irq_unmask;
gic_arch_extn.irq_set_wake = imx_gpc_irq_set_wake;
}
+
+static struct regulator *pu_reg;
+
+static int imx6q_pm_pu_power_off(struct generic_pm_domain *genpd)
+{
+ u32 val;
+ int iso, iso2sw;
+
+ /* Read ISO and ISO2SW power down delays */
+ val = readl_relaxed(gpc_base + GPC_PGC_GPU_PDNSCR);
+ iso = val & 0x3f;
+ iso2sw = (val >> 8) & 0x3f;
+
+ /* Gate off PU domain when GPU/VPU when powered down */
+ writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
+
+ /* Request GPC to power down GPU/VPU */
+ val = readl_relaxed(gpc_base + GPC_CNTR);
+ val |= GPU_VPU_PDN_REQ;
+ writel_relaxed(val, gpc_base + GPC_CNTR);
+
+ /* Wait ISO + ISO2SW IPG clock cycles */
+ ndelay((iso + iso2sw) * 1000 / 66);
+
+ regulator_disable(pu_reg);
+
+ return 0;
+}
+
+static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
+{
+ int ret;
+ u32 val;
+ int sw, sw2iso;
+
+ ret = regulator_enable(pu_reg);
+ if (ret) {
+ pr_err("%s: failed to enable regulator: %d\n", __func__, ret);
+ return ret;
+ }
+
+ /* Gate off PU domain when GPU/VPU when powered down */
+ writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
+
+ /* Read ISO and ISO2SW power down delays */
+ val = readl_relaxed(gpc_base + GPC_PGC_GPU_PUPSCR);
+ sw = val & 0x3f;
+ sw2iso = (val >> 8) & 0x3f;
+
+ /* Request GPC to power up GPU/VPU */
+ val = readl_relaxed(gpc_base + GPC_CNTR);
+ val |= GPU_VPU_PUP_REQ;
+ writel_relaxed(val, gpc_base + GPC_CNTR);
+
+ /* Wait ISO + ISO2SW IPG clock cycles */
+ ndelay((sw + sw2iso) * 1000 / 66);
+
+ return 0;
+}
+
+static struct generic_pm_domain imx6q_pu_domain = {
+ .name = "PU",
+ .power_off = imx6q_pm_pu_power_off,
+ .power_on = imx6q_pm_pu_power_on,
+};
+
+static int imx6q_pm_notifier_call(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct generic_pm_domain *genpd;
+ struct device *dev = data;
+ struct device_node *np;
+ int ret;
+
+ switch (event) {
+ case BUS_NOTIFY_BIND_DRIVER:
+ np = of_parse_phandle(dev->of_node, "power-domain", 0);
+ if (!np || np != imx6q_pu_domain.of_node)
+ return NOTIFY_DONE;
+
+ ret = pm_genpd_of_add_device(np, dev);
+ if (ret)
+ dev_err(dev, "failed to add to power domain: %d\n",
+ ret);
+ break;
+ case BUS_NOTIFY_UNBOUND_DRIVER:
+ genpd = dev_to_genpd(dev);
+ if (IS_ERR(genpd) || genpd != &imx6q_pu_domain)
+ return NOTIFY_DONE;
+
+ ret = pm_genpd_remove_device(genpd, dev);
+ if (ret)
+ dev_err(dev, "failed to remove from power domain: %d\n",
+ ret);
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block imx6q_platform_nb = {
+ .notifier_call = imx6q_pm_notifier_call,
+};
+
+static int imx_gpc_probe(struct platform_device *pdev)
+{
+ struct device_node *np;
+ int ret;
+
+ np = of_get_child_by_name(pdev->dev.of_node, "pu-power-domain");
+ if (!np) {
+ dev_err(&pdev->dev, "missing pu-power-domain node\n");
+ return -EINVAL;
+ }
+ imx6q_pu_domain.of_node = np;
+
+ pu_reg = devm_regulator_get(&pdev->dev, "pu");
+ if (IS_ERR(pu_reg)) {
+ ret = PTR_ERR(pu_reg);
+ dev_err(&pdev->dev, "failed to get pu regulator: %d\n", ret);
+ return ret;
+ }
+
+ /* The regulator is initially enabled */
+ ret = regulator_enable(pu_reg);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to enable pu regulator: %d\n", ret);
+ return ret;
+ }
+
+ imx6q_pu_domain.of_node = np;
+ imx6q_pm_pu_power_off(&imx6q_pu_domain);
+ pm_genpd_init(&imx6q_pu_domain, NULL, true);
+ bus_register_notifier(&platform_bus_type, &imx6q_platform_nb);
+
+ return 0;
+}
+
+static struct of_device_id imx_gpc_dt_ids[] = {
+ { .compatible = "fsl,imx6q-gpc" },
+ { }
+};
+
+static struct platform_driver imx_gpc_driver = {
+ .driver = {
+ .name = "imx-gpc",
+ .owner = THIS_MODULE,
+ .of_match_table = imx_gpc_dt_ids,
+ },
+ .probe = imx_gpc_probe,
+};
+
+static int __init imx_pgc_init(void)
+{
+ return platform_driver_register(&imx_gpc_driver);
+}
+subsys_initcall(imx_pgc_init);
--
1.8.5.3
^ permalink raw reply related
* [PATCH v2 1/7] Documentation: Add device tree bindings for Freescale i.MX GPC
From: Philipp Zabel @ 2014-02-13 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392302350-11729-1-git-send-email-p.zabel@pengutronix.de>
The i.MX6 contains a power controller that controls power gating and
sequencing for the SoC's power domains.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
.../devicetree/bindings/power/fsl,imx-gpc.txt | 61 ++++++++++++++++++++++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
new file mode 100644
index 0000000..3ec8c0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
@@ -0,0 +1,61 @@
+Freescale i.MX General Power Controller
+=======================================
+
+The i.MX6Q General Power Control (GPC) block contains DVFS load tracking
+counters and Power Gating Control (PGC) for the CPU and PU (GPU/VPU) power
+domains.
+
+Required properties:
+- compatible: Should be "fsl,imx6q-gpc"
+- reg: should be register base and length as documented in the
+ datasheet
+- interrupts: Should contain GPC interrupt request 1
+- pu-supply: Link to the LDO regulator powering the PU power domain
+- #address-cells, #size-cells: Should be <1>
+
+The gpc node should contain 'power-domain' subnodes for each power domain.
+These serve as phandle targets for devices belonging to the power domain:
+
+Power domains controlled by a PGC register set
+==============================================
+
+Required properties:
+- compatible: Should be "fsl,imx6q-power-domain"
+- reg: should be register base and length as documented in the
+ datasheet
+
+Specifying power domain for IP modules
+======================================
+
+IP cores belonging to a power domain should contain a 'power-domain' property
+that is a phandle pointing to the power-domain subnode of the gpc device node.
+
+Required properties:
+- power-domain: A phandle pointing to the power-domain device tree node
+
+
+Example:
+
+ gpc: gpc at 020dc000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,imx6q-gpc";
+ reg = <0x020dc000 0x4000>;
+ interrupts = <0 89 0x04 0 90 0x04>;
+ pu-supply = <®_pu>;
+
+ pd_pu: power-domain at 020dc260 {
+ compatible = "fsl,imx6q-power-domain";
+ reg = <0x020dc260 0x10>;
+ };
+ };
+
+Example of a device that is part of a power domain:
+
+ vpu: vpu at 02040000 {
+ reg = <0x02040000 0x3c000>;
+ /* ... */
+ power-domain = <&pd_pu>;
+ /* ... */
+ };
+
--
1.8.5.3
^ permalink raw reply related
* [PATCH v2 0/7] i.MX6 PU power domain support
From: Philipp Zabel @ 2014-02-13 14:39 UTC (permalink / raw)
To: linux-arm-kernel
The i.MX6Q can gate off the CPU and PU (GPU/VPU) power domains using the
Power Gating Controller (PGC) in the GPC register space. The CPU power
domain is already handled by wait state code, but the PU power domain can
be controlled using the generic power domain framework and power off the PU
supply regulator if all devices in the power domain are (runtime) suspended.
This patchset adds a GPC platform device initialized at subsys_initcall time
(after anatop regulators) that binds to the gpc device tree node and sets up
the PU power domain:
gpc: gpc at 020dc000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,imx6q-gpc";
reg = <0x020dc000 0x4000>;
interrupts = <0 89 0x04 0 90 0x04>;
pu-supply = <®_pu>;
pd_pu: pu-power-domain at 020dc260 {
compatible = "fsl,imx6q-power-domain";
reg = <0x020dc260 0x10>;
};
pd_arm: cpu-power-domain at 020dc2a0 {
compatible = "fsl,imx6q-power-domain";
reg = <0x020dc2a0 0x10>;
};
};
The cpu-power-domain node is included for completeness' sake, it is not
currently used by the code.
It registers a platform bus notifier so that it can add GPU and VPU devices
to the power domain when they are bound. If finds devices to be added to the
power domain by scanning the device tree for nodes that contain a
power-domain = <&pd_pu>;
property.
For i.MX6QDL there is only one power domain that can be disabled at runtime,
on i.MX6SL there is an additional DISPLAY power domain, which is not yet
handled by the code.
Changes since v1:
- Added device tree binding documentation
- Removed a superfluous comment in gpc.c
- Changed the power domain compatible to be less generic
- Link PU domain with its DT node, check for PU domain in bus notifier
- Turn off the PU power domain on boot
- Renamed power-domain node to pu-power-domain and added cpu-power-domain
for i.MX6QDL
- Added dts patch for i.MX6SL
regards
Philipp
Philipp Zabel (7):
Documentation: Add device tree bindings for Freescale i.MX GPC
ARM: imx6: gpc: Add PU power domain for GPU/VPU
ARM: imx6: gpc: Add pm clock support to PU power domain
ARM: imx6: gpc: Add observed worst case latencies
ARM: dts: imx6qdl: Allow disabling the PU regulator, add a enable ramp
delay
ARM: dts: imx6qdl: Add power-domain information to gpc node
ARM: dts: imx6sl: Add power-domain information to gpc node
.../devicetree/bindings/power/fsl,imx-gpc.txt | 61 +++++
arch/arm/boot/dts/imx6qdl.dtsi | 16 +-
arch/arm/boot/dts/imx6sl.dtsi | 18 ++
arch/arm/mach-imx/Kconfig | 2 +
arch/arm/mach-imx/gpc.c | 253 +++++++++++++++++++++
5 files changed, 349 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
--
1.8.5.3
^ permalink raw reply
* [PATCH] ARM: imx_v6_v7_defconfig: Select imx thermal and cpufreq
From: Fabio Estevam @ 2014-02-13 14:32 UTC (permalink / raw)
To: linux-arm-kernel
Let imx thermal and cpufreq drivers be built by default.
Generated by doing:
- Selected imx thermal and cpufreq via 'make menuconfig'
- make savedefconfig
- cp defconfig arch/arm/configs/imx_v6_v7_defconfig
(This is why CONFIG_COMMON_CLK_DEBUG is deleted)
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 7b76794..2d5834f 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -47,6 +47,7 @@ CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
+CONFIG_CPU_FREQ=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_BINFMT_MISC=m
@@ -157,6 +158,9 @@ CONFIG_SPI_IMX=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_MC9S08DZ60=y
# CONFIG_HWMON is not set
+CONFIG_THERMAL=y
+CONFIG_CPU_THERMAL=y
+CONFIG_IMX_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_IMX2_WDT=y
CONFIG_MFD_DA9052_I2C=y
@@ -245,7 +249,6 @@ CONFIG_DRM_IMX_TVE=y
CONFIG_DRM_IMX_LDB=y
CONFIG_DRM_IMX_IPUV3_CORE=y
CONFIG_DRM_IMX_IPUV3=y
-CONFIG_COMMON_CLK_DEBUG=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_PWM=y
CONFIG_PWM_IMX=y
--
1.8.1.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox