* [PATCH v3 5/7] ARM: brcmstb: add misc. DT bindings for brcm, brcmstb-*
From: Marc Carino @ 2014-01-14 23:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389743333-16741-1-git-send-email-marc.ceeeee@gmail.com>
Document the bindings that the Broadcom STB platform needs
for proper bootup.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
.../devicetree/bindings/arm/brcm-brcmstb.txt | 43 ++++++++++++++++++++
1 files changed, 43 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
diff --git a/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
new file mode 100644
index 0000000..5f1aba7
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
@@ -0,0 +1,43 @@
+Broadcom STB platforms Device Tree Bindings
+-------------------------------------------
+Boards with Broadcom Brahma15 ARM-based BCM7xxx SoC shall have the following
+properties.
+
+Required root node properties:
+
+ - compatible = "brcm,brcmstb-<chip_id>";
+
+Further, a node with the following compatible string shall be defined:
+
+ - compatible: "brcm,brcmstb-gen-ctrl-v1"
+
+brcmstb-gen-ctrl
+----------------
+This node describes the registers needed for reset and CPU power control.
+
+ - compatible: "brcm,brcmstb-gen-ctrl-v1"
+ - properties:
+ o reg = <rst-src-en-reg-base len
+ sw-mstr-rst-reg-base len
+ cpu-rst-cfg-reg-base len
+ cpu-pwr-zone-ctrl-reg-base len
+ stb-boot-hi-addr0-reg len>;
+
+example:
+/ {
+ model = "Broadcom STB";
+ compatible = "brcm,brcmstb-7445";
+
+ /* snip */
+
+ gen-ctrl {
+ compatible = "brcm,brcmstb-gen-ctrl-v1";
+ reg = <0xf0404304 0x4
+ 0xf0404308 0x4
+ 0xf03e2578 0x4
+ 0xf03e2488 0x10
+ 0xf0452000 0x20>;
+ };
+
+ /* snip */
+};
--
1.7.1
^ permalink raw reply related
* [PATCH v3 6/7] ARM: brcmstb: gic: add compatible string for Broadcom Brahma15
From: Marc Carino @ 2014-01-14 23:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389743333-16741-1-git-send-email-marc.ceeeee@gmail.com>
Document the Broadcom Brahma B15 GIC implementation as compatible
with the ARM GIC standard.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/devicetree/bindings/arm/gic.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index 3dfb0c0..b7d7970 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -15,6 +15,7 @@ Main node required properties:
"arm,cortex-a9-gic"
"arm,cortex-a7-gic"
"arm,arm11mp-gic"
+ "brcm,brahma15-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.
--
1.7.1
^ permalink raw reply related
* [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
From: Marc Carino @ 2014-01-14 23:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389743333-16741-1-git-send-email-marc.ceeeee@gmail.com>
Add a sample DTS which will allow bootup of a board populated
with the BCM7445 chip.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/boot/dts/brcmstb-7445.dts | 104 ++++++++++++++++++++++++++++++++++++
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/brcmstb-7445.dts
diff --git a/arch/arm/boot/dts/brcmstb-7445.dts b/arch/arm/boot/dts/brcmstb-7445.dts
new file mode 100644
index 0000000..cbe73b4
--- /dev/null
+++ b/arch/arm/boot/dts/brcmstb-7445.dts
@@ -0,0 +1,104 @@
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ model = "Broadcom STB (7445)";
+ compatible = "brcm,brcmstb-7445";
+ interrupt-parent = <&gic>;
+
+ chosen {};
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x40000000 0x40000000 0x40000000 0x80000000 0x40000000>;
+ };
+
+ cpupll: cpupll at 0 {
+ #clock-cells = <0x0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1500000000>;
+ };
+
+ cpuclk: cpu-clk-div at 0 {
+ #clock-cells = <0x0>;
+ compatible = "brcm,brcmstb-cpu-clk-div";
+ reg = <0xf03e257c 0x4>;
+ clocks = <&cpupll>;
+ div-table = <0x0 0x1 0x11 0x2 0x12 0x4 0x13 0x8 0x14 0x10>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at 0 {
+ compatible = "brcm,brahma15";
+ operating-points = <0x16e360 0x0
+ 0x0b71b0 0x0
+ 0x05b8d8 0x0
+ 0x02dc6c 0x0
+ 0x016e36 0x0>;
+ clocks = <&cpuclk>;
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <1500000000>;
+ };
+
+ cpu at 1 {
+ compatible = "brcm,brahma15";
+ device_type = "cpu";
+ reg = <1>;
+ clock-frequency = <1500000000>;
+ };
+
+ cpu at 2 {
+ compatible = "brcm,brahma15";
+ device_type = "cpu";
+ reg = <2>;
+ clock-frequency = <1500000000>;
+ };
+
+ cpu at 3 {
+ compatible = "brcm,brahma15";
+ device_type = "cpu";
+ reg = <3>;
+ clock-frequency = <1500000000>;
+ };
+ };
+
+ gic: interrupt-controller at ffd00000 {
+ compatible = "brcm,brahma15-gic", "arm,cortex-a15-gic";
+ reg = <0xffd01000 0x1000
+ 0xffd02000 0x2000>;
+ interrupt-controller;
+ #interrupt-cells = <0x3>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <1 13 0xf08
+ 1 14 0xf08
+ 1 11 0xf08
+ 1 10 0xf08>;
+ };
+
+ serial at f0406b00 {
+ compatible = "ns16550a";
+ reg = <0xf0406b00 0x20>;
+ reg-shift = <0x2>;
+ reg-io-width = <0x4>;
+ interrupts = <0x0 0x4b 0x4>;
+ clock-frequency = <0x4d3f640>;
+ };
+
+ gen-ctrl {
+ compatible = "brcm,brcmstb-gen-ctrl-v1";
+ reg = <0xf0404304 0x4
+ 0xf0404308 0x4
+ 0xf03e2578 0x4
+ 0xf03e2488 0x10
+ 0xf0452000 0x20>;
+ };
+};
--
1.7.1
^ permalink raw reply related
* [PATCH] irq-gic: remove file name from heading comment
From: Sergei Shtylyov @ 2014-01-14 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201312140224.53928.sergei.shtylyov@cogentembedded.com>
Hello.
On 12/14/2013 02:24 AM, Sergei Shtylyov wrote:
> File names in the heading comments fell out of favor long ago, and this one
> weren't even changed when the driver was moved from arch/arm/common/, so remove
> it at last...
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
> The patch is against the 'irq/core' branch of the 'tip.git' repo.
Thomas, is there a chance that you merge this patch for 3.14? Is it even
the right branch for cleanups (I'm seeing fixes there)?
WBR, Sergei
^ permalink raw reply
* [PATCH 0/9] Renesas RSPI/QSPI DT support
From: Simon Horman @ 2014-01-14 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWMZE23JkEr7Weq6MWgPK5w-Gy_kus5HxvcLBdgPn5Daw@mail.gmail.com>
On Tue, Jan 14, 2014 at 09:40:34AM +0100, Geert Uytterhoeven wrote:
> On Tue, Jan 14, 2014 at 1:53 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Sun, Jan 12, 2014 at 01:55:19PM +0100, Geert Uytterhoeven wrote:
> >> On Sun, Jan 12, 2014 at 12:13 PM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >
> > [1/9] spi: rspi: Add missing clk_disable() calls in error and cleanup paths
> > [2/9] spi: rspi: Convert to clk_prepare_enable/disable_unprepare
> > [3/9] spi: rspi: Use NULL as the clock ID
> > [4/9][V3] spi: rspi: Add DT support
> >
> >> > [5/9] ARM: shmobile: r7s72100: Add RSPI clocks for DT
> >> > [6/9][V3] ARM: shmobile: r7s72100 dtsi: Add RSPI nodes
> >> > [7/9][V3] ARM: shmobile: genmai reference: Add RSPI nodes
> >> > [8/9] ARM: shmobile: r8a7791 dtsi: Add QSPI node
> >> > [9/9] ARM: shmobile: koelsch: Add QSPI nodes
> >>
> >> Forgot to mention:
> >>
> >> The ARM/shmobile part is based on renesas-devel-v3.13-rc7-20140109v2, with
> >> Magnus' pinctrl, Wolfram's riic, Simon's sh_eth, Valentine's i2c pinctrl
> >> and Laurent's SCIF DT work applied on top.
> >> [Simon: I don't know in which order you will merge these. If you want me
> >> to rebase my patches, just ask! Thanks!]
> >
> > Firstly, I would like an Ack from Magnus on the shmobile patches.
> >
> > With regards to merge order, my preference is to merge patches
> > in parallel once their dependencies will no longer change.
> >
> > So for this series it lools like.
> >
> > 5/9: Can be merged independently of other patches in the series.
> > But there isn't much point in merging it until the rest of the
> > series is acked and tested.
>
> OK.
>
> > 6-9/9: Needs to wait until 4/9 has at least been acked by Mark
>
> OK. Based on Mark's comments, there will be a V4.
>
> > Also, is 1/9 a run-time dependency of these changes?
>
> 1/9 is a bugfix. I'll send a rebased version to Mark, as he wanted to
> get that one in first.
>
> 2-3/9 are run-time dependencies, but 2/9 won't apply without 1/9.
run-time dependencies of 6-9/9 ?
^ permalink raw reply
* [PATCH V2 0/3] SoC and board integration for QSPI on r8a7791/koelsch
From: Simon Horman @ 2014-01-14 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWYqv41RwyZROmuSeD9F9RfFFyOuCxn+66NgJ3MbhsJvw@mail.gmail.com>
On Tue, Jan 14, 2014 at 10:05:28AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Tue, Jan 14, 2014 at 1:46 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Sun, Jan 12, 2014 at 12:00:29PM +0100, Geert Uytterhoeven wrote:
> >> This series adds support for the Spansion s25fl512s SPI FLASH on the
> >> r8a7791-based Koelsch board. It is based on
> >> renesas-devel-v3.13-rc7-20140109v2, with Valentine's i2c pinctrl and
> >> Laurent's SCIF DT work applied on top.
> >> [Simon: I don't know in which order you will merge these. If you want me
> >> to rebase my patches, just ask! Thanks!]
> >
> > I see that Laruent has taken patch 1/4.
> >
> > Is it possible for me to merge patches 2-4/4 independently of that patch?
> > That is, can I apply them and still produce a kernel that boots. If so,
> > that is my preferred option. If not I will talk to Laurent about a branch
> > to base things on.
>
> Yes you can. Note that RSPI still won't be enabled without "spi: rspi: Remove
> dependency on DMAE for SHMOBILE" (which has now landed in the spi tree).
> And with that patch applied, you'll get warnings like:
>
> pinmux core: sh-pfc does not support function qspi
> sh-pfc pfc-r8a7791: invalid function qspi in map table
> pinmux core: sh-pfc does not support function qspi
> sh-pfc pfc-r8a7791: invalid function qspi in map table
>
> which are harmless, and spi will still work, as that's the default pin config
> anyway.
Thanks, that is perfectly fine.
> > Also, I would like to get an Ack from Magnus.
>
> Sure.
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
^ permalink raw reply
* [GIT PULL] SOCFPGA DT updates for 3.14
From: Kevin Hilman @ 2014-01-14 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389214300-5806-1-git-send-email-dinguyen@altera.com>
<dinguyen@altera.com> writes:
> Hi Arnd, Kevin, and Olof,
>
> Please consider pulling in these 2 SOCFPGA DT patches for v3.14.
>
> Thanks,
> Dinh
>
> The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e:
>
> Linux 3.13-rc3 (2013-12-06 09:34:04 -0800)
>
> are available in the git repository at:
>
> git://git.rocketboards.org/linux-socfpga-next.git tags/socfpga-dt-for-3.14
>
> for you to fetch changes up to 672ef909e9b10933dc676c87d1bdeaabfcc11dda:
>
> ARM: dts: socfpga: add pl330 clock (2014-01-08 12:04:03 -0600)
>
> ----------------------------------------------------------------
> SOCFPGA DT updates for v3.14
>
> ----------------------------------------------------------------
Pulled into next/dt.
Thanks,
Kevin
^ permalink raw reply
* [GIT PULL]ARM: sirf: dts update for 3.14
From: Kevin Hilman @ 2014-01-14 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4yx=U2dQ6ZkGAtvEwUPdWRwotJae8Sk+g+gqczV0JEo0w@mail.gmail.com>
Barry Song <21cnbao@gmail.com> writes:
> Hi Olof,
> The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e:
>
> Linux 3.13-rc3 (2013-12-06 09:34:04 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux.git
> tags/sirf-dts-for-3.14
>
> for you to fetch changes up to 73f68c01f468f072776d98f6bbf7fb367a1f2540:
>
> ARM: dts: SiRF: add pin group for USP0 with only RX or TX frame sync
> (2014-01-09 20:05:31 +0800)
>
> ----------------------------------------------------------------
> ARM: sirf: dts update for 3.14
>
> some missed dt nodes or props for sirf dts for 3.14.
> Among them:
> - add lost clocks for cphifbg
> - add lost bus_width, clock and status for sdhci
> - add clock, frequence-voltage table for CPU0
> - add lost minigpsrtc device node
> - add lost usp1_uart_nostreamctrl pin group for atlas6
> - add pin group for USP0 with only RX or TX frame sync
>
> ----------------------------------------------------------------
Pulled into next/dt.
Thanks,
Kevin
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Fixes for v3.14
From: Simon Horman @ 2014-01-15 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a9ey8kt5.fsf@linaro.org>
On Tue, Jan 14, 2014 at 10:44:54AM -0800, Kevin Hilman wrote:
> Simon Horman <horms+renesas@verge.net.au> writes:
>
> > Hi Olof, Hi Kevin, Hi Arnd,
> >
> > please consider these renesas ARM Based SoC Fixes for v3.14.
> >
> > This pull-request is based on the Third Round of Renesas ARM Based SoC
> > Updates for v3.14, tagged as renesas-soc3-for-v3.14, which you have
> > previously pulled.
> >
> > It resolves a problem introduced by a patch included in the second round of such
> > changes, tagged as renesas-soc2-for-v3.14, which you have also previously
> > pulled.
> >
> > renesas-soc3-for-v3.14 is based on renesas-soc2-for-v3.14.
>
> Applied.
>
> Since your soc3 branch was included in our next/soc branch, I've just
> added the fix there as well.
Thanks.
^ permalink raw reply
* [PATCH v4 5/6] spmi: document the PMIC arbiter SPMI bindings
From: Courtney Cavin @ 2014-01-15 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6dbb1c77001542e093d3af09ea976d402ed24d17.1389738151.git.joshc@codeaurora.org>
On Tue, Jan 14, 2014 at 07:41:39PM +0100, Josh Cartwright wrote:
> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> ---
> .../bindings/spmi/qcom,spmi-pmic-arb.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
>
> diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
> new file mode 100644
> index 0000000..9e50cb3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
> @@ -0,0 +1,46 @@
> +Qualcomm SPMI Controller (PMIC Arbiter)
> +
> +The SPMI PMIC Arbiter is found on the Snapdragon 800 Series. It is an SPMI
> +controller with wrapping arbitration logic to allow for multiple on-chip
> +devices to control a single SPMI master.
> +
> +The PMIC Arbiter can also act as an interrupt controller, providing interrupts
> +to slave devices.
> +
> +See spmi.txt for the generic SPMI controller binding requirements for child
> +nodes.
> +
> +Required properties:
> +- compatible : should be "qcom,spmi-pmic-arb".
> +- reg-names : should be "core", "intr", "cnfg"
> +- reg : register specifiers, must contain 3 entries, in the follow order:
> + core registers, interrupt controller registers, configuration registers
As far as I can tell, patch 3/6 doesn't require these to be in any
order, as it uses 'reg-names' to fetch the values. Perhaps the
following:
reg-names : must contain:
"core" - core registers
"intr" - interrupt controller registers
"cnfg" - configuration registers
reg : A list of address + size pairs for the regs listed in reg-names
> +- #address-cells : must be set to 2
> +- #size-cells : must be set to 0
> +- qcom,ee : indicates the active Execution Environment identifier (0-5)
> +- qcom,channel : which of the PMIC Arb provided channels to use for accesses (0-5)
These two are new.... Is it expected that they should be required?
> +- interrupt-controller : indicates the PMIC arbiter is an interrupt controller
Although it's probably fairly understood that this is a boolean, it
wouldn't hurt to mention that here. It might also be worth referencing
devicetree/binding/interrupt-controller/interrupts.txt in your opening
blurb.
> +- #interrupt-cells = <4>: interrupts are specified as a 4-tuple:
Nitpick: This '= <X>' differs from the above 'must be set to X' format.
> + cell 1: slave ID for the requested interrupt (0-15)
> + cell 2: peripheral ID for requested interrupt (0-255)
> + cell 3: the requested peripheral interrupt (0-7)
> + cell 4: interrupt flags indicating level-sense information, as defined in
> + dt-bindings/interrupt-controller/irq.h
[...]
-Courtney
^ permalink raw reply
* [PATCH V3 0/3] Enable X-Gene platform reboot driver.
From: Feng Kan @ 2014-01-15 1:07 UTC (permalink / raw)
To: linux-arm-kernel
Enable X-Gene platform driver for the X-Gene platform. Change the
driver to use syscon to access the system clock unit's system
reset register.
V2 Change:
- Add support for using ACPI resource.
V3 Change:
- Remove the reboot driver's use of acpi resource patch.
- Change the reboot driver to use syscon to parse out
system clock register. Remove the old method of getting
register from the reboot driver directly.
- Remove documentation since its now simple.
Feng Kan (3):
arm64: add reboot dts entry for X-Gene platform.
arm64: Enable system reset via arch Kconfig for X-Gene system.
power: reset: use syscon driver to parse reboot register from scu
arch/arm64/Kconfig | 2 ++
arch/arm64/boot/dts/apm-storm.dtsi | 10 ++++++++++
drivers/power/reset/xgene-reboot.c | 33 +++++++++++++++++----------------
3 files changed, 29 insertions(+), 16 deletions(-)
--
1.7.6.1
^ permalink raw reply
* [PATCH V3 1/3] arm64: add reboot dts entry for X-Gene platform.
From: Feng Kan @ 2014-01-15 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389748055-23534-1-git-send-email-fkan@apm.com>
Add missing dts entries for the X-Gene reboot driver.
Signed-off-by: Feng Kan <fkan@apm.com>
---
arch/arm64/boot/dts/apm-storm.dtsi | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
index d37d736..7beac9d 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -103,6 +103,11 @@
#size-cells = <2>;
ranges;
+ scu: system-clk-controller at 17000000 {
+ compatible = "apm,xgene-scu","syscon";
+ reg = <0x0 0x17000000 0x0 0x400>;
+ };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
@@ -187,5 +192,10 @@
interrupt-parent = <&gic>;
interrupts = <0x0 0x4c 0x4>;
};
+
+ reboot at 17000014 {
+ compatible = "apm,xgene-reboot";
+ apm,scu = <&scu>;
+ };
};
};
--
1.7.6.1
^ permalink raw reply related
* [PATCH V3 2/3] arm64: Enable system reset via arch Kconfig for X-Gene system.
From: Feng Kan @ 2014-01-15 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389748055-23534-1-git-send-email-fkan@apm.com>
Select X-Gene reboot driver for X-Gene platform.
Signed-off-by: Feng Kan <fkan@apm.com>
---
arch/arm64/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 249acb9..bfdf029 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -122,6 +122,8 @@ config ARCH_VEXPRESS
config ARCH_XGENE
bool "AppliedMicro X-Gene SOC Family"
+ select POWER_RESET_XGENE
+ select MFD_SYSCON
help
This enables support for AppliedMicro X-Gene SOC Family
--
1.7.6.1
^ permalink raw reply related
* [PATCH V3 3/3] power: reset: use syscon driver to parse reboot register from scu
From: Feng Kan @ 2014-01-15 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389748055-23534-1-git-send-email-fkan@apm.com>
Use the syscon driver to parse out the reboot register map and issue
reboot via the regmap function.
Signed-off-by: Feng Kan <fkan@apm.com>
---
drivers/power/reset/xgene-reboot.c | 75 +++++++++---------------------------
1 files changed, 19 insertions(+), 56 deletions(-)
diff --git a/drivers/power/reset/xgene-reboot.c b/drivers/power/reset/xgene-reboot.c
index ecd55f8..660ed8a 100644
--- a/drivers/power/reset/xgene-reboot.c
+++ b/drivers/power/reset/xgene-reboot.c
@@ -24,80 +24,43 @@
* For system shutdown, this is board specify. If a board designer
* implements GPIO shutdown, use the gpio-poweroff.c driver.
*/
-#include <linux/io.h>
#include <linux/of_device.h>
#include <linux/of_address.h>
#include <linux/platform_device.h>
-#include <linux/stat.h>
-#include <linux/slab.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/reboot.h>
#include <asm/system_misc.h>
-struct xgene_reboot_context {
- struct platform_device *pdev;
- void *csr;
- u32 mask;
-};
+#define SCU_SRST 0x14
-static struct xgene_reboot_context *xgene_restart_ctx;
-
-static void xgene_restart(char str, const char *cmd)
+static void xgene_restart(enum reboot_mode reboot_mode, const char *cmd)
{
- struct xgene_reboot_context *ctx = xgene_restart_ctx;
unsigned long timeout;
+ struct regmap *map;
+ unsigned int ret;
+ struct device_node *dn;
+
+ dn = of_find_node_by_name(NULL, "reboot");
+ map = syscon_regmap_lookup_by_phandle(dn, "apm,scu");
+ if (IS_ERR(map)) {
+ ret = PTR_ERR(map);
+ pr_err("Reboot driver failed to get scu regmap: %d\n", ret);
+ return;
+ }
- /* Issue the reboot */
- if (ctx)
- writel(ctx->mask, ctx->csr);
+ regmap_write(map, SCU_SRST, 0x1);
timeout = jiffies + HZ;
while (time_before(jiffies, timeout))
cpu_relax();
- dev_emerg(&ctx->pdev->dev, "Unable to restart system\n");
+ pr_emerg("Unable to restart system\n");
}
-static int xgene_reboot_probe(struct platform_device *pdev)
+static int __init xgene_reboot_init(void)
{
- struct xgene_reboot_context *ctx;
-
- ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
- if (!ctx) {
- dev_err(&pdev->dev, "out of memory for context\n");
- return -ENODEV;
- }
-
- ctx->csr = of_iomap(pdev->dev.of_node, 0);
- if (!ctx->csr) {
- devm_kfree(&pdev->dev, ctx);
- dev_err(&pdev->dev, "can not map resource\n");
- return -ENODEV;
- }
-
- if (of_property_read_u32(pdev->dev.of_node, "mask", &ctx->mask))
- ctx->mask = 0xFFFFFFFF;
-
- ctx->pdev = pdev;
arm_pm_restart = xgene_restart;
- xgene_restart_ctx = ctx;
-
return 0;
}
-
-static struct of_device_id xgene_reboot_of_match[] = {
- { .compatible = "apm,xgene-reboot" },
- {}
-};
-
-static struct platform_driver xgene_reboot_driver = {
- .probe = xgene_reboot_probe,
- .driver = {
- .name = "xgene-reboot",
- .of_match_table = xgene_reboot_of_match,
- },
-};
-
-static int __init xgene_reboot_init(void)
-{
- return platform_driver_register(&xgene_reboot_driver);
-}
device_initcall(xgene_reboot_init);
--
1.7.6.1
^ permalink raw reply related
* [PATCH 1/3] mmc: dw_mmc: use slot-gpio to handle cd pin
From: zhangfei @ 2014-01-15 1:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMi5bK6siLQ2dVkR7P30+5zQa8qsyxa3UsWj0Kw9OEXCPw@mail.gmail.com>
On 01/15/2014 01:23 AM, Olof Johansson wrote:
> On Tue, Jan 14, 2014 at 7:58 AM, Kevin Hilman <khilman@linaro.org> wrote:
>> On Thu, Jan 9, 2014 at 6:35 AM, Zhangfei Gao <zhangfei.gao@linaro.org> wrote:
>>> Suggested by Jaehoon: Use slot-gpio to handle cd-gpio
>>> Add function dw_mci_of_get_cd_gpio to check "cd-gpios" from dts.
>>> mmc_gpio_request_cd and mmc_gpio_get_cd are used to handle cd pin
>>>
>>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>>> Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
>>
>> The Samsung Arndale board started failing boot from MMC root tests
>> starting with next-20140113 and I bisected it down to this patch.
>> Reverting this patch on top of next-20140114 gets Arndale booting
>> again from MMC. Is there some supporting DT data that's missing for
>> Arndale?
>
> Rather, it looks like this patch changes behaviour and no longer uses
> dw_mci_get_cd() to find out if there's a card attached -- it switches
> to rely only on GPIO (see the last chunk in the patch). That seems
> broken?
>
Oops,
Change using dw_mci_get_cd set flag DW_MMC_CARD_PRESENT.
And dw_mci_get_cd is called from mmc_rescan, a litter later than
dw_mci_probe.
Is that too late?
Thanks
^ permalink raw reply
* [PATCH 1/2] clk: hisilicon: add hi3620_mmc_clks
From: zhangfei @ 2014-01-15 1:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114201740.4167.52076@quantum>
Dear Mike
On 01/15/2014 04:17 AM, Mike Turquette wrote:
> Quoting Zhangfei Gao (2014-01-13 01:14:28)
>> Suggest by Arnd: abstract mmc tuning as clock behavior,
>> also because different soc have different tuning method and registers.
>> hi3620_mmc_clks is added to handle mmc clock specifically on hi3620.
>>
>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>> Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
>
> Patch looks good to me with one exception. I do not have
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt in the
> clk-next branch. Is there a stable branch I can pull in as a dependency?
Mach-hisi just have been uploaeded.
Have tried next-20140114, the patch can be applied successfully.
While v3.13-rc8 still can not.
Is this fine?
Thanks
^ permalink raw reply
* [PATCH V6 6/8] Add EFI stub for ARM
From: Roy Franz @ 2014-01-15 1:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9OfieNhvj07tQv+ucQomZhDVDxwdV3Z9Tm+HaHE8HG-Q@mail.gmail.com>
On Tue, Jan 14, 2014 at 1:05 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 10 January 2014 17:30, Roy Franz <roy.franz@linaro.org> wrote:
>> This patch adds EFI stub support for the ARM Linux kernel. The EFI stub
>> operates similarly to the x86 stub: it is a shim between the EFI firmware
>> and the normal zImage entry point, and sets up the environment that the
>> zImage is expecting. This includes loading the initrd (optionaly) and
>> device tree from the system partition based on the kernel command line.
>> The stub updates the device tree as necessary, adding entries for EFI
>> runtime services. The PE/COFF "MZ" header at offset 0 results in the
>> first instruction being an add that corrupts r5, which is not used by
>> the zImage interface.
>>
>> Signed-off-by: Roy Franz <roy.franz@linaro.org>
>> Acked-by: Grant Likely <grant.likely@linaro.org>
>> ---
>
> [...]
>
>> diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
>> new file mode 100644
>> index 0000000..dbb7101
>> --- /dev/null
>> +++ b/arch/arm/boot/compressed/efi-header.S
>> @@ -0,0 +1,117 @@
>> +@ Copyright (C) 2013 Linaro Ltd; <roy.franz@linaro.org>
>> +@
>> +@ This file contains the PE/COFF header that is part of the
>> +@ EFI stub.
>> +@
>> +
>> + .org 0x3c
>> + @
>> + @ The PE header can be anywhere in the file, but for
>> + @ simplicity we keep it together with the MSDOS header
>> + @ The offset to the PE/COFF header needs to be at offset
>> + @ 0x3C in the MSDOS header.
>> + @ The only 2 fields of the MSDOS header that are used are this
>> + @ PE/COFF offset, and the "MZ" bytes at offset 0x0.
>> + @
>> + .long pe_header @ Offset to the PE header.
>> +
>> + .align 3
>> +pe_header:
>> + .ascii "PE"
>> + .short 0
>> +
>> +coff_header:
>> + .short 0x01c2 @ ARM or Thumb
>
> Could you explain why you are using 0x1c2 (Thumb) here and not 0x1c0 (ARM) ?
>
> Cheers,
> Ard.
Nope. It should be 0x1c0.
Roy
^ permalink raw reply
* [PATCH 1/2] usb: chipidea: usbmisc: Add support for i.MX27/i.MX31 CPUs
From: Chris Ruehl @ 2014-01-15 1:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114134942.GY29475@pengutronix.de>
On Tuesday, January 14, 2014 09:49 PM, Uwe Kleine-K?nig wrote:
> Hello Chris,
>
> On Tue, Jan 14, 2014 at 11:53:47AM +0800, Chris Ruehl wrote:
>> On Tuesday, January 14, 2014 11:30 AM, Alexander Shiyan wrote:
>>> ???????????, 13 ?????? 2014, 22:31 +01:00 ?? Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>>>> On Sat, Jan 11, 2014 at 06:01:48PM +0400, Alexander Shiyan wrote:
>>>>> ???????, 11 ?????? 2014, 13:55 +01:00 ?? Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>>>>>> On Mon, Nov 11, 2013 at 11:09:16AM +0400, Alexander Shiyan wrote:
>>>>>>> Hello.
>>>>>>>
>>>>>>>>>>>> On Sunday, November 10, 2013 03:18 PM, Alexander Shiyan wrote:
>>>>>>>>>>>>> This adds i.MX27 and i.MX31 as the next user of the usbmisc driver.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Alexander Shiyan<shc_work@mail.ru>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> drivers/usb/chipidea/usbmisc_imx.c | 42 ++++++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>> 1 file changed, 42 insertions(+)
>>>>>>> ...
>>>>>>>> At this point might be good to patch the imx27.dtsi with the usb defines.
>>>>>>> ...
>>>>>>>
>>>>>>> I have a working configuration for i.MX27 USB, but I prefer to make a few more
>>>>>>> tests before the addition of definitions in DTS. This will be a next step.
>>>>>>> Thanks.
>>>>>> Any news here?
>>>>> Not ready yet.
>>>> Are you still working at it? Would you mind sharing more details, like
>>>> your current tree/patch stack and what works/doesn't work for you?
>>>
>>> Now my work on this is suspended, but will continue later.
>>> I'll send you a personal letter with DT configuration.
>>> Ports (both Host & OTG) are detected by kernel, but works Host only.
>>> OTG not works nor as Host, nor as Device...
>>>
>>> ---
>> hi,
>> I'm still working on my patches for imx27 and ULPI integration. But
>> have more urgent things in the queue.
>
> Starting from here I'm not sure I understand you.
>> I have a running version but it cant make it in the kernel. Rework
>> on platform device code needed.
I have a customized board running OTG/host and USB2/host (USB1 not connected)
Both ports are connected to a ISP1504 ULPI
a) I need a rs-gpio to reset in addition to the cs-gpio the ISP1504 (done)
b) Implement UPLI viewport (IORESOURCE_MEM) and logic to set the external power
supply.
The code (b) was rejected and needs rework.
>> Just wait until the patches already accepted appears in the
>> linux-next before commit new patches.
>
> That means: USB works for you? What does "it cant make it in the kernel"
> mean? Problems to upstream it?
> Do you wait or should I?
I will fix the problem with (b) and resend my patches.
>
> Best regards
> Uwe
>
--
GTSYS Limited RFID Technology
A01 24/F Gold King Industrial Bld
35-41 Tai Lin Pai Road, Kwai Chung, Hong Kong
Fax (852) 8167 4060 - Tel (852) 3598 9488
Disclaimer: http://www.gtsys.com.hk/email/classified.html
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Felipe Balbi @ 2014-01-15 2:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114203613.GA604@saruman.home>
Hi,
On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote:
> > Felipe, care to run your randconfig magic for this?
>
> This branch builds just fine so far, I still have omap5 multiplaform and
> uniplatform builds, but since that was working before i'm assuming it
> won't break.
No build failures in any of my 18 seeds (5 randconfigs of each), I'd
attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can
send it.
FWIW:
Acked-by: Felipe Balbi <balbi@ti.com>
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140114/ec6a466f/attachment.sig>
^ permalink raw reply
* [PATCH V6 6/8] Add EFI stub for ARM
From: Roy Franz @ 2014-01-15 2:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFECyb9jx4NA0v_qNgrto4qG3KV3fBOpGh839Mnvbjody4xwYA@mail.gmail.com>
On Tue, Jan 14, 2014 at 5:47 PM, Roy Franz <roy.franz@linaro.org> wrote:
> On Tue, Jan 14, 2014 at 1:05 AM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 10 January 2014 17:30, Roy Franz <roy.franz@linaro.org> wrote:
>>> This patch adds EFI stub support for the ARM Linux kernel. The EFI stub
>>> operates similarly to the x86 stub: it is a shim between the EFI firmware
>>> and the normal zImage entry point, and sets up the environment that the
>>> zImage is expecting. This includes loading the initrd (optionaly) and
>>> device tree from the system partition based on the kernel command line.
>>> The stub updates the device tree as necessary, adding entries for EFI
>>> runtime services. The PE/COFF "MZ" header at offset 0 results in the
>>> first instruction being an add that corrupts r5, which is not used by
>>> the zImage interface.
>>>
>>> Signed-off-by: Roy Franz <roy.franz@linaro.org>
>>> Acked-by: Grant Likely <grant.likely@linaro.org>
>>> ---
>>
>> [...]
>>
>>> diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
>>> new file mode 100644
>>> index 0000000..dbb7101
>>> --- /dev/null
>>> +++ b/arch/arm/boot/compressed/efi-header.S
>>> @@ -0,0 +1,117 @@
>>> +@ Copyright (C) 2013 Linaro Ltd; <roy.franz@linaro.org>
>>> +@
>>> +@ This file contains the PE/COFF header that is part of the
>>> +@ EFI stub.
>>> +@
>>> +
>>> + .org 0x3c
>>> + @
>>> + @ The PE header can be anywhere in the file, but for
>>> + @ simplicity we keep it together with the MSDOS header
>>> + @ The offset to the PE/COFF header needs to be at offset
>>> + @ 0x3C in the MSDOS header.
>>> + @ The only 2 fields of the MSDOS header that are used are this
>>> + @ PE/COFF offset, and the "MZ" bytes at offset 0x0.
>>> + @
>>> + .long pe_header @ Offset to the PE header.
>>> +
>>> + .align 3
>>> +pe_header:
>>> + .ascii "PE"
>>> + .short 0
>>> +
>>> +coff_header:
>>> + .short 0x01c2 @ ARM or Thumb
>>
>> Could you explain why you are using 0x1c2 (Thumb) here and not 0x1c0 (ARM) ?
>>
>> Cheers,
>> Ard.
>
> Nope. It should be 0x1c0.
>
> Roy
OK, now I resolved the nagging feeling that I had already fixed
this... Right now, the EDK2 UEFI implementation
requires the machine type for ARM to be "0x1c2". I don't think that
this is correct, but correcting this in EDK2 slipped through
the cracks, but is now back on my todo list.
I think that for now we should leave this as 0x1c2 so that the
unpatched EDK2 builds will boot it, and some time after EDK2 is
updated
this can be changed. I'll work on a patch for EDK2 and get the
discussion going on that list to resolve this in EDK2.
Roy
^ permalink raw reply
* [GIT PULL]ARM: sirf: machine update for 3.14
From: Barry Song @ 2014-01-15 2:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kevin/Olof,
The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e:
Linux 3.13-rc3 (2013-12-06 09:34:04 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux.git
tags/sirf-soc-for-3.14
for you to fetch changes up to dbd1b42baa6ec8082bce6eec37de5e1b46aff19c:
ARM: prima2: make sirfsoc_init_late function static (2014-01-15
10:42:26 +0800)
----------------------------------------------------------------
ARM: sirf: machine update for 3.14
Among them:
- ARM: prima2: move to generic reset controller driver framework
- MAINTAINERS: ARM: SiRF: use regex patterns to involve all SiRF drivers
- ARM: prima2: make sirfsoc_init_late function static
----------------------------------------------------------------
Barry Song (3):
ARM: prima2: move to generic reset controller driver framework
MAINTAINERS: ARM: SiRF: use regex patterns to involve all SiRF drivers
ARM: prima2: make sirfsoc_init_late function static
.../devicetree/bindings/reset/sirf,rstc.txt | 42 +++++++++
MAINTAINERS | 9 +-
arch/arm/boot/dts/atlas6.dtsi | 3 +-
arch/arm/boot/dts/marco.dtsi | 3 +-
arch/arm/boot/dts/prima2.dtsi | 3 +-
arch/arm/mach-prima2/Kconfig | 1 +
arch/arm/mach-prima2/common.c | 2 +-
arch/arm/mach-prima2/rstc.c | 93 +++++++++++++-------
8 files changed, 110 insertions(+), 46 deletions(-)
create mode 100644 Documentation/devicetree/bindings/reset/sirf,rstc.txt
-barry
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Mike Turquette @ 2014-01-15 3:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115020421.GA24195@saruman.home>
Quoting Felipe Balbi (2014-01-14 18:04:21)
> Hi,
>
> On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote:
> > > Felipe, care to run your randconfig magic for this?
> >
> > This branch builds just fine so far, I still have omap5 multiplaform and
> > uniplatform builds, but since that was working before i'm assuming it
> > won't break.
>
> No build failures in any of my 18 seeds (5 randconfigs of each), I'd
> attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can
> send it.
>
> FWIW:
>
> Acked-by: Felipe Balbi <balbi@ti.com>
Felipe,
That's great to hear. Thanks for testing.
Tero & Tony,
These 40 patches apply very cleanly on top of clk-next with 2
exceptions:
1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data"
because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based
on 3.13-rc1).
2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I
resolved correctly but would like verification.
I'd prefer to simply merge these patches into clk-next, which is the
most straightforward route. Any ideas on how to handle the missing
AM35xx dtsi data? It can always go as a separate fix after this stuff
gets merged which, ironically, is how that file was created in the first
place.
Regards,
Mike
>
> cheers
>
> --
> balbi
^ permalink raw reply
* [PATCH V5 1/3] ARM: imx: add suspend in ocram support for i.mx6q
From: Shawn Guo @ 2014-01-15 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389681315-10231-1-git-send-email-b20788@freescale.com>
On Tue, Jan 14, 2014 at 02:35:13PM +0800, Anson Huang wrote:
> When system enter suspend, we can set the DDR IO to
> high-Z state to save DDR IOs' power consumption, this
> operation can save many power(from ~26mA at 1.5V to ~15mA at 1.5V,
> measured on i.MX6Q SabreSD board, R25) of DDR IOs. To
> achieve that, we need to copy the suspend code to ocram
> and run the low level hardware related code(set DDR IOs
> to high-Z state) in ocram.
>
> If there is no ocram space available, then system will
> still do suspend in external DDR, hence no DDR IOs will
> be set to high-Z.
>
> The OCRAM usage layout is as below,
>
> ocram suspend region(4K currently):
> ======================== high address ======================
> .
> .
> .
> ^
> ^
> ^
> imx6_suspend code
> reserved space(to make imx6_suspend aligned with 8)
We can remove this line now, right? Same for the comment in code.
> PM_INFO structure(imx6_cpu_pm_info)
> ======================== low address =======================
>
> Signed-off-by: Anson Huang <b20788@freescale.com>
<snip>
> +ENTRY(imx6_suspend)
> + ldr r1, [r0, #PM_INFO_PBASE_OFFSET]
> + ldr r2, [r0, #PM_INFO_RESUME_ADDR_OFFSET]
> + ldr r3, [r0, #PM_INFO_CPU_TYPE_OFFSET]
> + ldr r4, [r0, #PM_INFO_PM_INFO_SIZE_OFFSET]
> +
> + /*
> + * counting the resume address in iram
> + * to set it in SRC register.
> + */
> + ldr r6, =imx6_suspend
> + ldr r7, =resume
> + sub r7, r7, r6
> + add r8, r1, r4
> + add r9, r8, r7
> +
> + /*
> + * make sure TLB contain the addr we want,
> + * as we will access them after MMDC IO floated.
> + */
> +
> + ldr r11, [r0, #PM_INFO_MX6Q_CCM_V_OFFSET]
> + ldr r6, [r11, #0x0]
> + ldr r11, [r0, #PM_INFO_MX6Q_GPC_V_OFFSET]
> + ldr r6, [r11, #0x0]
> +
> + /* use r11 to store the IO address */
> + ldr r11, [r0, #PM_INFO_MX6Q_SRC_V_OFFSET]
> + /* store physical resume addr and pm_info address. */
> + str r9, [r11, #MX6Q_SRC_GPR1]
> + str r1, [r11, #MX6Q_SRC_GPR2]
> +
> + /* need to sync L2 cache before DSM. */
> + sync_l2_cache
> +
> + ldr r11, [r0, #PM_INFO_MX6Q_MMDC_V_OFFSET]
> + /*
> + * put DDR explicitly into self-refresh and
> + * disable automatic power savings.
> + */
> + ldr r7, [r11, #MX6Q_MMDC_MAPSR]
> + orr r7, r7, #0x1
> + str r7, [r11, #MX6Q_MMDC_MAPSR]
> +
> + /* make the DDR explicitly enter self-refresh. */
> + ldr r7, [r11, #MX6Q_MMDC_MAPSR]
> + orr r7, r7, #(1 << 21)
> + str r7, [r11, #MX6Q_MMDC_MAPSR]
> +
> +poll_dvfs_set_1:
> + ldr r7, [r11, #MX6Q_MMDC_MAPSR]
> + ands r7, r7, #(1 << 25)
> + beq poll_dvfs_set_1
> +
> + ldr r11, [r0, #PM_INFO_MX6Q_IOMUXC_V_OFFSET]
> + ldr r6, =0x0
> + ldr r7, [r0, #PM_INFO_MMDC_IO_NUM_OFFSET]
> + ldr r8, =PM_INFO_MMDC_IO_VAL_OFFSET
If we add the following instruction here
add r8, r0, r8
> +set_mmdc_io_lpm:
> + ldr r9, [r0, r8]
, it can be replaced by the following one
ldr r9, [r8], #0x8
> + str r6, [r11, r9]
> + add r8, r8, #0x8
, and then we can save this one in the loop, right?
> + sub r7, r7, #0x1
> + cmp r7, #0x0
The sequence of 'sub ...; cmp ..., #0' and 'and ...; cmp ..., #0' can
generally be replaced by 'subs ...' and 'ands' respectively to save one
instruction, right?
The above two comments apply to a few other places in the code.
> + bne set_mmdc_io_lpm
> +
> + /*
> + * mask all GPC interrupts before
> + * enabling the RBC counters to
> + * avoid the counter starting too
> + * early if an interupt is already
> + * pending.
> + */
> + ldr r11, [r0, #PM_INFO_MX6Q_GPC_V_OFFSET]
> + ldr r6, [r11, #MX6Q_GPC_IMR1]
> + ldr r7, [r11, #MX6Q_GPC_IMR2]
> + ldr r8, [r11, #MX6Q_GPC_IMR3]
> + ldr r9, [r11, #MX6Q_GPC_IMR4]
> +
> + ldr r10, =0xffffffff
> + str r10, [r11, #MX6Q_GPC_IMR1]
> + str r10, [r11, #MX6Q_GPC_IMR2]
> + str r10, [r11, #MX6Q_GPC_IMR3]
> + str r10, [r11, #MX6Q_GPC_IMR4]
> +
> + /*
> + * enable the RBC bypass counter here
> + * to hold off the interrupts. RBC counter
> + * = 32 (1ms), Minimum RBC delay should be
> + * 400us for the analog LDOs to power down.
> + */
> + ldr r11, [r0, #PM_INFO_MX6Q_CCM_V_OFFSET]
> + ldr r10, [r11, #MX6Q_CCM_CCR]
> + bic r10, r10, #(0x3f << 21)
> + orr r10, r10, #(0x20 << 21)
> + str r10, [r11, #MX6Q_CCM_CCR]
> +
> + /* enable the counter. */
> + ldr r10, [r11, #MX6Q_CCM_CCR]
> + orr r10, r10, #(0x1 << 27)
> + str r10, [r11, #MX6Q_CCM_CCR]
> +
> + /* unmask all the GPC interrupts. */
> + ldr r11, [r0, #PM_INFO_MX6Q_GPC_V_OFFSET]
> + str r6, [r11, #MX6Q_GPC_IMR1]
> + str r7, [r11, #MX6Q_GPC_IMR2]
> + str r8, [r11, #MX6Q_GPC_IMR3]
> + str r9, [r11, #MX6Q_GPC_IMR4]
> +
> + /*
> + * now delay for a short while (3usec)
> + * ARM is at 1GHz at this point
> + * so a short loop should be enough.
> + * this delay is required to ensure that
> + * the RBC counter can start counting in
> + * case an interrupt is already pending
> + * or in case an interrupt arrives just
> + * as ARM is about to assert DSM_request.
> + */
> + ldr r6, =2000
> +rbc_loop:
> + sub r6, r6, #0x1
> + cmp r6, #0x0
> + bne rbc_loop
> +
> + /* Zzz, enter stop mode */
> + wfi
> + nop
> + nop
> + nop
> + nop
> +
> + /*
> + * run to here means there is pending
> + * wakeup source, system should auto
> + * resume, we need to restore MMDC IO first
> + */
The MMDC restoring code looks identical between the case of wakeup
source pending and the normal resume case, except that the former runs
at virtual address and the later runs at the physical. Can we make
a macro for it to save some code duplication?
Shawn
> + ldr r11, [r0, #PM_INFO_MX6Q_IOMUXC_V_OFFSET]
> + ldr r6, [r0, #PM_INFO_MMDC_IO_NUM_OFFSET]
> + ldr r7, =PM_INFO_MMDC_IO_VAL_OFFSET
> +restore_mmdc_io:
> + ldr r8, [r0, r7]
> + add r7, r7, #0x4
> + ldr r9, [r0, r7]
> + add r7, r7, #0x4
> + str r9, [r11, r8]
> + sub r6, r6, #0x1
> + cmp r6, #0x0
> + bne restore_mmdc_io
> +
> + ldr r11, [r0, #PM_INFO_MX6Q_MMDC_V_OFFSET]
> + /* let DDR out of self-refresh. */
> + ldr r7, [r11, #MX6Q_MMDC_MAPSR]
> + bic r7, r7, #(1 << 21)
> + str r7, [r11, #MX6Q_MMDC_MAPSR]
> +
> +poll_dvfs_clear_2:
> + ldr r7, [r11, #MX6Q_MMDC_MAPSR]
> + ands r7, r7, #(1 << 25)
> + bne poll_dvfs_clear_2
> + /* enable DDR auto power saving */
> + ldr r7, [r11, #MX6Q_MMDC_MAPSR]
> + bic r7, r7, #0x1
> + str r7, [r11, #MX6Q_MMDC_MAPSR]
> + /* return to suspend finish */
> + mov pc, lr
> +
> +resume:
> + /* invalidate L1 I-cache first */
> + mov r6, #0x0
> + mcr p15, 0, r6, c7, c5, 0
> + mcr p15, 0, r6, c7, c5, 0
> + mcr p15, 0, r6, c7, c5, 6
> + /* enable the Icache and branch prediction */
> + mov r6, #0x1800
> + mcr p15, 0, r6, c1, c0, 0
> + isb
> +
> + /* get physical resume address from pm_info. */
> + ldr lr, [r0, #PM_INFO_RESUME_ADDR_OFFSET]
> + /* clear core0's entry and parameter */
> + ldr r11, [r0, #PM_INFO_MX6Q_SRC_P_OFFSET]
> + mov r7, #0
> + str r7, [r11, #MX6Q_SRC_GPR1]
> + str r7, [r11, #MX6Q_SRC_GPR2]
> +
> + ldr r11, [r0, #PM_INFO_MX6Q_IOMUXC_P_OFFSET]
> + ldr r6, [r0, #PM_INFO_MMDC_IO_NUM_OFFSET]
> + ldr r7, =PM_INFO_MMDC_IO_VAL_OFFSET
> +dsm_restore_mmdc_io:
> + ldr r8, [r0, r7]
> + add r7, r7, #0x4
> + ldr r9, [r0, r7]
> + add r7, r7, #0x4
> + str r9, [r11, r8]
> + sub r6, r6, #0x1
> + cmp r6, #0x0
> + bne dsm_restore_mmdc_io
> +
> + ldr r11, [r0, #PM_INFO_MX6Q_MMDC_P_OFFSET]
> + /* let DDR out of self-refresh */
> + ldr r7, [r11, #MX6Q_MMDC_MAPSR]
> + bic r7, r7, #(1 << 21)
> + str r7, [r11, #MX6Q_MMDC_MAPSR]
> +
> +poll_dvfs_clear_1:
> + ldr r7, [r11, #MX6Q_MMDC_MAPSR]
> + ands r7, r7, #(1 << 25)
> + bne poll_dvfs_clear_1
> + /* enable DDR auto power saving */
> + ldr r7, [r11, #MX6Q_MMDC_MAPSR]
> + bic r7, r7, #0x1
> + str r7, [r11, #MX6Q_MMDC_MAPSR]
> + mov pc, lr
> +ENDPROC(imx6_suspend)
> --
> 1.7.9.5
>
>
^ permalink raw reply
* [PATCH] mm: nobootmem: avoid type warning about alignment value
From: Nicolas Pitre @ 2014-01-15 3:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140112105958.GA9791@n2100.arm.linux.org.uk>
On Sun, 12 Jan 2014, Russell King - ARM Linux wrote:
> This patch makes their types match exactly with x86's definitions of
> the same, which is the basic problem: on ARM, they all took "int" values
> and returned "int"s, which leads to min() in nobootmem.c complaining.
>
> arch/arm/include/asm/bitops.h | 54 +++++++++++++++++++++++++++++++++++--------
> 1 file changed, 44 insertions(+), 10 deletions(-)
For the record:
Acked-by: Nicolas Pitre <nico@linaro.org>
The reason why macros were used at the time this was originally written
is because gcc used to have issues forwarding the constant nature of a
variable down multiple levels of inline functions and
__builtin_constant_p() always returned false. But that was quite a long
time ago.
> diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
> index e691ec91e4d3..b2e298a90d76 100644
> --- a/arch/arm/include/asm/bitops.h
> +++ b/arch/arm/include/asm/bitops.h
> @@ -254,25 +254,59 @@ static inline int constant_fls(int x)
> }
>
> /*
> - * On ARMv5 and above those functions can be implemented around
> - * the clz instruction for much better code efficiency.
> + * On ARMv5 and above those functions can be implemented around the
> + * clz instruction for much better code efficiency. __clz returns
> + * the number of leading zeros, zero input will return 32, and
> + * 0x80000000 will return 0.
> */
> +static inline unsigned int __clz(unsigned int x)
> +{
> + unsigned int ret;
> +
> + asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
>
> + return ret;
> +}
> +
> +/*
> + * fls() returns zero if the input is zero, otherwise returns the bit
> + * position of the last set bit, where the LSB is 1 and MSB is 32.
> + */
> static inline int fls(int x)
> {
> - int ret;
> -
> if (__builtin_constant_p(x))
> return constant_fls(x);
>
> - asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
> - ret = 32 - ret;
> - return ret;
> + return 32 - __clz(x);
> +}
> +
> +/*
> + * __fls() returns the bit position of the last bit set, where the
> + * LSB is 0 and MSB is 31. Zero input is undefined.
> + */
> +static inline unsigned long __fls(unsigned long x)
> +{
> + return fls(x) - 1;
> +}
> +
> +/*
> + * ffs() returns zero if the input was zero, otherwise returns the bit
> + * position of the first set bit, where the LSB is 1 and MSB is 32.
> + */
> +static inline int ffs(int x)
> +{
> + return fls(x & -x);
> +}
> +
> +/*
> + * __ffs() returns the bit position of the first bit set, where the
> + * LSB is 0 and MSB is 31. Zero input is undefined.
> + */
> +static inline unsigned long __ffs(unsigned long x)
> +{
> + return ffs(x) - 1;
> }
>
> -#define __fls(x) (fls(x) - 1)
> -#define ffs(x) ({ unsigned long __t = (x); fls(__t & -__t); })
> -#define __ffs(x) (ffs(x) - 1)
> #define ffz(x) __ffs( ~(x) )
>
> #endif
>
>
> --
> 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".
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Mike Turquette @ 2014-01-15 3:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115031632.4167.2698@quantum>
Quoting Mike Turquette (2014-01-14 19:16:32)
> Quoting Felipe Balbi (2014-01-14 18:04:21)
> > Hi,
> >
> > On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote:
> > > > Felipe, care to run your randconfig magic for this?
> > >
> > > This branch builds just fine so far, I still have omap5 multiplaform and
> > > uniplatform builds, but since that was working before i'm assuming it
> > > won't break.
> >
> > No build failures in any of my 18 seeds (5 randconfigs of each), I'd
> > attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can
> > send it.
> >
> > FWIW:
> >
> > Acked-by: Felipe Balbi <balbi@ti.com>
>
> Felipe,
>
> That's great to hear. Thanks for testing.
>
> Tero & Tony,
>
> These 40 patches apply very cleanly on top of clk-next with 2
> exceptions:
>
> 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data"
> because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based
> on 3.13-rc1).
>
> 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I
> resolved correctly but would like verification.
>
> I'd prefer to simply merge these patches into clk-next, which is the
> most straightforward route. Any ideas on how to handle the missing
> AM35xx dtsi data? It can always go as a separate fix after this stuff
> gets merged which, ironically, is how that file was created in the first
> place.
I've pushed my branch. Tero can you take a look and let me know if you
see any problems?
git://git.linaro.org/people/mike.turquette/linux.git clk-next-omap
Thanks!
Mike
>
> Regards,
> Mike
>
> >
> > cheers
> >
> > --
> > balbi
^ permalink raw reply
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