* [PATCH 3/9] ARM: DTS: omap4: Set all audio related IP's status to disabled as default
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
Board dts files will need to enable the IP nodes which they are using and
does not have to care about the not used ones (to disable them).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a1e05853afcd..78c19e30eca0 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -426,6 +426,7 @@
dmas = <&sdma 65>,
<&sdma 66>;
dma-names = "up_link", "dn_link";
+ status = "disabled";
};
dmic: dmic at 4012e000 {
@@ -437,6 +438,7 @@
ti,hwmods = "dmic";
dmas = <&sdma 67>;
dma-names = "up_link";
+ status = "disabled";
};
mcbsp1: mcbsp at 40122000 {
@@ -451,6 +453,7 @@
dmas = <&sdma 33>,
<&sdma 34>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp2: mcbsp at 40124000 {
@@ -465,6 +468,7 @@
dmas = <&sdma 17>,
<&sdma 18>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp3: mcbsp at 40126000 {
@@ -479,6 +483,7 @@
dmas = <&sdma 19>,
<&sdma 20>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp4: mcbsp at 48096000 {
@@ -492,6 +497,7 @@
dmas = <&sdma 31>,
<&sdma 32>;
dma-names = "tx", "rx";
+ status = "disabled";
};
keypad: keypad at 4a31c000 {
--
1.8.5.3
^ permalink raw reply related
* [PATCH 4/9] ARM: DTS: omap4-panda-common: No need to disable the unused audio nodes
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
All audio nodes has been set to disabled state in omap4.dtsi file.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 9067d4c0148d..f83dd4c365c7 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -387,18 +387,6 @@
status = "okay";
};
-&mcbsp2 {
- status = "disabled";
-};
-
-&mcbsp3 {
- status = "disabled";
-};
-
-&dmic {
- status = "disabled";
-};
-
&mcpdm {
pinctrl-names = "default";
pinctrl-0 = <&mcpdm_pins>;
--
1.8.5.3
^ permalink raw reply related
* [PATCH 5/9] ARM: DTS: omap4-sdp: No need to disable mcbsp3 node
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
All audio nodes has been set to disabled state in omap4.dtsi file.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 513b01774966..9bbbbec1d63d 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -548,10 +548,6 @@
status = "okay";
};
-&mcbsp3 {
- status = "disabled";
-};
-
&dmic {
pinctrl-names = "default";
pinctrl-0 = <&dmic_pins>;
--
1.8.5.3
^ permalink raw reply related
* [PATCH 6/9] ARM: DTS: omap5: Set all audio related IP's status to disabled as default
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
Board dts files will need to enable the IP nodes which they are using and
does not have to care about the not used ones (to disable them).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index fc3fad563861..84cee44f1fad 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -467,6 +467,7 @@
dmas = <&sdma 65>,
<&sdma 66>;
dma-names = "up_link", "dn_link";
+ status = "disabled";
};
dmic: dmic at 4012e000 {
@@ -478,6 +479,7 @@
ti,hwmods = "dmic";
dmas = <&sdma 67>;
dma-names = "up_link";
+ status = "disabled";
};
mcbsp1: mcbsp at 40122000 {
@@ -492,6 +494,7 @@
dmas = <&sdma 33>,
<&sdma 34>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp2: mcbsp at 40124000 {
@@ -506,6 +509,7 @@
dmas = <&sdma 17>,
<&sdma 18>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp3: mcbsp at 40126000 {
@@ -520,6 +524,7 @@
dmas = <&sdma 19>,
<&sdma 20>;
dma-names = "tx", "rx";
+ status = "disabled";
};
timer1: timer at 4ae18000 {
--
1.8.5.3
^ permalink raw reply related
* [PATCH 7/9] ARM: DTS: omap3: Set disabled status for McBSP instances as default state
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
In omap3.dtsi disable all mcbsp nodes and board dts files can explicitly
enable the mcbsp they are using.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 4 ++++
arch/arm/boot/dts/omap3-beagle.dts | 4 ++++
arch/arm/boot/dts/omap3-devkit8000.dts | 16 ++--------------
arch/arm/boot/dts/omap3-igep.dtsi | 1 +
arch/arm/boot/dts/omap3-overo.dtsi | 4 ++++
arch/arm/boot/dts/omap3.dtsi | 5 +++++
6 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index df33a50bc070..d9ae3f4d0aa4 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -222,3 +222,7 @@
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
+
+&mcbsp2 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index 3ba4a625ea5b..c13449773def 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -199,3 +199,7 @@
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
+
+&mcbsp2 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts b/arch/arm/boot/dts/omap3-devkit8000.dts
index 4665421bb7bc..bf5a515a3247 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -101,20 +101,8 @@
status = "disabled";
};
-&mcbsp1 {
- status = "disabled";
-};
-
-&mcbsp3 {
- status = "disabled";
-};
-
-&mcbsp4 {
- status = "disabled";
-};
-
-&mcbsp5 {
- status = "disabled";
+&mcbsp2 {
+ status = "okay";
};
&gpmc {
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
index 165aaf7591ba..ced7aa0e503c 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -172,6 +172,7 @@
&mcbsp2 {
pinctrl-names = "default";
pinctrl-0 = <&mcbsp2_pins>;
+ status = "okay";
};
&mmc1 {
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index a461d2fd1fb0..b08142f755fd 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -95,3 +95,7 @@
pinctrl-names = "default";
pinctrl-0 = <&uart3_pins>;
};
+
+&mcbsp2 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index daabf99d402a..50767f339e2d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,6 +397,7 @@
dmas = <&sdma 31>,
<&sdma 32>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp2: mcbsp at 49022000 {
@@ -414,6 +415,7 @@
dmas = <&sdma 33>,
<&sdma 34>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp3: mcbsp at 49024000 {
@@ -431,6 +433,7 @@
dmas = <&sdma 17>,
<&sdma 18>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp4: mcbsp at 49026000 {
@@ -446,6 +449,7 @@
dmas = <&sdma 19>,
<&sdma 20>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp5: mcbsp at 48096000 {
@@ -461,6 +465,7 @@
dmas = <&sdma 21>,
<&sdma 22>;
dma-names = "tx", "rx";
+ status = "disabled";
};
sham: sham at 480c3000 {
--
1.8.5.3
^ permalink raw reply related
* [PATCH 8/9] ARM: DTS: omap2: Set disabled status for McBSP instances as default state
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
In omap2420.dtsi and omap2430.dtsi disable all mcbsp nodes and board dts
files can explicitly enable the mcbsp they are using.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap2420.dtsi | 2 ++
arch/arm/boot/dts/omap2430.dtsi | 5 +++++
2 files changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index 60c605de22dd..85b1fb014c43 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -99,6 +99,7 @@
dmas = <&sdma 31>,
<&sdma 32>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp2: mcbsp at 48076000 {
@@ -112,6 +113,7 @@
dmas = <&sdma 33>,
<&sdma 34>;
dma-names = "tx", "rx";
+ status = "disabled";
};
msdi1: mmc at 4809c000 {
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index d624345666f5..9d2f028fd687 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -113,6 +113,7 @@
dmas = <&sdma 31>,
<&sdma 32>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp2: mcbsp at 48076000 {
@@ -128,6 +129,7 @@
dmas = <&sdma 33>,
<&sdma 34>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp3: mcbsp at 4808c000 {
@@ -143,6 +145,7 @@
dmas = <&sdma 17>,
<&sdma 18>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp4: mcbsp at 4808e000 {
@@ -158,6 +161,7 @@
dmas = <&sdma 19>,
<&sdma 20>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp5: mcbsp at 48096000 {
@@ -173,6 +177,7 @@
dmas = <&sdma 21>,
<&sdma 22>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mmc1: mmc at 4809c000 {
--
1.8.5.3
^ permalink raw reply related
* [PATCH 9/9] ARM: DTS: am335x-evmsk: Correct audio clock frequency
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
The clock for audio is sourced from virt_24000000_ck, so the correct
frequency is 24000000.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: <stable@vger.kernel.org> # 3.13.x
---
arch/arm/boot/dts/am335x-evmsk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 4718ec4a4dbf..50abe53f6887 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -121,7 +121,7 @@
ti,model = "AM335x-EVMSK";
ti,audio-codec = <&tlv320aic3106>;
ti,mcasp-controller = <&mcasp1>;
- ti,codec-clock-rate = <24576000>;
+ ti,codec-clock-rate = <24000000>;
ti,audio-routing =
"Headphone Jack", "HPLOUT",
"Headphone Jack", "HPROUT";
--
1.8.5.3
^ permalink raw reply related
* [PATCH] arm64: fix build error if DMA_CMA is enabled
From: Pankaj Dubey @ 2014-01-24 8:23 UTC (permalink / raw)
To: linux-arm-kernel
arm64/include/asm/dma-contiguous.h is trying to include
<asm-genric/dma-contiguous.h> which does not exist, and thus failing
build for arm64 if we enable CONFIG_DMA_CMA. This patch fixes build
error by removing unwanted header inclusion from arm64's dma-contiguous.h.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: Somraj Mani <somraj.mani@samsung.com>
---
arch/arm64/include/asm/dma-contiguous.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/include/asm/dma-contiguous.h b/arch/arm64/include/asm/dma-contiguous.h
index d6aacb6..14c4c0c 100644
--- a/arch/arm64/include/asm/dma-contiguous.h
+++ b/arch/arm64/include/asm/dma-contiguous.h
@@ -18,7 +18,6 @@
#ifdef CONFIG_DMA_CMA
#include <linux/types.h>
-#include <asm-generic/dma-contiguous.h>
static inline void
dma_contiguous_early_fixup(phys_addr_t base, unsigned long size) { }
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 2/4] pinctrl: st: Add software edge trigger interrupt support.
From: Lee Jones @ 2014-01-24 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaBAnpfHBqkgU2emZrYwHGh9KvDvqfnCvaWdU5jYgxStA@mail.gmail.com>
> > +/*
> > + * As edge triggers are not supported at hardware level, it is supported by
> > + * software by exploiting the level trigger support in hardware.
>
> (...)
>
> All this is quite hard to understand. Maybe it's just because
> it's hard overall. Edge triggers are not supported by hardware
> so we use the hardware edge trigger support?
>
> That is a bit oxymoronic...
That's not what is says. Read it again. :)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Vincent Guittot @ 2014-01-24 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122192041.GA3709@e102568-lin.cambridge.arm.com>
On 22 January 2014 20:20, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> Hi Vincent,
>
> On Tue, Jan 21, 2014 at 11:16:46AM +0000, Vincent Guittot wrote:
>> Hi Lorenzo,
>>
>> On 20 January 2014 18:47, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> > ARM based platforms implement a variety of power management schemes that
>> > allow processors to enter at run-time low-power states, aka C-states
>> > in ACPI jargon. The parameters defining these C-states vary on a per-platform
>> > basis forcing the OS to hardcode the state parameters in platform
>> > specific static tables whose size grows as the number of platforms supported
>> > in the kernel increases and hampers device drivers standardization.
>> >
>> > Therefore, this patch aims at standardizing C-state device tree bindings for
>> > ARM platforms. Bindings define C-state parameters inclusive of entry methods
>> > and state latencies, to allow operating systems to retrieve the
>> > configuration entries from the device tree and initialize the related
>> > power management drivers, paving the way for common code in the kernel
>> > to deal with power states and removing the need for static data in current
>> > and previous kernel versions.
>> >
>> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> > ---
>> > Documentation/devicetree/bindings/arm/c-states.txt | 774 +++++++++++++++++++++
>> > Documentation/devicetree/bindings/arm/cpus.txt | 10 +
>> > 2 files changed, 784 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/arm/c-states.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/arm/c-states.txt b/Documentation/devicetree/bindings/arm/c-states.txt
>> > new file mode 100644
>> > index 0000000..0b5617b
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/arm/c-states.txt
>> > @@ -0,0 +1,774 @@
>> > +==========================================
>> > +ARM C-states binding description
>> > +==========================================
>> > +
>> > +==========================================
>> > +1 - Introduction
>> > +==========================================
>> > +
>> > +ARM systems contain HW capable of managing power consumption dynamically,
>> > +where cores can be put in different low-power states (ranging from simple
>> > +wfi to power gating) according to OSPM policies. Borrowing concepts
>> > +from the ACPI specification[1], the CPU states representing the range of
>> > +dynamic states that a processor can enter at run-time, aka C-state, can be
>> > +specified through device tree bindings representing the parameters required to
>> > +enter/exit specific C-states on a given processor.
>> > +
>> > +The state an ARM CPU can be put into is loosely identified by one of the
>> > +following operating modes:
>> > +
>> > +- Running:
>> > + # Processor core is executing instructions
>> > +
>> > +- Wait for Interrupt:
>> > + # An ARM processor enters wait for interrupt (WFI) low power
>> > + state by executing a wfi instruction. When a processor enters
>> > + wfi state it disables most of the clocks while keeping the processor
>> > + powered up. This state is standard on all ARM processors and it is
>> > + defined as C1 in the remainder of this document.
>> > +
>>
>> > +- Dormant:
>> > + # Dormant mode is entered by executing wfi instructions and by sending
>> > + platform specific commands to the platform power controller (coupled
>> > + with processor specific SW/HW control sequences).
>> > + In dormant mode, most of the processor control and debug logic is
>> > + powered up but cache RAM can be put in retention state, providing
>>
>> Base on your description, it's not clear for me what is on, what is
>> lost and what is power down ?
>> My understand of the dormant mode that you described above is : the
>> cache is preserved (and especially the cache RAM) but the processor
>> state is lost (registers ...). Do I understand correctly ?
>>
>> What about retention mode where the contents of processor and cache
>> are preserved but the power consumption is reduced ? it can be seen as
>> a special wfi mode which need specific SW/HW control sequences but i'm
>> not sure to understand how to describe such state with your proposal.
>
Hi Lorenzo,
Sorry for the late reply,
> I had an idea. To simplify things, I think that one possibility is to
> add a parameter to the power domain specifier (platform specific, see
> Tomasz bindings):
We can't use a simple boolean state (on/off) for defining the
powerdomain state associated to a c-state so your proposal of being
able to add a parameter that will define the power domain state is
interesting.
>
> Documentation/devicetree/bindings/power/power_domain.txt
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224928.html
>
> to represent, when that state is entered the behavior of the power
> controller (ie cache RAM retention or cache shutdown or in general any
> substate within a power domain). Since it is platform specific, and since
> we are able to link caches to the power domain, the power controller will
> actually define what happens to the cache when that state is entered
> (basically we use the power domain specifier additional parameter to define
> a "substate" in that power domain e.g.:
>
> Example:
>
> foo_power_controller {
> [...]
> /*
> * first cell is register index, second one is the state index
> * that in turn implies the state behavior - eg cache lost or
> * retained
> */
> #power-domain-cells = <2>;
> };
>
> l1-cache {
> [...]
> /*
> * syntax: power-domains = list of power domain specifiers
> <[&power_domain_phandle register-index state],[&power_domain_phandle register-index state]>;
> The syntax is defined by the power controller du jour
> as described by Tomasz bindings
> */
> power-domains =<&foo_power_controller 0 0 &foo_power_controller 0 1>;
Normally, power-domains describes a list of power domain specifiers
that are necessary for the l1-cache to at least retain its state so
i'm not sure understand your example above
If we take the example of system that support running, retention and
powerdown state described as state 0, 1 and 2 for the power domain, i
would have set the l1-cache like:
power-domains =<&foo_power_controller 0 1>;
for saying that the state is retained up to state 1
Please look below, i have modified the rest of your example accordingly
>
> }:
>
> and then
>
> state0 {
> index = <2>;
> compatible = "arm,cpu-power-state";
> latency = <...>;
> /*
> * This means that when the state is entered, the power
> * controller should use register index 0 and state 0,
> * whose meaning is power controller specific. Since we
> * know all components affected (for every component
> * we declare its power domain(s) and states so we
> * know what components are affected by the state entry.
> * Given the cache node above and this phandle, the state
> * implies that the cache is retained, register index == 0 state == 0
> /*
> power-domain =<&foo_power_controller 0 0>;
for retention state we need to set the power domain in state 1
power-domain =<&foo_power_controller 0 1>;
> };
>
> state1 {
> index = <3>;
> compatible = "arm,cpu-power-state";
> latency = <...>;
> /*
> * This means that when the state is entered, the power
> * controller should use register index 0 and state 1,
> * whose meaning is power controller specific. Since we
> * know all components affected (for every component
> * we declare its power domain(s) and states so we
> * know what components are affected by the state entry.
> * Given the cache node above and this phandle, the state
> * implies that the cache is lost, register index == 0 state == 1
> /*
> power-domain =<&foo_power_controller 0 1>;
for power down mode, we need to set thge power domain in state 2
power-domain =<&foo_power_controller 0 2>;
Vincent
> };
>
> It is complex but it is probably the cleanest way. And it leaves complexity
> to power controller implementations (if managed in the kernel....), which
> actually makes sense because it is up to power controller to define the
> behavior of certain states.
>
> All in all it is just an idea, feel free to scotch it, it is complex but
> we have to sort it out, one way or another.
>
> Vincent, Tomasz, anyone, thoughts ?
> Lorenzo
>
^ permalink raw reply
* [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Hiremath, Vaibhav @ 2014-01-24 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0333F.4000400@gmail.com>
> -----Original Message-----
> From: Ivaylo Dimitrov [mailto:ivo.g.dimitrov.75 at gmail.com]
> Sent: Thursday, January 23, 2014 2:38 AM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov; Valkeinen, Tomi
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> fbdev at vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
>
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues
>
Link seems to be coming blank to me :)
Thanks,
Vaibhav
^ permalink raw reply
* [PATCH 2/2] clk: exynos4: Fix spacing related checkpatch errors
From: Sachin Kamat @ 2014-01-24 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD1182.80200@samsung.com>
Hi Tomasz,
On 20 January 2014 17:37, Tomasz Figa <t.figa@samsung.com> wrote:
> Hi Sachin,
>
>
> On 15.01.2014 11:01, Sachin Kamat wrote:
>>
>> Silences the following type of checkpatch errors:
>> ERROR: space prohibited after that open parenthesis '('
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>> ---
>> drivers/clk/samsung/clk-exynos4.c | 50
>> ++++++++++++++++++-------------------
>> 1 file changed, 25 insertions(+), 25 deletions(-)
>
>
> I believe this is a false warning. In this special case the spaces greatly
> improve readability of static data in the driver, which I believe is
> preferred over the strict rules of checkpatch.
I agree that the existing pattern looks good to eyes :)
But then you will keep getting many such fix patches. The intention was to
bring this to your notice.
What say about the other patch in this series?
--
With warm regards,
Sachin
^ permalink raw reply
* [Linaro-acpi] [PATCH 04/20] ARM64 / ACPI: Introduce arm_core.c and its related head file
From: Hanjun Guo @ 2014-01-24 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E13BBC.5020005@linaro.org>
On 2014?01?23? 23:56, Tomasz Nowicki wrote:
> Hi Lorenzo,
>
> W dniu 22.01.2014 12:54, Lorenzo Pieralisi pisze:
>> On Fri, Jan 17, 2014 at 12:24:58PM +0000, Hanjun Guo wrote:
>>
>> [...]
>>
>>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>>> index bd9bbd0..2210353 100644
>>> --- a/arch/arm64/kernel/setup.c
>>> +++ b/arch/arm64/kernel/setup.c
>>> @@ -41,6 +41,7 @@
>>> #include <linux/memblock.h>
>>> #include <linux/of_fdt.h>
>>> #include <linux/of_platform.h>
>>> +#include <linux/acpi.h>
>>>
>>> #include <asm/cputype.h>
>>> #include <asm/elf.h>
>>> @@ -225,6 +226,11 @@ void __init setup_arch(char **cmdline_p)
>>>
>>> arm64_memblock_init();
>>>
>>> + /* Parse the ACPI tables for possible boot-time configuration */
>>> + acpi_boot_table_init();
>>> + early_acpi_boot_init();
>>> + acpi_boot_init();
>>> +
>>> paging_init();
>>
>> Can I ask you please why we need to parse ACPI tables before
>> paging_init() ?
> This is for future usage and because of couple of reasons. Mainly SRAT
> table parsing should be done (before paging_init()) for proper NUMA
> initialization and then paging_init().
Yes, I agree, thanks for Tomasz's clarification.
>>
>> [...]
>>
>>> +/*
>>> + * __acpi_map_table() will be called before page_init(), so
>>> early_ioremap()
>>> + * or early_memremap() should be called here.
>>
>> Again, why is this needed ? What's needed before paging_init() from
>> ACPI ?
>>
>> [...]
>>
>>> +/*
>>> + * acpi_boot_table_init() and acpi_boot_init()
>>> + * called from setup_arch(), always.
>>> + * 1. checksums all tables
>>> + * 2. enumerates lapics
>>> + * 3. enumerates io-apics
>>> + *
>>> + * acpi_table_init() is separated to allow reading SRAT without
>>> + * other side effects.
>>> + */
>>> +void __init acpi_boot_table_init(void)
>>> +{
>>> + /*
>>> + * If acpi_disabled, bail out
>>> + */
>>> + if (acpi_disabled)
>>> + return;
>>> +
>>> + /*
>>> + * Initialize the ACPI boot-time table parser.
>>> + */
>>> + if (acpi_table_init()) {
>>> + disable_acpi();
>>> + return;
>>> + }
>>> +}
>>> +
>>> +int __init early_acpi_boot_init(void)
>>> +{
>>> + /*
>>> + * If acpi_disabled, bail out
>>> + */
>>> + if (acpi_disabled)
>>> + return -ENODEV;
>>> +
>>> + /*
>>> + * Process the Multiple APIC Description Table (MADT), if present
>>> + */
>>> + early_acpi_process_madt();
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +int __init acpi_boot_init(void)
>>> +{
>>> + /*
>>> + * If acpi_disabled, bail out
>>> + */
>>> + if (acpi_disabled)
>>> + return -ENODEV;
>>> +
>>> + acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
>>> +
>>> + /*
>>> + * Process the Multiple APIC Description Table (MADT), if present
>>> + */
>>> + acpi_process_madt();
>>> +
>>> + return 0;
>>> +}
>>
>> Well, apart from having three init calls, one returning void and two
>> returning proper values, do not understand why, and do not understand
>> why we need three calls in the first place...why should we process MADT
>> twice in two separate calls ? What is supposed to change in between that
>> prevents you from merging the two together ?
Thanks for pointing this out. I can merge acpi_boot_table_init() and
early_acpi_boot_init() together, but can not merge early_acpi_boot_init()
and acpi_boot_init() together.
early_acpi_boot_init() and acpi_boot_init() was separated intentionally for
memory hotplug reasons. memory allocated in this stage can not be migrated
and cause memory hot-remove failed, in order to keep memory allocated
at base node (general NUMA node 0 in the system) at boot stage, we should
parse SRAT first before CPU is enumerated, does this make sense to you?
Thanks
Hanjun
^ permalink raw reply
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Hanjun Guo @ 2014-01-24 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3140612.0s75qS6VKb@wuerfel>
On 2014?01?22? 22:56, Arnd Bergmann wrote:
> On Wednesday 22 January 2014 11:46:16 Mark Rutland wrote:
>> On Mon, Jan 20, 2014 at 09:08:32AM +0000, Hanjun Guo wrote:
>>> On 2014-1-17 22:21, Arnd Bergmann wrote:
>>>> On Friday 17 January 2014, Hanjun Guo wrote:
>>>>> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
>>>>>
>>>>> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
>>>>> name from the ACPI timer table is matched with all the registered
>>>>> timer controllers and matching initialisation routine is invoked.
>>>> I wouldn't anticipate this infrastructure to be required. Shouldn't all
>>>> ARMv8 machines have an architected timer?
>>> I not sure of this, could anyone can give some guidance? if only arch
>>> timer is available for ARM64, this will make thing very simple.
>> All ARMv8 systems should have an architected timer.
>>
>> However, they may also have other timers (e.g. global timers for use
>> when CPUs are in low power states and their local architected timers
>> aren't active).
> But all other timers could be regular platform drivers I suppose. No
> need for special infrastructure for those.
One more information, acpi_early_init() is run before timekeeping_init()
now, and that patch was merged into 3.14-rc1. So we can initialize
timers for scanning the DSDT table, and it also means that timer defined
in DSDT can be initialized early enough.
Thanks
Hanjun
^ permalink raw reply
* [PATCH] ARM-i.MX6Q-dts : Added USB_OTG Support
From: Ashutosh singh @ 2014-01-24 9:28 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for USB_OTG on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh <ashutosh.s@phytec.in>
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts | 4 ++++
arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 22 ++++++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 7d37ec6..39e69bd 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -32,3 +32,7 @@
&usdhc3 {
status = "okay";
};
+
+&usbotg {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index 1a3b50d..dcb1d59 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -18,6 +18,19 @@
memory {
reg = <0x10000000 0x80000000>;
};
+
+ regulators {
+ compatible = "simple-bus";
+
+ reg_usb_otg_vbus: usb_otg_vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 15 0>;
+ enable-active-low;
+ };
+ };
};
&ecspi3 {
@@ -134,6 +147,7 @@
MX6QDL_PAD_EIM_D23__GPIO3_IO23 0x80000000
MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x80000000 /* SPI NOR chipselect */
MX6QDL_PAD_DI0_PIN15__GPIO4_IO17 0x80000000 /* PMIC interrupt */
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x80000000 /* USB_OTG_PWR_EN */
>;
};
};
@@ -178,3 +192,11 @@
wp-gpios = <&gpio1 29 0>;
status = "disabled";
};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg_1>;
+ disable-over-current;
+ status = "disabled";
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Andreas Herrmann @ 2014-01-24 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123192429.GB26399@alberich>
On Thu, Jan 23, 2014 at 08:24:29PM +0100, Andreas Herrmann wrote:
> On Wed, Jan 22, 2014 at 03:33:52PM +0000, Will Deacon wrote:
> > On Wed, Jan 22, 2014 at 01:54:11PM +0000, Varun Sethi wrote:
> > > > > > Ok, so are you suggesting that we perform the isolation mapping in
> > > > > > arm_smmu_add_device and drop the notifier altogether?
> > > > > I think that should be fine, until we want to delay mapping creation
> > > > > till driver bind time.
> > > >
> > > > Is there a hard dependency on that?
> > > >
> > > Not sure, may be Andreas can answer that.
> >
> > Ok. Andreas? I would have thought doing this *earlier* shouldn't be a
> > problem (the DMA ops must be swizzled before the driver is probed).
>
> Yes, I think, there is no hard dependency.
>
> (But still have to double check whether arm_smmu_add_device can be
> used instead of the notifier. Will finally see this when doing some
> tests.)
I think we have to keep the notifier and delay mapping creation until
device is bound to a driver.
Otherwise we might create mappings for devices which might not be used
at all. Who guarantees that the running kernel will have driver
support for all devices? If there is no driver for a device why create
a mapping for it -- no DMA will happen.
Andreas
^ permalink raw reply
* [PATCH 4/5] ARM: S3C24XX: convert boards to use common restart function
From: Tomasz Figa @ 2014-01-24 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1873916.c2IkPH5hCW@phil>
On 24.01.2014 09:03, Heiko St?bner wrote:
> On Thursday 23 January 2014 23:35:29 Tomasz Figa wrote:
>> On 23.01.2014 20:02, Heiko St?bner wrote:
>>> Am Donnerstag, 23. Januar 2014, 19:51:34 schrieb Tomasz Figa:
>>>> On 23.01.2014 19:36, Heiko St?bner wrote:
>>> In general, I want to try establishing some sort of general restart way,
>>> as in the future one dt-board should hopefully be enough to cover all
>>> s3c24xx soc variants.
>>
>> If you make SAMSUNG_WDT_RESET always selected on S3C24XX then I guess
>> it's fine.
>>
>>>> Note that you can make the restart field NULL in mach_desc in board
>>>> files.
>>>
>>> As I said above, this is mainly meant for the dt-case. The legacy-board
>>> files are more or less only secondary, and the affected boards can of
>>> course then have a NULL restart handle :-) .
>>>
>>> So for this the dt-board could simply use the wdt-reset, which then gets
>>> replaced by the ccf-based reset if appropriate.
>>
>> OK. By the way, are there any benefits of using this software reset over
>> watchdog reset? Maybe all S3C24xx could simply use watchdog reset and no
>> special handling of those with swrst would be needed.
>
> According to the manuals I looked at, all S3C24XX SoCs seem to support the
> watchdog reset - I'm not sure why the swrst variant was choosen for the newer
> ones when they were added initially. So yes in theory all of them seem to be
> able to use the watchdog reset.
>
> But in any case the s3c2412 will need its own handling, due to the apparent
> clock problem during resets (mentioned in the code and the manuals of
> s3c2412/s3c2413).
OK. So WDT by default (always selected in Kconfig) and override to SWRST
in clock driver if available should work.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH v5 1/8] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
From: Mark Rutland @ 2014-01-24 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390361452-3124-2-git-send-email-marc.ceeeee@gmail.com>
On Wed, Jan 22, 2014 at 03:30:45AM +0000, Marc Carino wrote:
> The BCM7xxx series of Broadcom SoCs are used primarily in set-top boxes.
>
> This patch adds machine support for the ARM-based Broadcom SoCs.
>
> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/configs/multi_v7_defconfig | 1 +
> arch/arm/mach-bcm/Kconfig | 14 ++
> arch/arm/mach-bcm/Makefile | 4 +
> arch/arm/mach-bcm/brcmstb.c | 110 ++++++++++++
> arch/arm/mach-bcm/brcmstb.h | 38 ++++
> arch/arm/mach-bcm/headsmp-brcmstb.S | 34 ++++
> arch/arm/mach-bcm/hotplug-brcmstb.c | 334 +++++++++++++++++++++++++++++++++++
> 7 files changed, 535 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-bcm/brcmstb.c
> create mode 100644 arch/arm/mach-bcm/brcmstb.h
> create mode 100644 arch/arm/mach-bcm/headsmp-brcmstb.S
> create mode 100644 arch/arm/mach-bcm/hotplug-brcmstb.c
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index c1df4e9..7028d11 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -7,6 +7,7 @@ CONFIG_MACH_ARMADA_370=y
> CONFIG_MACH_ARMADA_XP=y
> CONFIG_ARCH_BCM=y
> CONFIG_ARCH_BCM_MOBILE=y
> +CONFIG_ARCH_BRCMSTB=y
> CONFIG_GPIO_PCA953X=y
> CONFIG_ARCH_HIGHBANK=y
> CONFIG_ARCH_KEYSTONE=y
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index 9fe6d88..2c1ae83 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -31,6 +31,20 @@ config ARCH_BCM_MOBILE
> BCM11130, BCM11140, BCM11351, BCM28145 and
> BCM28155 variants.
>
> +config ARCH_BRCMSTB
> + bool "Broadcom BCM7XXX based boards" if ARCH_MULTI_V7
> + depends on MMU
> + select ARM_GIC
> + select MIGHT_HAVE_PCI
> + select HAVE_SMP
> + select HAVE_ARM_ARCH_TIMER
> + help
> + Say Y if you intend to run the kernel on a Broadcom ARM-based STB
> + chipset.
> +
> + This enables support for Broadcom ARM-based set-top box chipsets,
> + including the 7445 family of chips.
> +
> endmenu
>
> endif
> diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> index c2ccd5a..b744a12 100644
> --- a/arch/arm/mach-bcm/Makefile
> +++ b/arch/arm/mach-bcm/Makefile
> @@ -13,3 +13,7 @@
> obj-$(CONFIG_ARCH_BCM_MOBILE) := board_bcm281xx.o bcm_kona_smc.o bcm_kona_smc_asm.o kona.o
> plus_sec := $(call as-instr,.arch_extension sec,+sec)
> AFLAGS_bcm_kona_smc_asm.o :=-Wa,-march=armv7-a$(plus_sec)
> +
> +obj-$(CONFIG_ARCH_BRCMSTB) := brcmstb.o
> +obj-$(CONFIG_SMP) += headsmp-brcmstb.o
> +obj-$(CONFIG_HOTPLUG_CPU) += hotplug-brcmstb.o
> diff --git a/arch/arm/mach-bcm/brcmstb.c b/arch/arm/mach-bcm/brcmstb.c
> new file mode 100644
> index 0000000..7a6093d
> --- /dev/null
> +++ b/arch/arm/mach-bcm/brcmstb.c
> @@ -0,0 +1,110 @@
> +/*
> + * Copyright (C) 2013 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/console.h>
> +#include <linux/clocksource.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/jiffies.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/printk.h>
> +#include <linux/smp.h>
> +
> +#include <asm/cacheflush.h>
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +#include <asm/mach/time.h>
> +
> +#include "brcmstb.h"
> +
> +/***********************************************************************
> + * STB CPU (main application processor)
> + ***********************************************************************/
> +
> +static const char *brcmstb_match[] __initconst = {
> + "brcm,bcm7445",
> + "brcm,brcmstb",
> + NULL
> +};
> +
> +static void __init brcmstb_init_early(void)
> +{
> + add_preferred_console("ttyS", 0, "115200");
> +}
Is this really required?
> +
> +/***********************************************************************
> + * SMP boot
> + ***********************************************************************/
> +
> +#ifdef CONFIG_SMP
> +static DEFINE_SPINLOCK(boot_lock);
> +
> +static void __cpuinit brcmstb_secondary_init(unsigned int cpu)
> +{
> + /*
> + * Synchronise with the boot thread.
> + */
> + spin_lock(&boot_lock);
> + spin_unlock(&boot_lock);
> +}
> +
> +static int __cpuinit brcmstb_boot_secondary(unsigned int cpu,
> + struct task_struct *idle)
> +{
> + /*
> + * set synchronisation state between this boot processor
> + * and the secondary one
> + */
> + spin_lock(&boot_lock);
> +
> + /* Bring up power to the core if necessary */
> + if (brcmstb_cpu_get_power_state(cpu) == 0)
> + brcmstb_cpu_power_on(cpu);
> +
> + brcmstb_cpu_boot(cpu);
> +
> + /*
> + * now the secondary core is starting up let it run its
> + * calibrations, then wait for it to finish
> + */
> + spin_unlock(&boot_lock);
> +
> + return 0;
> +}
> +
> +struct smp_operations brcmstb_smp_ops __initdata = {
> + .smp_prepare_cpus = brcmstb_cpu_ctrl_setup,
> + .smp_secondary_init = brcmstb_secondary_init,
> + .smp_boot_secondary = brcmstb_boot_secondary,
> +#ifdef CONFIG_HOTPLUG_CPU
> + .cpu_kill = brcmstb_cpu_kill,
> + .cpu_die = brcmstb_cpu_die,
> +#endif
> +};
> +#endif
> +
> +DT_MACHINE_START(BRCMSTB, "Broadcom STB (Flattened Device Tree)")
> + .dt_compat = brcmstb_match,
> +#ifdef CONFIG_SMP
> + .smp = smp_ops(brcmstb_smp_ops),
> +#endif
> + .init_early = brcmstb_init_early,
> +MACHINE_END
> diff --git a/arch/arm/mach-bcm/brcmstb.h b/arch/arm/mach-bcm/brcmstb.h
> new file mode 100644
> index 0000000..e49bde6
> --- /dev/null
> +++ b/arch/arm/mach-bcm/brcmstb.h
> @@ -0,0 +1,38 @@
> +/*
> + * Copyright (C) 2013 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __BRCMSTB_H__
> +#define __BRCMSTB_H__
> +
> +#if !defined(__ASSEMBLY__)
> +#include <linux/smp.h>
> +#endif
> +
> +#if !defined(__ASSEMBLY__)
> +extern void brcmstb_secondary_startup(void);
> +extern void brcmstb_cpu_boot(unsigned int cpu);
> +extern void brcmstb_cpu_power_on(unsigned int cpu);
> +extern int brcmstb_cpu_get_power_state(unsigned int cpu);
> +extern struct smp_operations brcmstb_smp_ops;
> +#if defined(CONFIG_HOTPLUG_CPU)
> +extern void brcmstb_cpu_die(unsigned int cpu);
> +extern int brcmstb_cpu_kill(unsigned int cpu);
> +void __init brcmstb_cpu_ctrl_setup(unsigned int max_cpus);
> +#else
> +static inline void brcmstb_cpu_die(unsigned int cpu) {}
> +static inline int brcmstb_cpu_kill(unsigned int cpu) {}
> +static inline void __init brcmstb_cpu_ctrl_setup(unsigned int max_cpus) {}
> +#endif
> +#endif
> +
> +#endif /* __BRCMSTB_H__ */
> diff --git a/arch/arm/mach-bcm/headsmp-brcmstb.S b/arch/arm/mach-bcm/headsmp-brcmstb.S
> new file mode 100644
> index 0000000..57ec438
> --- /dev/null
> +++ b/arch/arm/mach-bcm/headsmp-brcmstb.S
> @@ -0,0 +1,34 @@
> +/*
> + * SMP boot code for secondary CPUs
> + * Based on arch/arm/mach-tegra/headsmp.S
> + *
> + * Copyright (C) 2010 NVIDIA, Inc.
> + * Copyright (C) 2013 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <asm/assembler.h>
> +#include <linux/linkage.h>
> +#include <linux/init.h>
> +
> + .section ".text.head", "ax"
> + __CPUINIT
__CPUINIT is either going or gone by now. This should disappear.
> +
> +ENTRY(brcmstb_secondary_startup)
> + /*
> + * Ensure CPU is in a sane state by disabling all IRQs and switching
> + * into SVC mode.
> + */
> + setmode PSR_I_BIT | PSR_F_BIT | SVC_MODE, r0
> +
> + bl v7_invalidate_l1
> + b secondary_startup
> +ENDPROC(brcmstb_secondary_startup)
> diff --git a/arch/arm/mach-bcm/hotplug-brcmstb.c b/arch/arm/mach-bcm/hotplug-brcmstb.c
> new file mode 100644
> index 0000000..ff4a732
> --- /dev/null
> +++ b/arch/arm/mach-bcm/hotplug-brcmstb.c
> @@ -0,0 +1,334 @@
> +/*
> + * Broadcom STB CPU hotplug support for ARM
> + *
> + * Copyright (C) 2013 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/jiffies.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/printk.h>
> +#include <linux/regmap.h>
> +#include <linux/smp.h>
> +#include <linux/mfd/syscon.h>
> +
> +#include <asm/cacheflush.h>
> +#include <asm/mach-types.h>
> +
> +#include "brcmstb.h"
> +
> +enum {
> + ZONE_MAN_CLKEN_MASK = BIT(0),
> + ZONE_MAN_RESET_CNTL_MASK = BIT(1),
> + ZONE_MAN_MEM_PWR_MASK = BIT(4),
> + ZONE_RESERVED_1_MASK = BIT(5),
> + ZONE_MAN_ISO_CNTL_MASK = BIT(6),
> + ZONE_MANUAL_CONTROL_MASK = BIT(7),
> + ZONE_PWR_DN_REQ_MASK = BIT(9),
> + ZONE_PWR_UP_REQ_MASK = BIT(10),
> + ZONE_BLK_RST_ASSERT_MASK = BIT(10),
> + ZONE_PWR_OFF_STATE_MASK = BIT(26),
> + ZONE_PWR_ON_STATE_MASK = BIT(26),
> + ZONE_DPG_PWR_STATE_MASK = BIT(28),
> + ZONE_MEM_PWR_STATE_MASK = BIT(29),
> + ZONE_RESET_STATE_MASK = BIT(31),
> +};
> +
> +static void __iomem *cpubiuctrl_block;
> +static void __iomem *hif_cont_block;
> +static u32 cpu0_pwr_zone_ctrl_reg;
> +static u32 cpu_rst_cfg_reg;
> +static u32 hif_cont_reg;
> +DEFINE_PER_CPU(int, per_cpu_sw_state);
> +
> +static void __iomem *pwr_ctrl_get_base(unsigned int cpu)
> +{
> + void __iomem *base = cpubiuctrl_block + cpu0_pwr_zone_ctrl_reg;
> + base += (cpu * 4);
CPU isn't guaranteed to be the physical CPU ID (MPIDR.Aff*). While it
almost certainly will be, we can't guarantee it in the face of a kexec,
for example.
You can use cpu_logical_map(cpu) to get the physical ID.
> + return base;
> +}
> +
> +static u32 pwr_ctrl_rd(unsigned int cpu)
> +{
> + void __iomem *base = pwr_ctrl_get_base(cpu);
> + return readl_relaxed(base);
> +}
> +
> +static void pwr_ctrl_wr(unsigned int cpu, u32 val)
> +{
> + void __iomem *base = pwr_ctrl_get_base(cpu);
> + writel(val, base);
> +}
> +
> +static void cpu_rst_cfg_set(int cpu, int set)
> +{
> + u32 val;
> + val = readl_relaxed(cpubiuctrl_block + cpu_rst_cfg_reg);
> + if (set)
> + val |= BIT(cpu);
> + else
> + val &= ~BIT(cpu);
Likewise here.
> + writel_relaxed(val, cpubiuctrl_block + cpu_rst_cfg_reg);
> +}
> +
> +static void cpu_set_boot_addr(int cpu, unsigned long boot_addr)
> +{
> + const int reg_ofs = cpu * 8;
And here.
> + writel_relaxed(0, hif_cont_block + hif_cont_reg + reg_ofs);
> + writel_relaxed(boot_addr, hif_cont_block + hif_cont_reg + 4 + reg_ofs);
> +}
> +
> +void brcmstb_cpu_boot(unsigned int cpu)
> +{
> + pr_info("SMP: Booting CPU%d...\n", cpu);
> +
> + /*
> + * set the reset vector to point to the secondary_startup
> + * routine
> + */
> + cpu_set_boot_addr(cpu, virt_to_phys(brcmstb_secondary_startup));
> +
> + flush_cache_all();
Why? What does the new CPU need before its caches are coherent and up?
> +
> + /* unhalt the cpu */
> + cpu_rst_cfg_set(cpu, 0);
> +}
> +
> +void brcmstb_cpu_power_on(unsigned int cpu)
> +{
> + /*
> + * The secondary cores power was cut, so we must go through
> + * power-on initialization.
> + */
> + u32 tmp;
> +
> + pr_info("SMP: Powering up CPU%d...\n", cpu);
> +
> + /* Request zone power up */
> + pwr_ctrl_wr(cpu, ZONE_PWR_UP_REQ_MASK);
> +
> + /* Wait for the power up FSM to complete */
> + do {
> + tmp = pwr_ctrl_rd(cpu);
> + } while (!(tmp & ZONE_PWR_ON_STATE_MASK));
> +
> + per_cpu(per_cpu_sw_state, cpu) = 1;
> +}
> +
> +int brcmstb_cpu_get_power_state(unsigned int cpu)
> +{
> + int tmp = pwr_ctrl_rd(cpu);
> + return (tmp & ZONE_RESET_STATE_MASK) ? 0 : 1;
> +}
> +
> +void __ref brcmstb_cpu_die(unsigned int cpu)
> +{
> + /* Derived from misc_bpcm_arm.c */
> +
> + /* Clear SCTLR.C bit */
> + __asm__(
> + "mrc p15, 0, r0, c1, c0, 0\n"
> + "bic r0, r0, #(1 << 2)\n"
> + "mcr p15, 0, r0, c1, c0, 0\n"
> + : /* no output */
> + : /* no input */
> + : "r0" /* clobber r0 */
> + );
This is odd. Why not allow GCC to allocate the register?
> +
> + /*
> + * Instruction barrier to ensure cache is really disabled before
> + * cleaning/invalidating the caches
> + */
> + isb();
I think you could use:
set_cr(get_cr() & ~CR_C))
Which would do all of the above (including the isb), and will get GCC to
allocate the register.
> +
> + flush_cache_all();
> +
> + /* Invalidate all instruction caches to PoU (ICIALLU) */
> + /* Data sync. barrier to ensure caches have emptied out */
> + __asm__("mcr p15, 0, r0, c7, c5, 0\n" : : : "r0");
> + dsb();
Why do you need to invalidate the I-cache?
> +
> + /*
> + * Clear ACTLR.SMP bit to prevent broadcast TLB messages from reaching
> + * this core
> + */
> + __asm__(
> + "mrc p15, 0, r0, c1, c0, 1\n"
> + "bic r0, r0, #(1 << 6)\n"
> + "mcr p15, 0, r0, c1, c0, 1\n"
> + : /* no output */
> + : /* no input */
> + : "r0" /* clobber r0 */
> + );
Surely you can use an output operand to get GCC to allocate the register
for you?
> +
> + /* Disable all IRQs for this CPU */
> + arch_local_irq_disable();
> +
> + per_cpu(per_cpu_sw_state, cpu) = 0;
Your caches are off at this point, so this could be going straight to
memory. Yet readers of this value aren't cleaning their caches before
reading this, so they could hit a stale cached copy.
> +
> + /*
> + * Final full barrier to ensure everything before this instruction has
> + * quiesced.
> + */
> + isb();
> + dsb();
> +
> + /* Sit and wait to die */
> + wfi();
> +
> + /* We should never get here... */
> + nop();
Why the nop first?
> + panic("Spurious interrupt on CPU %d received!\n", cpu);
> +}
> +
> +int brcmstb_cpu_kill(unsigned int cpu)
> +{
> + u32 tmp;
> +
> + pr_info("SMP: Powering down CPU%d...\n", cpu);
> +
> + while (per_cpu(per_cpu_sw_state, cpu))
> + ;
As this was written to with caches disabled, the cached copy of the
value (which this is reading) could be stale. Surely you need to
clean+invalidate the line for this value each time you read it to give
it a chance to update?
> +
> + /* Program zone reset */
> + pwr_ctrl_wr(cpu, ZONE_RESET_STATE_MASK | ZONE_BLK_RST_ASSERT_MASK |
> + ZONE_PWR_DN_REQ_MASK);
> +
> + /* Verify zone reset */
> + tmp = pwr_ctrl_rd(cpu);
> + if (!(tmp & ZONE_RESET_STATE_MASK))
> + pr_err("%s: Zone reset bit for CPU %d not asserted!\n",
> + __func__, cpu);
> +
> + /* Wait for power down */
> + do {
> + tmp = pwr_ctrl_rd(cpu);
> + } while (!(tmp & ZONE_PWR_OFF_STATE_MASK));
> +
> + /* Settle-time from Broadcom-internal DVT reference code */
> + udelay(7);
> +
> + /* Assert reset on the CPU */
> + cpu_rst_cfg_set(cpu, 1);
> +
> + return 1;
> +}
> +
> +static int __init setup_hifcpubiuctrl_regs(struct device_node *np)
> +{
> + int rc = 0;
> + char *name;
> + int index;
> + struct device_node *syscon_np = NULL;
> +
> + name = "syscon-cpu";
> +
> + syscon_np = of_parse_phandle(np, name, 0);
> + if (!syscon_np) {
> + pr_err("can't find phandle %s\n", name);
> + rc = -EINVAL;
> + goto cleanup;
> + }
> +
> + cpubiuctrl_block = of_iomap(syscon_np, 0);
> + if (!cpubiuctrl_block) {
> + pr_err("iomap failed for cpubiuctrl_block\n");
> + rc = -EINVAL;
> + goto cleanup;
> + }
> +
> + index = 1;
> + rc = of_property_read_u32_index(np, name, index,
> + &cpu0_pwr_zone_ctrl_reg);
The index variable seems rather pointless. Why not just use the value
in-place?
> + if (rc) {
> + pr_err("failed to read %d from %s property (%d)\n", index, name,
> + rc);
It might be better to state _what_ you're looking for (what does the
value represent?).
> + rc = -EINVAL;
> + goto cleanup;
> + }
> +
> + index = 2;
> + rc = of_property_read_u32_index(np, name, index, &cpu_rst_cfg_reg);
Likewise for all of the above.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Tomi Valkeinen @ 2014-01-24 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0333F.4000400@gmail.com>
On 2014-01-22 23:08, Ivaylo Dimitrov wrote:
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues
I don't know, it wasn't immediately clear to me if the reserved memory
was handled with CMA or not.
Also, we have this funniness that omapfb is not present in DT data, so
we can't give reserved memory to omapfb directly like that.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140124/ee42870f/attachment.sig>
^ permalink raw reply
* [PATCH v5 4/8] ARM: do CPU-specific init for Broadcom Brahma15 cores
From: Mark Rutland @ 2014-01-24 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390361452-3124-5-git-send-email-marc.ceeeee@gmail.com>
On Wed, Jan 22, 2014 at 03:30:48AM +0000, Marc Carino wrote:
> Perform any CPU-specific initialization required on the
> Broadcom Brahma-15 core.
>
> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/mm/proc-v7.S | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index bd17819..98ea423 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -193,6 +193,7 @@ __v7_cr7mp_setup:
> b 1f
> __v7_ca7mp_setup:
> __v7_ca15mp_setup:
> +__v7_b15mp_setup:
> mov r10, #0
> 1:
> #ifdef CONFIG_SMP
> @@ -494,6 +495,16 @@ __v7_ca15mp_proc_info:
> .size __v7_ca15mp_proc_info, . - __v7_ca15mp_proc_info
>
> /*
> + * Broadcom Corporation Brahma-B15 processor.
> + */
> + .type __v7_b15mp_proc_info, #object
> +__v7_b15mp_proc_info:
> + .long 0x420f00f0
> + .long 0xff0ffff0
> + __v7_proc __v7_b15mp_setup, hwcaps = HWCAP_IDIV
On the third posting, Will Deacon asked if the hwcap override was really
required [1]. Two postings later there's been no answer.
Is your CPUID_EXT_ISAR0 value wrong? If so, please add a comment to that
effect (as with __krait_proc_info).
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/225895.html
^ permalink raw reply
* [PATCH 3/3] irqchip: orion: clear stale interrupts in irq_enable
From: Russell King - ARM Linux @ 2014-01-24 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123225208.GA24778@obsidianresearch.com>
On Thu, Jan 23, 2014 at 03:52:08PM -0700, Jason Gunthorpe wrote:
> On Thu, Jan 23, 2014 at 11:38:06PM +0100, Sebastian Hesselbarth wrote:
> > Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
> > IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
> > them before unmask. This installs an .irq_enable callback to ensure stale
> > irqs are cleared before initial unmask.
>
> I'm not sure if putting this in irq_enable is correct. I think this
> should only happen at irq_startup.
>
> The question boils down to what is supposed to happen with this code
> sequence:
>
> disable_irq(..);
> write(.. something to cause an interrupt edge ..);
> .. synchronize ..
> enable_irq(..);
>
> Do we get the interrupt or not?
The answer is... yes, the interrupt should be delivered after the
interrupt is re-enabled.
> I found this message from Linus long ago:
> http://yarchive.net/comp/linux/edge_triggered_interrupts.html
> > Btw, the "disable_irq()/enable_irq()" subsystem has been written so that
> > when you disable an edge-triggered interrupt, and the edge happens while
> > the interrupt is disabled, we will re-play the interrupt at enable time.
> > Exactly so that drivers can have an easier time and don't have to
> > normally worry about whether something is edge or level-triggered.
>
> And found this note in Documentation/DocBook/genericirq.tmpl:
>
> > This prevents losing edge interrupts on hardware which does
> > not store an edge interrupt event while the interrupt is disabled at
> > the hardware level.
>
> So I think it is very clear that the chip driver should not discard
> edges that happened while the interrupt was disabled.
Correct.
--
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 v5 6/8] ARM: brcmstb: add misc. DT bindings for brcmstb
From: Mark Rutland @ 2014-01-24 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390361452-3124-7-git-send-email-marc.ceeeee@gmail.com>
On Wed, Jan 22, 2014 at 03:30:50AM +0000, Marc Carino wrote:
> 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 | 95 ++++++++++++++++++++
> 1 files changed, 95 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..3c436cc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
> @@ -0,0 +1,95 @@
> +ARM Broadcom STB platforms Device Tree Bindings
> +-----------------------------------------------
> +Boards with Broadcom Brahma15 ARM-based BCMxxxx (generally BCM7xxx variants)
> +SoC shall have the following DT organization:
> +
> +Required root node properties:
> + - compatible: "brcm,bcm<chip_id>", "brcm,brcmstb"
> +
> +example:
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + model = "Broadcom STB (bcm7445)";
> + compatible = "brcm,bcm7445", "brcm,brcmstb";
> +
> +Further, syscon nodes that map platform-specific registers used for general
> +system control is required:
> +
> + - compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon"
> + - compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
> + - compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
> +
> +example:
> + rdb {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + ranges = <0 0x00 0xf0000000 0x1000000>;
> +
> + sun_top_ctrl: syscon at 404000 {
> + compatible = "brcm,bcm7445-sun-top-ctrl", "syscon";
> + reg = <0x404000 0x51c>;
> + };
> +
> + hif_cpubiuctrl: syscon at 3e2400 {
> + compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
> + reg = <0x3e2400 0x5b4>;
> + };
> +
> + hif_continuation: syscon at 452000 {
> + compatible = "brcm,bcm7445-hif-continuation", "syscon";
> + reg = <0x452000 0x100>;
> + };
> + };
> +
> +Lastly, nodes that allow for support of SMP initialization and reboot are
> +required:
> +
> +smpboot
> +-------
> +Required properties:
> +
> + - compatible
> + The string "brcm,brcmstb-smpboot".
> +
> + - syscon-cpu
> + A phandle / integer array property which lets the BSP know the location
> + of certain CPU power-on registers.
> +
> + The layout of the property is as follows:
> + o a phandle to the "hif_cpubiuctrl" syscon node
> + o offset to the base CPU power zone register
> + o offset to the base CPU reset register
How variable are these values?
> +
> + - syscon-cont
> + A phandle pointing to the syscon node which describes the CPU boot
> + continuation registers.
> + o a phandle to the "hif_continuation" syscon node
> +
> +example:
> + smpboot {
> + compatible = "brcm,brcmstb-smpboot";
> + syscon-cpu = <&hif_cpubiuctrl 0x88 0x178>;
> + syscon-cont = <&hif_continuation>;
> + };
This looks odd. This doesn't seem like a device, but rather a grouping
of disparate devices used for a particular software purpose.
> +
> +reboot
> +-------
> +Required properties
> +
> + - compatible
> + The string property "brcm,brcmstb-reboot".
> +
> + - syscon
> + A phandle / integer array that points to the syscon node which describes
> + the general system reset registers.
> + o a phandle to "sun_top_ctrl"
> + o offset to the "reset source enable" register
> + o offset to the "software master reset" register
How variable are these values?
> +
> +example:
> + reboot {
> + compatible = "brcm,brcmstb-reboot";
> + syscon = <&sun_top_ctrl 0x304 0x308>;
> + };
As with smpboot, this seems odd.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v5 8/8] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
From: Mark Rutland @ 2014-01-24 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390361452-3124-9-git-send-email-marc.ceeeee@gmail.com>
On Wed, Jan 22, 2014 at 03:30:52AM +0000, Marc Carino wrote:
> 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/bcm7445.dts | 111 +++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 111 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/bcm7445.dts
>
> diff --git a/arch/arm/boot/dts/bcm7445.dts b/arch/arm/boot/dts/bcm7445.dts
> new file mode 100644
> index 0000000..ffa3305
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm7445.dts
> @@ -0,0 +1,111 @@
> +/dts-v1/;
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + model = "Broadcom STB (bcm7445)";
> + compatible = "brcm,bcm7445", "brcm,brcmstb";
> + interrupt-parent = <&gic>;
> +
> + chosen {};
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00 0x00000000 0x00 0x40000000>,
> + <0x00 0x40000000 0x00 0x40000000>,
> + <0x00 0x80000000 0x00 0x40000000>;
> + };
As I commented on v3 [1], these are contiguous and can be described with
a single entry:
memory {
device_type = "memory";
reg = <0x0 0x00000000 0x0 0xc0000000>;
};
Is there any reason to have three entries?
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/225899.html
^ permalink raw reply
* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Srikanth Thokala @ 2014-01-24 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0FC22.8060903@metafoo.de>
Hi Lars,
On Thu, Jan 23, 2014 at 4:55 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> On 01/22/2014 05:52 PM, Srikanth Thokala wrote:
> [...]
>> +/**
>> + * xilinx_vdma_device_control - Configure DMA channel of the device
>> + * @dchan: DMA Channel pointer
>> + * @cmd: DMA control command
>> + * @arg: Channel configuration
>> + *
>> + * Return: '0' on success and failure value on error
>> + */
>> +static int xilinx_vdma_device_control(struct dma_chan *dchan,
>> + enum dma_ctrl_cmd cmd, unsigned long arg)
>> +{
>> + struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
>> +
>> + switch (cmd) {
>> + case DMA_TERMINATE_ALL:
>> + xilinx_vdma_terminate_all(chan);
>> + return 0;
>> + case DMA_SLAVE_CONFIG:
>> + return xilinx_vdma_slave_config(chan,
>> + (struct xilinx_vdma_config *)arg);
>
> You really shouldn't be overloading the generic API with your own semantics.
> DMA_SLAVE_CONFIG should take a dma_slave_config and nothing else.
Ok. The driver needs few additional configuration from the slave
device like Vertical
Size, Horizontal Size, Stride etc., for the DMA transfers, in that case do you
suggest me to define a separate dma_ctrl_cmd like the one FSLDMA_EXTERNAL_START
defined for Freescale drivers?
>
>> + default:
>> + return -ENXIO;
>> + }
>> +}
>> +
> [...]
>> +
>> + /* Request the interrupt */
>> + chan->irq = irq_of_parse_and_map(node, 0);
>> + err = devm_request_irq(xdev->dev, chan->irq, xilinx_vdma_irq_handler,
>> + IRQF_SHARED, "xilinx-vdma-controller", chan);
>
> This is a clasic example of where to not use devm_request_irq. 'chan' is
> accessed in the interrupt handler, but if you use devm_request_irq 'chan'
> will be freed before the interrupt handler has been released, which means
> there is now a race condition where the interrupt handler can access already
> freed memory.
Ok, thank you for the clarification on this thread. I will fix it in v3.
>
>> + if (err) {
>> + dev_err(xdev->dev, "unable to request IRQ\n");
>> + return err;
>> + }
>> +
>> + /* Initialize the DMA channel and add it to the DMA engine channels
>> + * list.
>> + */
>> + chan->common.device = &xdev->common;
>> +
>> + list_add_tail(&chan->common.device_node, &xdev->common.channels);
>> + xdev->chan[chan->id] = chan;
>> +
>> + /* Reset the channel */
>> + err = xilinx_vdma_chan_reset(chan);
>> + if (err < 0) {
>> + dev_err(xdev->dev, "Reset channel failed\n");
>> + return err;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * struct of_dma_filter_xilinx_args - Channel filter args
>> + * @dev: DMA device structure
>> + * @chan_id: Channel id
>> + */
>> +struct of_dma_filter_xilinx_args {
>> + struct dma_device *dev;
>> + u32 chan_id;
>> +};
>> +
>> +/**
>> + * xilinx_vdma_dt_filter - VDMA channel filter function
>> + * @chan: DMA channel pointer
>> + * @param: Filter match value
>> + *
>> + * Return: true/false based on the result
>> + */
>> +static bool xilinx_vdma_dt_filter(struct dma_chan *chan, void *param)
>> +{
>> + struct of_dma_filter_xilinx_args *args = param;
>> +
>> + return chan->device == args->dev && chan->chan_id == args->chan_id;
>> +}
>> +
>> +/**
>> + * of_dma_xilinx_xlate - Translation function
>> + * @dma_spec: Pointer to DMA specifier as found in the device tree
>> + * @ofdma: Pointer to DMA controller data
>> + *
>> + * Return: DMA channel pointer on success and NULL on error
>> + */
>> +static struct dma_chan *of_dma_xilinx_xlate(struct of_phandle_args *dma_spec,
>> + struct of_dma *ofdma)
>> +{
>> + struct of_dma_filter_xilinx_args args;
>> + dma_cap_mask_t cap;
>> +
>> + args.dev = ofdma->of_dma_data;
>> + if (!args.dev)
>> + return NULL;
>> +
>> + if (dma_spec->args_count != 1)
>> + return NULL;
>> +
>> + dma_cap_zero(cap);
>> + dma_cap_set(DMA_SLAVE, cap);
>> +
>> + args.chan_id = dma_spec->args[0];
>> +
>> + return dma_request_channel(cap, xilinx_vdma_dt_filter, &args);
>
> There is a new helper function called dma_get_slave_channel, which makes
> this much easier. Take a look at the k3dma.c driver for an example.
Ok. I will check and fix it in v3.
Srikanth
>> +}
>
> --
> 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
* [PATCH v4 3/3] serial: fsl_lpuart: documented the clock requirement.
From: Mark Rutland @ 2014-01-24 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390363773-24108-4-git-send-email-yao.yuan@freescale.com>
On Wed, Jan 22, 2014 at 04:09:33AM +0000, Yuan Yao wrote:
> It was previously required but not documented.
> Add the text to the binding along with the new "dmas" addition.
>
> Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
> ---
> Documentation/devicetree/bindings/serial/fsl-lpuart.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> index 6e1cbbf..9666f97 100644
> --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> @@ -4,6 +4,8 @@ Required properties:
> - compatible : Should be "fsl,<soc>-lpuart"
> - reg : Address and length of the register set for the device
> - interrupts : Should contain uart interrupt
> +- clocks : phandle + clock specifier pairs, one for each entry in clock-names
> +- clock-names : should contain: "ipg" - the uart clock
>
> Optional properties:
> - dmas: Generic dma devicetree binding as described
> @@ -19,6 +21,8 @@ uart0: serial at 40027000 {
> compatible = "fsl,vf610-lpuart";
> reg = <0x40027000 0x1000>;
> interrupts = <0 61 0x00>;
> + clocks = <&clks VF610_CLK_UART0>;
> + clock-names = "ipg";
> dmas = <&edma0 0 2>,
> <&edma0 0 3>;
> dma-names = "rx","tx";
As this was a previous requirement, and this is a correction to the
documentation rather than a binding change:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
^ 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