* [PATCH V4 09/10] trace, ras: add ARM processor error trace event
From: Steven Rostedt @ 2016-10-21 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477071013-29563-10-git-send-email-tbaicar@codeaurora.org>
On Fri, 21 Oct 2016 11:30:12 -0600
Tyler Baicar <tbaicar@codeaurora.org> wrote:
> Currently there are trace events for the various RAS
> errors with the exception of ARM processor type errors.
> Add a new trace event for such errors so that the user
> will know when they occur. These trace events are
> consistent with the ARM processor error section type
> defined in UEFI 2.6 spec section N.2.4.4.
>
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
Tracing part looks fine to me.
Acked-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* [PATCH 2/3] ARM: convert to generated system call tables
From: Arnd Bergmann @ 2016-10-21 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021154856.GC1041@n2100.armlinux.org.uk>
On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
> On Fri, Oct 21, 2016 at 05:18:30PM +0200, Arnd Bergmann wrote:
> > On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> > > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> >
> > > > If we hit this case, why not just use the wrapper on both EABI
> > > > and OABI for simplicity? It's not like we care a lot about
> > > > micro-optimizing OABI any more.
> > >
> > > I'd still like to retain the ability to only add to EABI in the future.
> >
> > Do you mean to add an EABI specific workaround for a specific syscall
> > if necessary, or to stop adding OABI syscalls altogether?
>
> To stop adding OABI syscalls altogether. I'm sure that there will
> come a point (if it hasn't already) that glibc no longer supports
> OABI, and at that point it probably becomes rather silly to keep
> adding OABI syscalls.
Ok. While uClibc still supports OABI, it seems rather unlikely that
there are active users of OABI uClibc that need any of the future
syscalls.
> > > > That brings up an interesting issue: it would be nice to use the
> > > > same input file for arch/arm/ and the compat mode of arch/arm64,
> > > > like x86 does. If we handle both oabi and arm64-compat in the same
> > > > file, we end up with a superset of what x86 does, and we could
> > > > use a single script again, and generate all four tables for
> > > > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> > >
> > > OABI-compat != ARM64-EABI-compat though. They're two completely
> > > different things.
> >
> > For the purpose of generating the tables, I don't see much
> > difference: we either use the fourth column only in native
> > mode, or we use the fifth column to override values from
> > the fourth one when emulating the ABI on the "other" kernel.
>
> The table generation method can be shared, but I've no idea about the
> feasibility of sharing the table between ARM64 and ARM - I don't know
> enough about ARM64 to know whether things like an "long" argument to
> a syscall (which would be 64-bit on ARM64) would be or would not be a
> problem if called from a 32-bit user application.
>
> I've zero knowledge of the whole 32-bit application on 64-bit CPUs
> thing, so it's pointless trying to discuss this aspect with me. Even
> for x86, all I care there is that it works, I've no knowledge of how
> it works.
Ok. I'm sure it works, but we can definitely leave that for the
time when I or someone else gets around to do the same conversion
for ARM64 that you are doing for ARM32. From all I can tell, it's
a natural extension of the file you already have.
> > That's similar to x86, 32-bit syscalls use the traditional numbers
> > with an optionally different entry point for compat mode, while
> > 64-bit syscalls use a somewhat reduced table that now has support
> > for both native 64-bit and "x32" mode. x86-64 and x32 share a
> > syscall table but not the unistd.h list, all three generated
> > from syscall_64.tbl.
>
> What's the point of the x32 mode?
On x86, the motivation is faster code for most use cases that
don't need a lot of memory, as the 64-bit opcodes have 16 registers
rather than 8 in 32-bit mode but 32-bit pointers have lower
cache footprint than 64-bit pointers.
Interestingly, while ARM64 is doing basically the same thing now,
the motivation is almost entirely different: going from around 16
to around 32 registers has a much lower impact on performance
than starting out with 8, but there are ARMv8 implementations that
lack aarch32 mode but still want to run legacy 32-bit code that
is too time-consuming to get 64-bit clean.
> > ARM64 has a separate list of syscalls for compat mode in
> > arch/arm64/include/asm/unistd32.h, this list has the same format
> > as include/asm-generic/uapi/unistd.h and must be updated manually
> > to match the arch/arm/ table today.
>
> Looking through it, sort-of. It could have re-used the numbering
> from the arch/arm include file, but because ARM64 wanted to be an
> entirely separate architecture, it duplicates a lot from 32-bit ARM.
> I pointed that out at the time, and was shouted down (which is why
> today I have absolutely nothing to do with ARM64, and as a result
> have very little knowledge about ARM64 - I lost interest in it as
> a result of the responses I got to my comments.)
>
> So... if you don't mind, this isn't an issue I care one iota about.
>
> In order for something to work like what you're alluding to, ARM64
> would have to ferret around in arch/arm to pull out the bits it
> wants, and I see zero reason for that to be acceptable on either
> side of the ARM64 vs ARM divide - it will make my job harder because
> I'm then into the position where I need acks from ARM64 people to
> change ARM code, and that doesn't interest me at all. I'm not going
> to put myself into a position where I'm at the mercy of ARM64 folk.
Well, if we don't need to worry about OABI any more, using a shared
file for all architectures to add new syscalls (with their compat
handlers) would also mean that you don't have to worry about the
compat handler either, since that gets added in the shared file
along with the syscall.
Then again, if we move the a shared file for new syscalls, we also
don't need to worry about synchronizing the syscall tables for
ARM and compat ARM64, since the files would not get changed any
more.
Arnd
^ permalink raw reply
* [PATCH v4 0/7] Add R8A7743/SK-RZG1M board support
From: Sergei Shtylyov @ 2016-10-21 20:39 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
Here's the set of 8 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20161021-v4.9-rc1' tag. I'm adding the device tree support for
the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
seems identical to the R8A7791/Porter board. The device tree patches depend on
the R8A7743 CPG/MSSR driver series just posted in order to compile and work.
Already merged patches from this series won't be re-posted.
[1/7] ARM: dts: r8a7743: initial SoC device tree
[2/7] ARM: dts: r8a7743: add SYS-DMAC support
[3/7] ARM: dts: r8a7743: add [H]SCIF{A|B} support
[4/7] ARM: dts: r8a7743: add Ether support
[5/7] ARM: dts: r8a7743: add IRQC support
[6/7] ARM: dts: sk-rzg1m: initial device tree
[7/7] ARM: dts: sk-rzg1m: add Ether support
WBR, Sergei
^ permalink raw reply
* [PATCH v4 1/7] ARM: dts: r8a7743: initial SoC device tree
From: Sergei Shtylyov @ 2016-10-21 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2719479.geOc9vqcRS@wasted.cogentembedded.com>
The initial R8A7743 SoC device tree including CPU0, GIC, timer, SYSC, CPG,
and the required clock descriptions.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 4:
- removed the CPU1 node, updated the patch description accordingly;
- reformatted the "interrupts" props of the GIC/timer device nodes;
- added Geert's tag.
Changes in version 3:
- changed the R8A7743 clock header #include;
- replaced the multiple clock nodes with the single CPG node, updated the
"clocks" property in the CPU0 node, updated the patch description.
Changes in version 2:
- added the IRQC and Ether clocks.
arch/arm/boot/dts/r8a7743.dtsi | 115 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 115 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -0,0 +1,115 @@
+/*
+ * Device Tree Source for the r8a7743 SoC
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/r8a7743-cpg-mssr.h>
+#include <dt-bindings/power/r8a7743-sysc.h>
+
+/ {
+ compatible = "renesas,r8a7743";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ clock-frequency = <1500000000>;
+ clocks = <&cpg CPG_CORE R8A7743_CLK_Z>;
+ power-domains = <&sysc R8A7743_PD_CA15_CPU0>;
+ next-level-cache = <&L2_CA15>;
+ };
+
+ L2_CA15: cache-controller at 0 {
+ compatible = "cache";
+ reg = <0>;
+ cache-unified;
+ cache-level = <2>;
+ power-domains = <&sysc R8A7743_PD_CA15_SCU>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller at f1001000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0 0xf1001000 0 0x1000>,
+ <0 0xf1002000 0 0x1000>,
+ <0 0xf1004000 0 0x2000>,
+ <0 0xf1006000 0 0x2000>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ cpg: clock-controller at e6150000 {
+ compatible = "renesas,r8a7743-cpg-mssr";
+ reg = <0 0xe6150000 0 0x1000>;
+ clocks = <&extal_clk>, <&usb_extal_clk>;
+ clock-names = "extal", "usb_extal";
+ #clock-cells = <2>;
+ #power-domain-cells = <0>;
+ };
+
+ sysc: system-controller at e6180000 {
+ compatible = "renesas,r8a7743-sysc";
+ reg = <0 0xe6180000 0 0x0200>;
+ #power-domain-cells = <1>;
+ };
+ };
+
+ /* External root clock */
+ extal_clk: extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overriden by the board. */
+ clock-frequency = <0>;
+ };
+
+ /* External USB clock - can be overridden by the board */
+ usb_extal_clk: usb_extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <48000000>;
+ };
+
+ /* External SCIF clock */
+ scif_clk: scif {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+};
^ permalink raw reply
* [PATCH v4 2/7] ARM: dts: r8a7743: add SYS-DMAC support
From: Sergei Shtylyov @ 2016-10-21 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2719479.geOc9vqcRS@wasted.cogentembedded.com>
Describe SYS-DMAC0/1 in the R8A7743 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 4:
- refreshed the patch.
Changes in version 3:
- resolved a reject;
- updated the "clocks" properties for the CPG/MSSR driver.
Changes in version 2:
- added Geert's tag.
arch/arm/boot/dts/r8a7743.dtsi | 64 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -88,6 +88,70 @@
reg = <0 0xe6180000 0 0x0200>;
#power-domain-cells = <1>;
};
+
+ dmac0: dma-controller at e6700000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6700000 0 0x20000>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&cpg CPG_MOD 219>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
+
+ dmac1: dma-controller at e6720000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6720000 0 0x20000>;
+ interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&cpg CPG_MOD 218>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
};
/* External root clock */
^ permalink raw reply
* [PATCH v4 3/7] ARM: dts: r8a7743: add [H]SCIF{|A|B} support
From: Sergei Shtylyov @ 2016-10-21 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2719479.geOc9vqcRS@wasted.cogentembedded.com>
Describe [H]SCIF{|A|B} ports in the R8A7743 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 4:
- corrected RBNF in the patch description/subject;
- used the R-Car gen2 bindings instead of the RZ/G family ones;
- refreshed the patch;
- added Geert's tag.
Changes in version 3:
- resolved a reject;
- updated the "clocks" properties for the CPG/MSSR driver;
- renamed the patch.
Changes in version 2:
- used the new RZ/G family "compatible" prop values, reformatting where needed;
- fixed the size cells of the SCIFB device nodes' "reg" properties;
- changed the size cells of the "reg" properties to hexadecimal;
- indented the SCIFA1 device node's closing brace correctly
- adjusted the patch description, renamed the patch.
arch/arm/boot/dts/r8a7743.dtsi | 261 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 261 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -152,6 +152,267 @@
#dma-cells = <1>;
dma-channels = <15>;
};
+
+ scifa0: serial at e6c40000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c40000 0 0x40>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 204>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x21>, <&dmac0 0x22>,
+ <&dmac1 0x21>, <&dmac1 0x22>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa1: serial at e6c50000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c50000 0 0x40>;
+ interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 203>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x25>, <&dmac0 0x26>,
+ <&dmac1 0x25>, <&dmac1 0x26>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa2: serial at e6c60000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c60000 0 0x40>;
+ interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 202>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x27>, <&dmac0 0x28>,
+ <&dmac1 0x27>, <&dmac1 0x28>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa3: serial at e6c70000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c70000 0 0x40>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1106>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1b>, <&dmac0 0x1c>,
+ <&dmac1 0x1b>, <&dmac1 0x1c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa4: serial at e6c78000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c78000 0 0x40>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1107>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1f>, <&dmac0 0x20>,
+ <&dmac1 0x1f>, <&dmac1 0x20>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa5: serial at e6c80000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c80000 0 0x40>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1108>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x23>, <&dmac0 0x24>,
+ <&dmac1 0x23>, <&dmac1 0x24>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb0: serial at e6c20000 {
+ compatible = "renesas,scifb-r8a7743",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6c20000 0 0x100>;
+ interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 206>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x3d>, <&dmac0 0x3e>,
+ <&dmac1 0x3d>, <&dmac1 0x3e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb1: serial at e6c30000 {
+ compatible = "renesas,scifb-r8a7743",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6c30000 0 0x100>;
+ interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 207>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x19>, <&dmac0 0x1a>,
+ <&dmac1 0x19>, <&dmac1 0x1a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb2: serial at e6ce0000 {
+ compatible = "renesas,scifb-r8a7743",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6ce0000 0 0x100>;
+ interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 216>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1d>, <&dmac0 0x1e>,
+ <&dmac1 0x1d>, <&dmac1 0x1e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif0: serial at e6e60000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e60000 0 0x40>;
+ interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 721>,
+ <&cpg CPG_CORE R8A7743_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x29>, <&dmac0 0x2a>,
+ <&dmac1 0x29>, <&dmac1 0x2a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif1: serial at e6e68000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e68000 0 0x40>;
+ interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 720>,
+ <&cpg CPG_CORE R8A7743_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2d>, <&dmac0 0x2e>,
+ <&dmac1 0x2d>, <&dmac1 0x2e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif2: serial at e6e58000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e58000 0 0x40>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 719>,
+ <&cpg CPG_CORE R8A7743_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2b>, <&dmac0 0x2c>,
+ <&dmac1 0x2b>, <&dmac1 0x2c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif3: serial at e6ea8000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ea8000 0 0x40>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 718>,
+ <&cpg CPG_CORE R8A7743_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2f>, <&dmac0 0x30>,
+ <&dmac1 0x2f>, <&dmac1 0x30>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif4: serial at e6ee0000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ee0000 0 0x40>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 715>,
+ <&cpg CPG_CORE R8A7743_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0xfb>, <&dmac0 0xfc>,
+ <&dmac1 0xfb>, <&dmac1 0xfc>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif5: serial at e6ee8000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ee8000 0 0x40>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 714>,
+ <&cpg CPG_CORE R8A7743_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0xfd>, <&dmac0 0xfe>,
+ <&dmac1 0xfd>, <&dmac1 0xfe>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif0: serial at e62c0000 {
+ compatible = "renesas,hscif-r8a7743",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62c0000 0 0x60>;
+ interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 717>,
+ <&cpg CPG_CORE R8A7743_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x39>, <&dmac0 0x3a>,
+ <&dmac1 0x39>, <&dmac1 0x3a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif1: serial at e62c8000 {
+ compatible = "renesas,hscif-r8a7743",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62c8000 0 0x60>;
+ interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 716>,
+ <&cpg CPG_CORE R8A7743_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x4d>, <&dmac0 0x4e>,
+ <&dmac1 0x4d>, <&dmac1 0x4e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif2: serial at e62d0000 {
+ compatible = "renesas,hscif-r8a7743",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62d0000 0 0x60>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 713>,
+ <&cpg CPG_CORE R8A7743_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x3b>, <&dmac0 0x3c>,
+ <&dmac1 0x3b>, <&dmac1 0x3c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
};
/* External root clock */
^ permalink raw reply
* [PATCH v4 4/7] ARM: dts: r8a7743: add Ether support
From: Sergei Shtylyov @ 2016-10-21 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2719479.geOc9vqcRS@wasted.cogentembedded.com>
Define the generic R8A7743 part of the Ether device node.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 4:
- refreshed the patch;
- added Geert's tag.
Changes in version 3:
- resolved a reject;
- updated the "clocks" property for the CPG/MSSR driver.
Changes in version 2:
- new patch.
arch/arm/boot/dts/r8a7743.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -413,6 +413,18 @@
power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
status = "disabled";
};
+
+ ether: ethernet at ee700000 {
+ compatible = "renesas,ether-r8a7743";
+ reg = <0 0xee700000 0 0x400>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 813>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ phy-mode = "rmii";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
/* External root clock */
^ permalink raw reply
* [PATCH v4 5/7] ARM: dts: r8a7743: add IRQC support
From: Sergei Shtylyov @ 2016-10-21 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2719479.geOc9vqcRS@wasted.cogentembedded.com>
Describe the IRQC interrupt controller in the R8A7743 device tree.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 4:
- refreshed the patch;
- added Geert's tag.
Changes in version 3:
- updated the "clocks" property for the CPG/MSSR driver.
Changes in version 2:
- new patch.
arch/arm/boot/dts/r8a7743.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -62,6 +62,25 @@
IRQ_TYPE_LEVEL_HIGH)>;
};
+ irqc: interrupt-controller at e61c0000 {
+ compatible = "renesas,irqc-r8a7743", "renesas,irqc";
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ reg = <0 0xe61c0000 0 0x200>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 407>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
^ permalink raw reply
* [PATCH v4 6/7] ARM: dts: sk-rzg1m: initial device tree
From: Sergei Shtylyov @ 2016-10-21 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2719479.geOc9vqcRS@wasted.cogentembedded.com>
Add the initial device tree for the R8A7743 SoC based SK-RZG1M board.
The board has one debug serial port (SCIF0); include support for it, so
that the serial console can work.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 4:
- refreshed the patch.
Changes in version 3:
- added Geert's tag.
arch/arm/boot/dts/Makefile | 1
arch/arm/boot/dts/r8a7743-sk-rzg1m.dts | 44 +++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+)
Index: renesas/arch/arm/boot/dts/Makefile
===================================================================
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -677,6 +677,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r7s72100-rskrza1.dtb \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
+ r8a7743-sk-rzg1m.dtb \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for the SK-RZG1M board
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7743.dtsi"
+
+/ {
+ model = "SK-RZG1M";
+ compatible = "renesas,sk-rzg1m", "renesas,r8a7743";
+
+ aliases {
+ serial0 = &scif0;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x40000000>;
+ };
+
+ memory at 200000000 {
+ device_type = "memory";
+ reg = <2 0x00000000 0 0x40000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <20000000>;
+};
+
+&scif0 {
+ status = "okay";
+};
^ permalink raw reply
* [PATCH 5/7] ARM: dts: am335x: Add the charger interrupt
From: Robert Nelson @ 2016-10-21 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021140106.21531-6-woogyom.kim@gmail.com>
On Fri, Oct 21, 2016 at 9:01 AM, Milo Kim <woogyom.kim@gmail.com> wrote:
> This enables the charger driver gets corresponding IRQ number by using
> platform_get_irq_byname() helper.
>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
> ---
> arch/arm/boot/dts/am335x-bone-common.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index 25303d9..cec9d91 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -6,6 +6,8 @@
> * published by the Free Software Foundation.
> */
>
> +#include <dt-bindings/mfd/tps65217.h>
^ this hasn't been posted nor pushed to mainline yet.. ;)
> +
> / {
> cpus {
> cpu at 0 {
> @@ -316,6 +318,12 @@
>
> ti,pmic-shutdown-controller;
>
> + charger {
> + interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
> + interrupts-names = "AC", "USB";
> + status = "okay";
> + };
> +
> regulators {
> dcdc1_reg: regulator at 0 {
> regulator-name = "vdds_dpr";
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Robert Nelson
https://rcn-ee.com/
^ permalink raw reply
* [PATCH v4 7/7] ARM: dts: sk-rzg1m: add Ether support
From: Sergei Shtylyov @ 2016-10-21 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2719479.geOc9vqcRS@wasted.cogentembedded.com>
Define the SK-RZG1M board dependent part of the Ether device node.
Enable DHCP and NFS root for the kernel booting.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 4:
- added Geert's tag.
Changes in version 2:
- new patch.
arch/arm/boot/dts/r8a7743-sk-rzg1m.dts | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -20,7 +20,7 @@
};
chosen {
- bootargs = "ignore_loglevel";
+ bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
stdout-path = "serial0:115200n8";
};
@@ -42,3 +42,16 @@
&scif0 {
status = "okay";
};
+
+ðer {
+ phy-handle = <&phy1>;
+ renesas,ether-link-active-low;
+ status = "okay";
+
+ phy1: ethernet-phy at 1 {
+ reg = <1>;
+ interrupt-parent = <&irqc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ micrel,led-mode = <1>;
+ };
+};
^ permalink raw reply
* [RFC PATCH 09/13] net: phy: Add Meson GXL Internal PHY driver
From: Florian Fainelli @ 2016-10-21 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477060838-14164-10-git-send-email-narmstrong@baylibre.com>
On 10/21/2016 07:40 AM, Neil Armstrong wrote:
> Add driver for the Internal RMII PHY found in the Amlogic Meson GXL SoCs.
>
> This PHY seems to only implement some standard registers and need some
> workarounds to provide autoneg values from vendor registers.
>
> Some magic values are currently used to configure the PHY, and this a
> temporary setup until clarification about these registers names and
> registers fields are provided by Amlogic.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> +
> +static int meson_gxl_config_init(struct phy_device *phydev)
> +{
> + int val;
> + u32 features;
> +
> + meson_gxl_phy_config(phydev);
> +
> + features = SUPPORTED_MII;
This does not really belong in the PHY driver, and this is statically
assigned, I would just drop this.
> +
> + /* Do we support autonegotiation? */
> + val = phy_read(phydev, MII_BMSR);
> + if (val < 0)
> + return val;
> +
> + if (val & BMSR_ANEGCAPABLE)
> + features |= SUPPORTED_Autoneg;
> + if (val & BMSR_100FULL)
> + features |= SUPPORTED_100baseT_Full;
> + if (val & BMSR_100HALF)
> + features |= SUPPORTED_100baseT_Half;
> + if (val & BMSR_10FULL)
> + features |= SUPPORTED_10baseT_Full;
> + if (val & BMSR_10HALF)
> + features |= SUPPORTED_10baseT_Half;
> +
> + phydev->supported = features;
> + phydev->advertising = features;
This is redundant with what PHYLIB will determine for the PHY.
> +
> + return 0;
> +}
> +
> +static int meson_gxl_phy_read_status(struct phy_device *phydev)
> +{
> + int err;
> +
> + /* Update the link, but return if there was an error */
> + err = genphy_update_link(phydev);
> + if (err)
> + return err;
> +
> + phydev->lp_advertising = 0;
> + phydev->pause = 0;
> + phydev->asym_pause = 0;
> +
> + if (phydev->autoneg == AUTONEG_ENABLE) {
> + unsigned int speed;
> + int reg = phy_read(phydev, GXL_REG_ANEG);
Is all of this really necessary? This should all be reflected in the
standard BMSR register, is not this the case here that we have to read
this non-standard register?
You use genphy_config_aneg(), so surely, the standard auto-negotiation
part works somehow?
> +
> + if (reg < 0)
> + return reg;
> +
> + speed = reg & REG_ANEG_SPEED_MASK;
> +
> + if (reg & REG_ANEG_FDUPLEX)
> + phydev->duplex = DUPLEX_FULL;
> + else
> + phydev->duplex = DUPLEX_HALF;
> +
> + if ((reg & REG_ANEG_SPEED_MASK) == REG_ANEG_SPEED10)
> + phydev->speed = SPEED_10;
> + else if ((reg & REG_ANEG_SPEED_MASK) == REG_ANEG_SPEED100)
> + phydev->speed = SPEED_100;
> + } else {
> + int bmcr = phy_read(phydev, MII_BMCR);
> +
> + if (bmcr < 0)
> + return bmcr;
> +
> + if (bmcr & BMCR_FULLDPLX)
> + phydev->duplex = DUPLEX_FULL;
> + else
> + phydev->duplex = DUPLEX_HALF;
> +
> + if (bmcr & BMCR_SPEED1000)
> + phydev->speed = SPEED_1000;
> + else if (bmcr & BMCR_SPEED100)
> + phydev->speed = SPEED_100;
> + else
> + phydev->speed = SPEED_10;
> + }
> +
> + return 0;
> +}
> +
> +static struct phy_driver meson_gxl_phy = {
> + .phy_id = 0x01814400,
> + .name = "Meson GXL Internal PHY",
> + .phy_id_mask = 0x0fffffff,
Usually the last 4 bits are 0, since that's where the revision part is
located.
> + .features = 0,
You should set PHY_GBIT_FEATURES and set .flags to PHY_IS_INTERNAL since
this is an internal PHY?
--
Florian
^ permalink raw reply
* [PATCH 5/7] ARM: dts: am335x: Add the charger interrupt
From: Robert Nelson @ 2016-10-21 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOCHtYgBTq0a1FAMQJb5VoLPWBHYkF3rH_Km6U9u6ep=8ApZuQ@mail.gmail.com>
On Fri, Oct 21, 2016 at 3:47 PM, Robert Nelson <robertcnelson@gmail.com> wrote:
> On Fri, Oct 21, 2016 at 9:01 AM, Milo Kim <woogyom.kim@gmail.com> wrote:
>> This enables the charger driver gets corresponding IRQ number by using
>> platform_get_irq_byname() helper.
>>
>> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
>> ---
>> arch/arm/boot/dts/am335x-bone-common.dtsi | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
>> index 25303d9..cec9d91 100644
>> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
>> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
>> @@ -6,6 +6,8 @@
>> * published by the Free Software Foundation.
>> */
>>
>> +#include <dt-bindings/mfd/tps65217.h>
>
> ^ this hasn't been posted nor pushed to mainline yet.. ;)
So, with this patchset + Keerthy's [RESEND PATCH v8 0/5] mfd:
tps65218: Clean ups:
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1250918.html
and this patch, as systemd is looking for "tps65217_pwr_but"..
https://github.com/systemd/systemd/blob/master/src/login/70-power-switch.rules#L13
Shutdown is working on my BBB/BBG/BBGW/BBBW's...
diff --git a/drivers/input/misc/tps65218-pwrbutton.c
b/drivers/input/misc/tps65218-pwrbutton.c
index cc74a41..f7e5492 100644
--- a/drivers/input/misc/tps65218-pwrbutton.c
+++ b/drivers/input/misc/tps65218-pwrbutton.c
@@ -36,7 +36,7 @@ struct tps6521x_data {
static const struct tps6521x_data tps65217_data = {
.reg_status = TPS65217_REG_STATUS,
.pb_mask = TPS65217_STATUS_PB,
- .name = "tps65217_pwrbutton",
+ .name = "tps65217_pwr_but",
};
static const struct tps6521x_data tps65218_data = {
diff --git a/include/dt-bindings/mfd/tps65217.h
b/include/dt-bindings/mfd/tps65217.h
new file mode 100644
index 0000000..26b2ba8
--- /dev/null
+++ b/include/dt-bindings/mfd/tps65217.h
@@ -0,0 +1,9 @@
+#ifndef __DT_BINDINGS_TPS65217_H
+#define __DT_BINDINGS_TPS65217_H
+
+#define TPS65217_IRQ_USB 0
+#define TPS65217_IRQ_AC 1
+#define TPS65217_IRQ_PB 2
+#define TPS65217_NUM_IRQ 3
+
+#endif /* __DT_BINDINGS_TPS65217_H */
Regards,
--
Robert Nelson
https://rcn-ee.com/
^ permalink raw reply related
* [PATCH] Documentation: DMA-API: Clarify semantics of dma_set_mask_and_coherent
From: Jonathan Corbet @ 2016-10-21 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017152623.7649-1-punit.agrawal@arm.com>
On Mon, 17 Oct 2016 16:26:23 +0100
Punit Agrawal <punit.agrawal@arm.com> wrote:
> The dma mapping api howto gives the impression that using the
> dma_set_mask_and_coherent (and related DMA APIs) will cause the kernel
> to check all the components in the path from the device to memory for
> addressing restrictions. In systems with address translations between
> the device and memory (e.g., when using IOMMU), this implies that a
> successful call to set set dma mask has checked the addressing
> constraints of the intermediaries as well.
>
> For the IOMMU drivers in the tree, the check is actually performed while
> allocating the DMA buffer rather than when the DMA mask is
> configured. For MMUs that do not support the full device addressing
> capability, the allocations are made from a reduced address space.
>
> Update the documentation to clarify that even though the call to
> dma_set_mask_and_coherent succeeds, it may not be possible to use the
> full addressing capability of the device.
OK, so I guess I can buy this. But...
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> ---
> Documentation/DMA-API-HOWTO.txt | 39 +++++++++++++++++++++++----------------
> 1 file changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
> index 979228b..240d1ee 100644
> --- a/Documentation/DMA-API-HOWTO.txt
> +++ b/Documentation/DMA-API-HOWTO.txt
> @@ -159,39 +159,46 @@ support 64-bit addressing (DAC) for all transactions. And at least
> one platform (SGI SN2) requires 64-bit consistent allocations to
> operate correctly when the IO bus is in PCI-X mode.
>
> -For correct operation, you must interrogate the kernel in your device
> -probe routine to see if the DMA controller on the machine can properly
> -support the DMA addressing limitation your device has. It is good
> +For correct operation, you must inform the kernel in your device probe
> +routine to see if the DMA controller on the machine can properly
> +support the DMA addressing capabilities your device has. It is good
Here it's still saying "to see if the DMA controller on the machine can
properly support the DMA addressing capabilities your device has". So
you've not really changed the sense of this sentence here.
If I understand things correctly, the calls in question are storing the
device's limitations; they will only fail if the kernel is entirely
unable to work within the indicated range, right? I don't think there's
ever been any guarantee that the system as a whole could use the entire
range that is addressable by the device. I have no objection to making
that more clear, but let's actually make it more clear by saying what the
functions are actually doing.
Make sense, or am I missing something here?
Thanks,
jon
^ permalink raw reply
* [PATCH v2 3/4] arm64: dts: msm8996: Add SMEM DT nodes
From: Sarangdhar Joshi @ 2016-10-21 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021000408.GI26139@codeaurora.org>
On 10/20/2016 05:04 PM, Stephen Boyd wrote:
> On 10/20, Sarangdhar Joshi wrote:
>> From: Bjorn Andersson <bjorn.andersson@linaro.org>
>>
>> Add SMEM and TCSR DT nodes on MSM8996.
>>
>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
>> ---
>> arch/arm64/boot/dts/qcom/msm8996.dtsi | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> index 949b096..abc1089 100644
>> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> @@ -164,17 +164,36 @@
>>
>> };
>>
>> + tcsr_mutex: hwlock {
>> + compatible = "qcom,tcsr-mutex";
>> + syscon = <&tcsr_mutex_regs 0 0x1000>;
>> + #hwlock-cells = <1>;
>> + };
>> +
>> psci {
>> compatible = "arm,psci-1.0";
>> method = "smc";
>> };
>>
>> + smem {
>> + compatible = "qcom,smem";
>> +
>> + memory-region = <&smem_mem>;
>> +
>> + hwlocks = <&tcsr_mutex 3>;
>
> Super nitpick: Is there a reason we have newlines between
> everything in this node? This node is the only one that isn't
> consistent.
Thanks, will do that. I think I just missed updating this node from
original patchset.
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH/RFC 4/4] soc: renesas: Identify SoC and register with the SoC bus
From: Arnd Bergmann @ 2016-10-21 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVv+K=NVpmn-H72m159sDXnsAydMT-FQHq1is67_Nw3mQ@mail.gmail.com>
On Friday, October 21, 2016 8:16:00 PM CEST Geert Uytterhoeven wrote:
> On Wed, Oct 19, 2016 at 12:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday, October 19, 2016 10:02:57 AM CEST Geert Uytterhoeven wrote:
> >> On Mon, Oct 10, 2016 at 4:23 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > I'd prefer seeing a separate soc driver for that one.
> >> Some SoCs have only CCCR, others have only PRR, some have both.
> >> On some SoCs one of them can be accessed from the RealTime CPU
> >> core (SH) only.
> >> On some SoCs the register is not documented, but present.
> >> If the PRR exists, it's a better choice, as it contains additional information
> >> in the high order bits (representing the presence of each big (CA15/CA57),
> >> little (CA7/CA53), and RT (CR7) CPU core). Currently we don't use that
> >> information, though.
> >>
> >> Grouping them in some other way means we would loose the family name,
> >> which is exposed through soc_dev_attr->family.
> >> The usefulness of family names is debatable though, as this is more an
> >> issue of marketing business.
> >
> > How about having a table to look up the family name by the value
> > of the PRR or CCCR then?
>
> Unfortunately there exist SoCs from different families using the same
> product ID.
>
> And different SoCs from the same family may have a revision register
> or not (e.g. R-Car H1 has, M1A hasn't).
Is this something we expect to see more of in the future, or can
we expect future chips to handle this more consistently?
> > How about this:
> >
> > The driver could report the hardcoded strings for the SoCs it already
> > knows about (you have the table anyway) and not report the revision
> > unless there is a regmap containing the CCCR or the PRR, in which
> > case you use that. Future SoCs will provide the PRR (I assume
> > CCCR is only used on the older ones) through a syscon regmap
> > that we can use to find out the exact revision as well.
> >
> > The existing DT files can gain the syscon device so you can report
> > the revision on those machines as well, unless you use an old DTB.
>
> Hmm... That means that if we have to add a driver quirk to distinguish
> between different revisions of the same SoC, we have to update the
> DTB anyway, to add the CCCR/PRR device node.
> We might as well just change the compatible value in that DTB for the
> device that needs the quirk. Which is what we'd like to avoid in the
> first place.
Do you have a specific example in mind? If this is only a theoretical
problem, we can worry about it when we get there, and then decide
if we add a hardcoded register after all.
> > Why not just drop all the #ifdef here? There should be very little
> > overhead in size, especially if all the data is __initconst.
>
> It still saves ca. 3 KiB for a kernel for a single SoC.
Fair enough, that is more than I was expecting from looking at the
source. It's probably the of_device_id structures for the most part.
Please just add the __maybe_unused then, to save us a patch in case
we make -Wunused-const the default in the future.
Arnd
^ permalink raw reply
* [PATCH v1 1/2] include: dt-bindings: Add GPIO pin index definition for rockchip pinctrl
From: Heiko Stuebner @ 2016-10-21 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13068948.jkWM1OvpR7@phil>
Am Mittwoch, 12. Oktober 2016, 00:00:12 CEST schrieb Heiko Stuebner:
> Am Mittwoch, 7. September 2016, 09:00:53 CEST schrieb Andy Yan:
> > Add gpio pin index definition to make it easier to describe
> > GPIO in dts.
> >
> > Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
>
> just as a heads up, as I didn't respond yet:
>
> Looks good and I'll take them, I just want to wait for the merge-window to
> close (should be the coming sunday), to be able to put the header change in
> a shared branch for the case that other users appear during the 4.10 cycle.
I've now applied both patches for 4.10
Thanks
Heiko
^ permalink raw reply
* [PATCH v3 3/6] pwm: imx: support output polarity inversion
From: Lukasz Majewski @ 2016-10-21 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b72dcbc9a021e6fa3aef62f63bbf93f@agner.ch>
Hi Stefan,
> On 2016-10-20 01:30, Lukasz Majewski wrote:
> > Hi Stefan,
> >
> >> Hi Stefan,
> >>
> >> > On 2016-10-12 15:15, Lukasz Majewski wrote:
> >> > > Hi Stefan,
> >> > >
> >> > >> On 2016-10-07 08:11, Bhuvanchandra DV wrote:
> >> > >> > From: Lothar Wassmann <LW@KARO-electronics.de>
> >> > >> >
> >> > >> > The i.MX pwm unit on i.MX27 and newer SoCs provides a
> >> > >> > configurable output polarity. This patch adds support to
> >> > >> > utilize this feature where available.
> >> > >> >
> >> > >> > Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
> >> > >> > Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
> >> > >> > Signed-off-by: Bhuvanchandra DV
> >> > >> > <bhuvanchandra.dv@toradex.com> Acked-by: Shawn Guo
> >> > >> > <shawn.guo@linaro.org> Reviewed-by: Sascha Hauer
> >> > >> > <s.hauer@pengutronix.de> ---
> >> > >> > Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +--
> >> > >> > drivers/pwm/pwm-imx.c | 51
> >> > >> > +++++++++++++++++++++-- 2 files changed, 51 insertions(+), 6
> >> > >> > deletions(-)
> >> > >> >
> >> > >> > diff --git
> >> > >> > a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> >> > >> > b/Documentation/devicetree/bindings/pwm/imx-pwm.txt index
> >> > >> > e00c2e9..c61bdf8 100644 ---
> >> > >> > a/Documentation/devicetree/bindings/pwm/imx-pwm.txt +++
> >> > >> > b/Documentation/devicetree/bindings/pwm/imx-pwm.txt @@ -6,8
> >> > >> > +6,8 @@ Required properties:
> >> > >> > - "fsl,imx1-pwm" for PWM compatible with the one
> >> > >> > integrated on i.MX1
> >> > >> > - "fsl,imx27-pwm" for PWM compatible with the one
> >> > >> > integrated on i.MX27
> >> > >> > - reg: physical base address and length of the controller's
> >> > >> > registers -- #pwm-cells: should be 2. See pwm.txt in this
> >> > >> > directory for a description of
> >> > >> > - the cells format.
> >> > >> > +- #pwm-cells: 2 for i.MX1 and 3 for i.MX27 and newer SoCs.
> >> > >> > See pwm.txt
> >> > >> > + in this directory for a description of the cells format.
> >> > >> > - clocks : Clock specifiers for both ipg and per clocks.
> >> > >> > - clock-names : Clock names should include both "ipg" and
> >> > >> > "per" See the clock consumer binding,
> >> > >> > @@ -17,7 +17,7 @@ See the clock consumer binding,
> >> > >> > Example:
> >> > >> >
> >> > >> > pwm1: pwm at 53fb4000 {
> >> > >> > - #pwm-cells = <2>;
> >> > >> > + #pwm-cells = <3>;
> >> > >> > compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
> >> > >> > reg = <0x53fb4000 0x4000>;
> >> > >> > clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>,
> >> > >> > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> >> > >> > index d600fd5..c37d223 100644
> >> > >> > --- a/drivers/pwm/pwm-imx.c
> >> > >> > +++ b/drivers/pwm/pwm-imx.c
> >> > >> > @@ -38,6 +38,7 @@
> >> > >> > #define MX3_PWMCR_DOZEEN (1 << 24)
> >> > >> > #define MX3_PWMCR_WAITEN (1 << 23)
> >> > >> > #define MX3_PWMCR_DBGEN (1 << 22)
> >> > >> > +#define MX3_PWMCR_POUTC (1 << 18)
> >> > >> > #define MX3_PWMCR_CLKSRC_IPG_HIGH (2 << 16)
> >> > >> > #define MX3_PWMCR_CLKSRC_IPG (1 << 16)
> >> > >> > #define MX3_PWMCR_SWR (1 << 3)
> >> > >> > @@ -180,6 +181,9 @@ static int imx_pwm_config_v2(struct
> >> > >> > pwm_chip *chip, if (enable)
> >> > >> > cr |= MX3_PWMCR_EN;
> >> > >> >
> >> > >> > + if (pwm->args.polarity == PWM_POLARITY_INVERSED)
> >> > >> > + cr |= MX3_PWMCR_POUTC;
> >> > >> > +
> >> > >>
> >> > >> This seems wrong to me, the config callback is meant for
> >> > >> period/duty cycle only.
> >
> > Unfortunately, it also resets the PWM IP block and setups it again
> > (by writing to PWMCR register). In that function we setup for
> > example MX3_PWMCR_DOZEEN
> > and MX3_PWMCR_DBGEN. Why cannot we setup polarity as well?
> >
> >
> > I've double checked the backlight and pwm code flow.
> >
> > Please find following snippet:
> >
> > [ 0.135545] ######### imx_pwm_probe
> > [ 0.135581] PWM supports output inversion
> > [ 0.136864] ######### pwm_backlight_probe
> > [ 0.136913] backlight supply power not found, using dummy
> > regulator [ 0.136984] ######### imx_pwm_set_polarity 1
> > [ 0.136995] imx_pwm_set_polarity: polarity set to inverted cr:
> > 0x40000 0xf08f8000
> > [ 0.137005] #########0 imx_pwm_config_v2 cr: 0x40000
> > [ 0.137683] #########1 imx_pwm_config_v2 cr: 0x0 0xf08f8000
> > [ 0.137693] #########2 imx_pwm_config_v2 cr: 0x1c20050
> > [ 0.137702] #########3 imx_pwm_config_v2 cr: 0x1c20050 0xf08f8000
> > [ 0.137711] @@@@@@@@@@ pwm_apply_state
Maybe a bit more logs:
[ 0.135451] ######### imx_pwm_probe
[ 0.135488] PWM supports output inversion
[ 0.136777] ######### pwm_backlight_probe
[ 0.136826] backlight supply power not found, using dummy regulator
[ 0.136893] ********* pwm_apply_state state->enabled: 0
[ 0.136902] ######### imx_pwm_set_polarity 1
[ 0.136913] imx_pwm_set_polarity: polarity set to inverted cr: 0x40000 0xf08f8000
[ 0.136923] #########0 imx_pwm_config_v2 cr: 0x40000
[ 0.137692] #########1 imx_pwm_config_v2 cr: 0x0 0xf08f8000
[ 0.137701] #########2 imx_pwm_config_v2 cr: 0x1c20050
[ 0.137710] #########3 imx_pwm_config_v2 cr: 0x1c20050 0xf08f8000
[ 0.137720] @@@@@@@@@@ pwm_apply_state
[ 0.137856] ********* pwm_apply_state state->enabled: 0
[ 0.137869] #########0 imx_pwm_config_v2 cr: 0x1c20050
[ 0.138904] #########1 imx_pwm_config_v2 cr: 0x0 0xf08f8000
[ 0.138913] #########2 imx_pwm_config_v2 cr: 0x1c20050
[ 0.138921] #########3 imx_pwm_config_v2 cr: 0x1c20050 0xf08f8000
[ 0.138928] @@@@@@@@@@ pwm_apply_state
[ 0.138940] ********* pwm_apply_state state->enabled: 1
^^^^^^^^^^^^^^^^^^ this is called from
pwm_backlight_power_on() from pwm_bl probe function
The problem here is not the lack of ->apply() callback, but the requirement to
perform software reset on the pwm_v2 fifo when the pwm_v2 is NOT enabled (state->enabled: 0).
As fair as I can see the pwm_state has following members: period, duty cycle, polarity and enabled.
I'm fine to implement ->apply() callback, which would change above values.
However, there is a problem with ->config() (imx_pwm_config_v2 @ pwm-imx.c) and imx pwm_v2 software
FIFO reset.
We can set polarity in any other kernel subsystem, which uses PWM (backlight in this example) and
then this setting would disappear when we call pwm_apply_state with state->enabled = 0 (as presented
in the log). This imposes setting polarity at ->config when we enable the PWM (as this patch does).
> >
> > Here the pwm_backlight_probe calls set_polarity callback available
> > in pwm - the polarity is set (the 0x40000 value).
> >
> > The above operation is performed in pwm_apply_state (@
> > drivers/pwm/core.c). In the same function, latter we call the
> > pwm->chip->ops->config(), which is the pointer to config_v2.
> > Since the PWM is not yet enabled, this function performs SW reset
> > and PWM inversion setting is cleared.
>
> That function should not do that.
I do agree that it shouldn't. Correct me if I'm wrong, but it seems like an
PWM HW requirement to perform the reset.
>It was probably already problematic
> in the old times, it is definitely now with the atomic PWM stuff.
The "atomic"[*] code (with ->apply() provided) will not solve this issue.
>
> >
> > Possible solutions:
> >
> > 1. Leave the original patch from Bhuvanchandra as it was (I'm for
> > this option)
>
> That really seems like a hack to me, and makes transition to the
> atomic PWM API more complex.
Could you be more specific here?
As I mentioned before, the problem is not with the lack of
"atomic" API.
For me the problem is with other subsystems (like pwm backlight)
which do require polarity inversion to work properly.
>
> If we can't make it happen properly in the current state of affairs,
We can set polarity properly with this patch. The only thing which needs fixing
and another revision of the patch) is the removal of condition:
- if (polarity == pwm->args.polarity)
- return 0;
at imx_pwm_set_polarity() function.
> we probably should first move to the atomic API.
>
> It really should not be that hard, since we already do almost
> everything in one function (imx_pwm_config_v2). We probably can
> almost just assign that function to the new apply function pointer
> and read information from the new state struct.
We do need to configure polarity according to DT value during the pwm
config_v2 configuration after PWM IP software reset.
>
> There are examples for instance here:
> https://patchwork.kernel.org/patch/7228221/
The atomicity[*]:
- It seems to me that this "atomicity" is just embracing all the ->enable, ->disable
and ->set_polarity in one -> apply callback. Is this just conceptual clean up or is
there any other reason for it (I'm just curious) ?
Best regards,
?ukasz Majewski
>
> --
> Stefan
>
> >
> > 2. Enable early PWM (in core, or in bl driver) so the config_v2 is
> > not calling SW reset on the PWM. (but this solutions seems _really_
> > bad to me)
> >
> > 3. Perform defer probe of pwm backlight driver (pwm_bl.c) until the
> > pwm is fully configured (it might be a bit tricky).
> >
> >
> > Best regards,
> > ?ukasz Majewski
> >
> >> > >
> >> > > If it is meant only for that, then the polarity should be
> >> > > removed from it.
> >> > >
> >> > > However after very quick testing, at least on my setup, it
> >> > > turns out that removing this lines causes polarity to _not_
> >> > > being set (and the polarity is not inverted).
> >> > >
> >> > > I will investigate this further on my setup and hopefully sent
> >> > > proper patch.
> >> > >
> >> > >> The set_polarity callback should get called in case a
> >> > >> different polarity is requested.
> >> > >
> >> > > On my setup the pwm2 is set from DT and pwm_backlight_probe()
> >> > > calls pwm_apply_args(), so everything should work. However, as
> >> > > I mentioned above there still is some problem with inversion
> >> > > setting.
> >> > >
> >> > >>
> >> > >>
> >> > >> > writel(cr, imx->mmio_base + MX3_PWMCR);
> >> > >> >
> >> > >> > return 0;
> >> > >> > @@ -240,27 +244,62 @@ static void imx_pwm_disable(struct
> >> > >> > pwm_chip *chip, struct pwm_device *pwm)
> >> > >> > clk_disable_unprepare(imx->clk_per);
> >> > >> > }
> >> > >> >
> >> > >> > -static struct pwm_ops imx_pwm_ops = {
> >> > >> > +static int imx_pwm_set_polarity(struct pwm_chip *chip,
> >> > >> > struct pwm_device *pwm,
> >> > >> > + enum pwm_polarity polarity)
> >> > >> > +{
> >> > >> > + struct imx_chip *imx = to_imx_chip(chip);
> >> > >> > + u32 val;
> >> > >> > +
> >> > >> > + if (polarity == pwm->args.polarity)
> >> > >> > + return 0;
> >> > >>
> >> > >> I don't think that this is right. Today, pwm_apply_args (in
> >> > >> include/linux/pwm.h) copies the polarity from args to
> >> > >> state.polarity, which is then passed as polarity argument to
> >> > >> this function. So this will always return 0 afaict.
> >> > >
> >> > > Yes, I've overlooked it (that the state is copied).
> >> > >
> >> > > It can be dropped.
> >> >
> >> > Did you do the above test with that line dropped?
> >>
> >> Yes. The above code has been also removed.
> >>
> >> Best regards,
> >> ?ukasz Majewski
> >>
> >> >
> >> > >
> >> > >>
> >> > >> I would just drop that.
> >> > >>
> >> > >> There is probably one little problem in the current state of
> >> > >> affairs: If the bootloader makes use of a PWM channel with
> >> > >> inverted state, then the kernel would not know about that and
> >> > >> currently assume a wrong initial state... I guess at one
> >> > >> point in time we should implement the state retrieval
> >> > >> callback and move to the new atomic PWM API, which would mean
> >> > >> to implement apply callback.
> >> > >
> >> > > Are there any patches on the horizon?
> >> > >
> >> >
> >> > Not that I know of...
> >> >
> >> > --
> >> > Stefan
> >> >
> >> > >>
> >> > >> --
> >> > >> Stefan
> >> > >>
> >> > >>
> >> > >> > +
> >> > >> > + val = readl(imx->mmio_base + MX3_PWMCR);
> >> > >> > +
> >> > >> > + if (polarity == PWM_POLARITY_INVERSED)
> >> > >> > + val |= MX3_PWMCR_POUTC;
> >> > >> > + else
> >> > >> > + val &= ~MX3_PWMCR_POUTC;
> >> > >> > +
> >> > >> > + writel(val, imx->mmio_base + MX3_PWMCR);
> >> > >> > +
> >> > >> > + dev_dbg(imx->chip.dev, "%s: polarity set to %s\n",
> >> > >> > __func__,
> >> > >> > + polarity == PWM_POLARITY_INVERSED ?
> >> > >> > "inverted" : "normal"); +
> >> > >> > + return 0;
> >> > >> > +}
> >> > >> > +
> >> > >> > +static struct pwm_ops imx_pwm_ops_v1 = {
> >> > >> > .enable = imx_pwm_enable,
> >> > >> > .disable = imx_pwm_disable,
> >> > >> > .config = imx_pwm_config,
> >> > >> > .owner = THIS_MODULE,
> >> > >> > };
> >> > >> >
> >> > >> > +static struct pwm_ops imx_pwm_ops_v2 = {
> >> > >> > + .enable = imx_pwm_enable,
> >> > >> > + .disable = imx_pwm_disable,
> >> > >> > + .set_polarity = imx_pwm_set_polarity,
> >> > >> > + .config = imx_pwm_config,
> >> > >> > + .owner = THIS_MODULE,
> >> > >> > +};
> >> > >> > +
> >> > >> > struct imx_pwm_data {
> >> > >> > int (*config)(struct pwm_chip *chip,
> >> > >> > struct pwm_device *pwm, int duty_ns, int
> >> > >> > period_ns); void (*set_enable)(struct pwm_chip *chip, bool
> >> > >> > enable);
> >> > >> > + struct pwm_ops *pwm_ops;
> >> > >> > };
> >> > >> >
> >> > >> > static struct imx_pwm_data imx_pwm_data_v1 = {
> >> > >> > .config = imx_pwm_config_v1,
> >> > >> > .set_enable = imx_pwm_set_enable_v1,
> >> > >> > + .pwm_ops = &imx_pwm_ops_v1,
> >> > >> > };
> >> > >> >
> >> > >> > static struct imx_pwm_data imx_pwm_data_v2 = {
> >> > >> > .config = imx_pwm_config_v2,
> >> > >> > .set_enable = imx_pwm_set_enable_v2,
> >> > >> > + .pwm_ops = &imx_pwm_ops_v2,
> >> > >> > };
> >> > >> >
> >> > >> > static const struct of_device_id imx_pwm_dt_ids[] = {
> >> > >> > @@ -282,6 +321,8 @@ static int imx_pwm_probe(struct
> >> > >> > platform_device *pdev) if (!of_id)
> >> > >> > return -ENODEV;
> >> > >> >
> >> > >> > + data = of_id->data;
> >> > >> > +
> >> > >> > imx = devm_kzalloc(&pdev->dev, sizeof(*imx),
> >> > >> > GFP_KERNEL); if (imx == NULL)
> >> > >> > return -ENOMEM;
> >> > >> > @@ -300,18 +341,22 @@ static int imx_pwm_probe(struct
> >> > >> > platform_device *pdev) return PTR_ERR(imx->clk_ipg);
> >> > >> > }
> >> > >> >
> >> > >> > - imx->chip.ops = &imx_pwm_ops;
> >> > >> > + imx->chip.ops = data->pwm_ops;
> >> > >> > imx->chip.dev = &pdev->dev;
> >> > >> > imx->chip.base = -1;
> >> > >> > imx->chip.npwm = 1;
> >> > >> > imx->chip.can_sleep = true;
> >> > >> > + if (data->pwm_ops->set_polarity) {
> >> > >> > + dev_dbg(&pdev->dev, "PWM supports output
> >> > >> > inversion\n");
> >> > >> > + imx->chip.of_xlate =
> >> > >> > of_pwm_xlate_with_flags;
> >> > >> > + imx->chip.of_pwm_n_cells = 3;
> >> > >> > + }
> >> > >> >
> >> > >> > r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> > >> > imx->mmio_base = devm_ioremap_resource(&pdev->dev,
> >> > >> > r); if (IS_ERR(imx->mmio_base))
> >> > >> > return PTR_ERR(imx->mmio_base);
> >> > >> >
> >> > >> > - data = of_id->data;
> >> > >> > imx->config = data->config;
> >> > >> > imx->set_enable = data->set_enable;
> >> > >>
> >> > >
> >> > > Best regards,
> >> > >
> >> > > ?ukasz Majewski
> >>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161021/7c7c9f4d/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/2] pinctrl: pm8994: add pad voltage regulator defines
From: Andy Gross @ 2016-10-21 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZYYawHAOyu09vVxkTFQdrPmHsX28C7sjrWQ57MzfR4JQ@mail.gmail.com>
On Sun, Sep 18, 2016 at 01:38:30PM +0200, Linus Walleij wrote:
> On Fri, Sep 16, 2016 at 7:41 PM, Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
>
> > This patch adds defines for internal voltage regulators used
> > to switch voltage levels on gpio/mpp pads.
> >
> > Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Andy can merge this with the rest of the stuff to the Qualcomm SoC tree.
Yup. Picked it up. Thanks!
Andy
^ permalink raw reply
* [PATCH v3 [fix]] PM / doc: Update device documentation for devices in IRQ safe PM domains
From: Lina Iyer @ 2016-10-21 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021152313.GC72940@linaro.org>
Update documentation to reflect the changes made to support IRQ safe PM
domains.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Changes since v3:
- Moved para to the end of the section
- Added clause for all IRQ safe devices in a domain
- Cleanup explanation of nested domains
---
Documentation/power/devices.txt | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 8ba6625..9218ce6 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -607,7 +607,9 @@ individually. Instead, a set of devices sharing a power resource can be put
into a low-power state together at the same time by turning off the shared
power resource. Of course, they also need to be put into the full-power state
together, by turning the shared power resource on. A set of devices with this
-property is often referred to as a power domain.
+property is often referred to as a power domain. A power domain may also be
+nested inside another power domain. The nested domain is referred to as the
+sub-domain of the parent domain.
Support for power domains is provided through the pm_domain field of struct
device. This field is a pointer to an object of type struct dev_pm_domain,
@@ -629,6 +631,13 @@ support for power domains into subsystem-level callbacks, for example by
modifying the platform bus type. Other platforms need not implement it or take
it into account in any way.
+Devices and PM domains may be defined as IRQ-safe, if they can be powered
+on/off even when the IRQs are disabled. An IRQ-safe device in a domain will
+disallow power management on the domain, unless the domain is also defined as
+IRQ-safe. In other words, a domain containing all IRQ-safe devices must also
+be defined as IRQ-safe. Another restriction this framework imposes on the
+parent domain of an IRQ-safe domain is that the parent domain must also be
+defined as IRQ-safe.
Device Low Power (suspend) States
---------------------------------
--
2.7.4
^ permalink raw reply related
* [PATCH v4 4/9] clk: sunxi-ng: Add minimums for all the relevant structures and clocks
From: André Przywara @ 2016-10-21 22:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a96b56fb7bda849e087b63a04ff76d1396c44d72.1476196031.git-series.maxime.ripard@free-electrons.com>
Salut,
On 11/10/16 15:28, Maxime Ripard wrote:
> Modify the current clocks we have to be able to specify the minimum for
> each clocks we support, just like we support the max.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/clk/sunxi-ng/ccu_mult.c | 7 ++++++-
> drivers/clk/sunxi-ng/ccu_nk.c | 12 ++++++++----
> drivers/clk/sunxi-ng/ccu_nkm.c | 18 ++++++++++++------
> drivers/clk/sunxi-ng/ccu_nkmp.c | 16 ++++++++++++----
> drivers/clk/sunxi-ng/ccu_nm.c | 12 ++++++++----
> 5 files changed, 46 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mult.c b/drivers/clk/sunxi-ng/ccu_mult.c
> index 32a1964439a2..6a02ffee5386 100644
> --- a/drivers/clk/sunxi-ng/ccu_mult.c
> +++ b/drivers/clk/sunxi-ng/ccu_mult.c
> @@ -14,7 +14,7 @@
> #include "ccu_mult.h"
>
> struct _ccu_mult {
> - unsigned long mult, max;
> + unsigned long mult, min, max;
> };
>
> static void ccu_mult_find_best(unsigned long parent, unsigned long rate,
> @@ -23,6 +23,9 @@ static void ccu_mult_find_best(unsigned long parent, unsigned long rate,
> int _mult;
>
> _mult = rate / parent;
> + if (_mult < mult->min)
> + _mult = mult->min;
> +
> if (_mult > mult->max)
> _mult = mult->max;
>
> @@ -37,6 +40,7 @@ static unsigned long ccu_mult_round_rate(struct ccu_mux_internal *mux,
> struct ccu_mult *cm = data;
> struct _ccu_mult _cm;
>
> + _cm.min = 1;
> _cm.max = 1 << cm->mult.width;
> ccu_mult_find_best(parent_rate, rate, &_cm);
>
> @@ -101,6 +105,7 @@ static int ccu_mult_set_rate(struct clk_hw *hw, unsigned long rate,
> ccu_mux_helper_adjust_parent_for_prediv(&cm->common, &cm->mux, -1,
> &parent_rate);
>
> + _cm.min = 1;
> _cm.max = 1 << cm->mult.width;
> ccu_mult_find_best(parent_rate, rate, &_cm);
>
> diff --git a/drivers/clk/sunxi-ng/ccu_nk.c b/drivers/clk/sunxi-ng/ccu_nk.c
> index e7e2e75618ef..a42d870ba0ef 100644
> --- a/drivers/clk/sunxi-ng/ccu_nk.c
> +++ b/drivers/clk/sunxi-ng/ccu_nk.c
> @@ -14,8 +14,8 @@
> #include "ccu_nk.h"
>
> struct _ccu_nk {
> - unsigned long n, max_n;
> - unsigned long k, max_k;
> + unsigned long n, min_n, max_n;
> + unsigned long k, min_k, max_k;
> };
>
> static void ccu_nk_find_best(unsigned long parent, unsigned long rate,
> @@ -25,8 +25,8 @@ static void ccu_nk_find_best(unsigned long parent, unsigned long rate,
> unsigned int best_k = 0, best_n = 0;
> unsigned int _k, _n;
>
> - for (_k = 1; _k <= nk->max_k; _k++) {
> - for (_n = 1; _n <= nk->max_n; _n++) {
> + for (_k = nk->min_k; _k <= nk->max_k; _k++) {
> + for (_n = nk->min_n; _n <= nk->max_n; _n++) {
> unsigned long tmp_rate = parent * _n * _k;
>
> if (tmp_rate > rate)
> @@ -97,7 +97,9 @@ static long ccu_nk_round_rate(struct clk_hw *hw, unsigned long rate,
> if (nk->common.features & CCU_FEATURE_FIXED_POSTDIV)
> rate *= nk->fixed_post_div;
>
> + _nk.min_n = 1;
> _nk.max_n = 1 << nk->n.width;
> + _nk.min_k = 1;
> _nk.max_k = 1 << nk->k.width;
>
> ccu_nk_find_best(*parent_rate, rate, &_nk);
> @@ -120,7 +122,9 @@ static int ccu_nk_set_rate(struct clk_hw *hw, unsigned long rate,
> if (nk->common.features & CCU_FEATURE_FIXED_POSTDIV)
> rate = rate * nk->fixed_post_div;
>
> + _nk.min_n = 1;
> _nk.max_n = 1 << nk->n.width;
> + _nk.min_k = 1;
> _nk.max_k = 1 << nk->k.width;
>
> ccu_nk_find_best(parent_rate, rate, &_nk);
> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> index 0b08d000eb38..b2a5fccf2f8c 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> @@ -14,9 +14,9 @@
> #include "ccu_nkm.h"
>
> struct _ccu_nkm {
> - unsigned long n, max_n;
> - unsigned long k, max_k;
> - unsigned long m, max_m;
> + unsigned long n, min_n, max_n;
> + unsigned long k, min_k, max_k;
> + unsigned long m, min_m, max_m;
> };
>
> static void ccu_nkm_find_best(unsigned long parent, unsigned long rate,
> @@ -26,9 +26,9 @@ static void ccu_nkm_find_best(unsigned long parent, unsigned long rate,
> unsigned long best_n = 0, best_k = 0, best_m = 0;
> unsigned long _n, _k, _m;
>
> - for (_k = 1; _k <= nkm->max_k; _k++) {
> - for (_n = 1; _n <= nkm->max_n; _n++) {
> - for (_m = 1; _n <= nkm->max_m; _m++) {
> + for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
> + for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
> + for (_m = nkm->min_m; _n <= nkm->max_m; _m++) {
should be _m in the condition
> unsigned long tmp_rate;
>
> tmp_rate = parent * _n * _k / _m;
> @@ -100,8 +100,11 @@ static unsigned long ccu_nkm_round_rate(struct ccu_mux_internal *mux,
> struct ccu_nkm *nkm = data;
> struct _ccu_nkm _nkm;
>
> + _nkm.min_n = 1;
> _nkm.max_n = 1 << nkm->n.width;
> + _nkm.min_k = 1;
> _nkm.max_k = 1 << nkm->k.width;
> + _nkm.min_m = 1;
> _nkm.max_m = nkm->m.max ?: 1 << nkm->m.width;
>
> ccu_nkm_find_best(parent_rate, rate, &_nkm);
> @@ -126,8 +129,11 @@ static int ccu_nkm_set_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long flags;
> u32 reg;
>
> + _nkm.min_n = 1;
> _nkm.max_n = 1 << nkm->n.width;
> + _nkm.min_k = 1;
> _nkm.max_k = 1 << nkm->k.width;
> + _nkm.min_m = 1;
> _nkm.max_m = nkm->m.max ?: 1 << nkm->m.width;
>
> ccu_nkm_find_best(parent_rate, rate, &_nkm);
> diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
> index 4b457d8cce11..2c1398192e48 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> @@ -27,10 +27,10 @@ static void ccu_nkmp_find_best(unsigned long parent, unsigned long rate,
> unsigned long best_n = 0, best_k = 0, best_m = 0, best_p = 0;
> unsigned long _n, _k, _m, _p;
>
> - for (_k = 1; _k <= nkmp->max_k; _k++) {
> - for (_n = 1; _n <= nkm->max_n; _n++) {
> - for (_m = 1; _n <= nkm->max_m; _m++) {
> - for (_p = 1; _p <= nkmp->max_p; _p <<= 1) {
> + for (_k = nkmp->min_k; _k <= nkmp->max_k; _k++) {
> + for (_n = nkmp->min_n; _n <= nkmp->max_n; _n++) {
> + for (_m = nkmp->min_m; _n <= nkmp->max_m; _m++) {
Same here: _m <= ...
> + for (_p = nkmp->min_p; _p <= nkmp->max_p; _p <<= 1) {
> unsigned long tmp_rate;
>
> tmp_rate = parent * _n * _k / (_m * _p);
> @@ -107,9 +107,13 @@ static long ccu_nkmp_round_rate(struct clk_hw *hw, unsigned long rate,
> struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> struct _ccu_nkmp _nkmp;
>
> + _nkmp.min_n = 1;
> _nkmp.max_n = 1 << nkmp->n.width;
> + _nkmp.min_k = 1;
> _nkmp.max_k = 1 << nkmp->k.width;
> + _nkmp.min_m = 1;
> _nkmp.max_m = nkmp->m.max ?: 1 << nkmp->m.width;
> + _nkmp.min_p = 1;
> _nkmp.max_p = nkmp->p.max ?: 1 << ((1 << nkmp->p.width) - 1);
>
> ccu_nkmp_find_best(*parent_rate, rate, &_nkmp);
> @@ -125,9 +129,13 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long flags;
> u32 reg;
>
> + _nkmp.min_n = 1;
> _nkmp.max_n = 1 << nkmp->n.width;
> + _nkmp.min_k = 1;
> _nkmp.max_k = 1 << nkmp->k.width;
> + _nkmp.min_m = 1;
> _nkmp.max_m = nkmp->m.max ?: 1 << nkmp->m.width;
> + _nkmp.min_p = 1;
> _nkmp.max_p = nkmp->p.max ?: 1 << ((1 << nkmp->p.width) - 1);
>
> ccu_nkmp_find_best(parent_rate, rate, &_nkmp);
> diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
> index c6d652289320..2a190bc032a9 100644
> --- a/drivers/clk/sunxi-ng/ccu_nm.c
> +++ b/drivers/clk/sunxi-ng/ccu_nm.c
> @@ -15,8 +15,8 @@
> #include "ccu_nm.h"
>
> struct _ccu_nm {
> - unsigned long n, max_n;
> - unsigned long m, max_m;
> + unsigned long n, min_n, max_n;
> + unsigned long m, min_m, max_m;
> };
>
> static void ccu_nm_find_best(unsigned long parent, unsigned long rate,
> @@ -26,8 +26,8 @@ static void ccu_nm_find_best(unsigned long parent, unsigned long rate,
> unsigned long best_n = 0, best_m = 0;
> unsigned long _n, _m;
>
> - for (_n = 1; _n <= nm->max_n; _n++) {
> - for (_m = 1; _n <= nm->max_m; _m++) {
> + for (_n = nm->min_n; _n <= nm->max_n; _n++) {
> + for (_m = nm->min_m; _n <= nm->max_m; _m++) {
And here: _m <= ...
Interestingly those typos were already in the code before.
Lets hope I don't dream of m's and k's tonight.
Cheers,
Andre.
> unsigned long tmp_rate = parent * _n / _m;
>
> if (tmp_rate > rate)
> @@ -93,7 +93,9 @@ static long ccu_nm_round_rate(struct clk_hw *hw, unsigned long rate,
> struct ccu_nm *nm = hw_to_ccu_nm(hw);
> struct _ccu_nm _nm;
>
> + _nm.min_n = 1;
> _nm.max_n = 1 << nm->n.width;
> + _nm.min_m = 1;
> _nm.max_m = nm->m.max ?: 1 << nm->m.width;
>
> ccu_nm_find_best(*parent_rate, rate, &_nm);
> @@ -114,7 +116,9 @@ static int ccu_nm_set_rate(struct clk_hw *hw, unsigned long rate,
> else
> ccu_frac_helper_disable(&nm->common, &nm->frac);
>
> + _nm.min_n = 1;
> _nm.max_n = 1 << nm->n.width;
> + _nm.min_m = 1;
> _nm.max_m = nm->m.max ?: 1 << nm->m.width;
>
> ccu_nm_find_best(parent_rate, rate, &_nm);
>
^ permalink raw reply
* [PATCH v3 0/4] MSM8996 DT Support for ADSP PIL
From: Sarangdhar Joshi @ 2016-10-21 23:19 UTC (permalink / raw)
To: linux-arm-kernel
Add various device tree nodes to lay the groundwork for
Qualcomm ADSP Peripheral Image Loader.
Sorry, I didn't send any cover letter for v1.
Changes since v2:
- Remove empty lines from smem DT node (Stephen)
Changes since v1:
- Move hwlock DT node under root (/) (Bjorn and Andy)
- Rename smp2p-adsp to adsp-smp2p (Bjorn)
- Remove interrupt-parent property from node (Bjorn)
Bjorn Andersson (1):
arm64: dts: msm8996: Add SMEM DT nodes
Sarangdhar Joshi (3):
arm64: dts: msm8996: Add SMEM reserve-memory node
arm64: dts: msm8996: Add reserve-memory nodes
arm64: dts: msm8996: Add SMP2P and APCS nodes
arch/arm64/boot/dts/qcom/msm8996.dtsi | 82 +++++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 1/4] arm64: dts: msm8996: Add SMEM reserve-memory node
From: Sarangdhar Joshi @ 2016-10-21 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477091959-19580-1-git-send-email-spjoshi@codeaurora.org>
Add DT node to carveout memory for shared memory region.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index d6da223..36216ae 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -31,6 +31,17 @@
reg = <0 0 0 0>;
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ smem_mem: smem-mem at 86000000 {
+ reg = <0x0 0x86000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <2>;
#size-cells = <0>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v3 2/4] arm64: dts: msm8996: Add reserve-memory nodes
From: Sarangdhar Joshi @ 2016-10-21 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477091959-19580-1-git-send-email-spjoshi@codeaurora.org>
Add reserve-memory nodes required for Qualcomm
Peripheral Image Loaders
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 36216ae..949b096 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -36,6 +36,31 @@
#size-cells = <2>;
ranges;
+ mba_region: mba at 91500000 {
+ reg = <0x0 0x91500000 0x0 0x200000>;
+ no-map;
+ };
+
+ slpi_region: slpi at 90b00000 {
+ reg = <0x0 0x90b00000 0xa00000>;
+ no-map;
+ };
+
+ venus_region: venus at 90400000 {
+ reg = <0x0 0x90400000 0x0 0x700000>;
+ no-map;
+ };
+
+ adsp_region: adsp at 8ea00000 {
+ reg = <0x0 0x8ea00000 0x0 0x1a00000>;
+ no-map;
+ };
+
+ mpss_region: mpss at 88800000 {
+ reg = <0x0 0x88800000 0x0 0x6200000>;
+ no-map;
+ };
+
smem_mem: smem-mem at 86000000 {
reg = <0x0 0x86000000 0x0 0x200000>;
no-map;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v3 3/4] arm64: dts: msm8996: Add SMEM DT nodes
From: Sarangdhar Joshi @ 2016-10-21 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477091959-19580-1-git-send-email-spjoshi@codeaurora.org>
From: Bjorn Andersson <bjorn.andersson@linaro.org>
Add SMEM and TCSR DT nodes on MSM8996.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 949b096..60d2d20c 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -164,17 +164,34 @@
};
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <&tcsr_mutex_regs 0 0x1000>;
+ #hwlock-cells = <1>;
+ };
+
psci {
compatible = "arm,psci-1.0";
method = "smc";
};
+ smem {
+ compatible = "qcom,smem";
+ memory-region = <&smem_mem>;
+ hwlocks = <&tcsr_mutex 3>;
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0 0xffffffff>;
compatible = "simple-bus";
+ tcsr_mutex_regs: syscon at 740000 {
+ compatible = "syscon";
+ reg = <0x740000 0x20000>;
+ };
+
intc: interrupt-controller at 9bc0000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox