* [PATCH 5/6] arm64: dts: ls1043a: update gic dts node
From: Minghuan Lian @ 2016-10-25 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477398945-22774-1-git-send-email-Minghuan.Lian@nxp.com>
From: Gong Qianyu <Qianyu.Gong@nxp.com>
In order to support kvm, rev1.1 LS1043a GIC register has been
changed to align as 64K. The patch updates GIC node according to
the rev1.1 hardware.
Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 5295bb9..da1809d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -144,10 +144,10 @@
compatible = "arm,gic-400";
#interrupt-cells = <3>;
interrupt-controller;
- reg = <0x0 0x1401000 0 0x1000>, /* GICD */
- <0x0 0x1402000 0 0x2000>, /* GICC */
- <0x0 0x1404000 0 0x2000>, /* GICH */
- <0x0 0x1406000 0 0x2000>; /* GICV */
+ reg = <0x0 0x1410000 0 0x10000>, /* GICD */
+ <0x0 0x1420000 0 0x20000>, /* GICC */
+ <0x0 0x1440000 0 0x20000>, /* GICH */
+ <0x0 0x1460000 0 0x20000>; /* GICV */
interrupts = <1 9 0xf08>;
};
--
1.9.1
^ permalink raw reply related
* [PATCH 4/6] arm64: dts: ls1046a: add MSI dts node
From: Minghuan Lian @ 2016-10-25 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477398945-22774-1-git-send-email-Minghuan.Lian@nxp.com>
LS1046a has three MSI controllers. each controller is assigned
four SPI interrupts.
Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 32 ++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 38806ca..5509dca 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -511,5 +511,37 @@
interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clockgen 4 1>;
};
+
+ msi: msi-controller {
+ compatible = "fsl,ls-scfg-msi";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ msi-controller;
+
+ msi0 at 1580000 {
+ reg = <0x0 0x1580000 0x0 0x10000>;
+ interrupts = <0 116 0x4>,
+ <0 111 0x4>,
+ <0 112 0x4>,
+ <0 113 0x4>;
+ };
+
+ msi1 at 1590000 {
+ reg = <0x0 0x1590000 0x0 0x10000>;
+ interrupts = <0 126 0x4>,
+ <0 121 0x4>,
+ <0 122 0x4>,
+ <0 123 0x4>;
+ };
+
+ msi2 at 15a0000 {
+ reg = <0x0 0x15a0000 0x0 0x10000>;
+ interrupts = <0 160 0x4>,
+ <0 155 0x4>,
+ <0 156 0x4>,
+ <0 157 0x4>;
+ };
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 3/6] arm64: dts: ls1043a: update MSI and PCIe node
From: Minghuan Lian @ 2016-10-25 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477398945-22774-1-git-send-email-Minghuan.Lian@nxp.com>
1. Change compatible to "fsl,ls-scfg-msi"
2. Move three MSI dts node into the parent node "msi-controller".
So a PCIe device can request the MSI from the three MSI controllers.
3. The rev1.1 of LS1043a moves PCIe INTB/C/D interrupts to MSI controller.
Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 64 +++++++++++++-------------
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 41e5dc1..5295bb9 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -587,25 +587,36 @@
dma-coherent;
};
- msi1: msi-controller1 at 1571000 {
- compatible = "fsl,1s1043a-msi";
- reg = <0x0 0x1571000 0x0 0x8>;
+ msi: msi-controller {
+ compatible = "fsl,ls-scfg-msi";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
msi-controller;
- interrupts = <0 116 0x4>;
- };
- msi2: msi-controller2 at 1572000 {
- compatible = "fsl,1s1043a-msi";
- reg = <0x0 0x1572000 0x0 0x8>;
- msi-controller;
- interrupts = <0 126 0x4>;
- };
+ msi0 at 1571000 {
+ reg = <0x0 0x1571000 0x0 0x1000>;
+ interrupts = <0 116 0x4>,
+ <0 111 0x4>,
+ <0 112 0x4>,
+ <0 113 0x4>;
+ };
- msi3: msi-controller3 at 1573000 {
- compatible = "fsl,1s1043a-msi";
- reg = <0x0 0x1573000 0x0 0x8>;
- msi-controller;
- interrupts = <0 160 0x4>;
+ msi1 at 1572000 {
+ reg = <0x0 0x1572000 0x0 0x1000>;
+ interrupts = <0 126 0x4>,
+ <0 121 0x4>,
+ <0 122 0x4>,
+ <0 123 0x4>;
+ };
+
+ msi2 at 1573000 {
+ reg = <0x0 0x1573000 0x0 0x1000>;
+ interrupts = <0 160 0x4>,
+ <0 155 0x4>,
+ <0 156 0x4>,
+ <0 157 0x4>;
+ };
};
pcie at 3400000 {
@@ -624,13 +635,10 @@
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x00000000 0x40 0x00010000 0x0 0x00010000 /* downstream I/O */
0x82000000 0x0 0x40000000 0x40 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
- msi-parent = <&msi1>;
+ msi-parent = <&msi>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0000 0 0 1 &gic 0 110 0x4>,
- <0000 0 0 2 &gic 0 111 0x4>,
- <0000 0 0 3 &gic 0 112 0x4>,
- <0000 0 0 4 &gic 0 113 0x4>;
+ interrupt-map = <0000 0 0 1 &gic 0 110 0x4>;
};
pcie at 3500000 {
@@ -649,13 +657,10 @@
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x00000000 0x48 0x00010000 0x0 0x00010000 /* downstream I/O */
0x82000000 0x0 0x40000000 0x48 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
- msi-parent = <&msi2>;
+ msi-parent = <&msi>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0000 0 0 1 &gic 0 120 0x4>,
- <0000 0 0 2 &gic 0 121 0x4>,
- <0000 0 0 3 &gic 0 122 0x4>,
- <0000 0 0 4 &gic 0 123 0x4>;
+ interrupt-map = <0000 0 0 1 &gic 0 120 0x4>;
};
pcie at 3600000 {
@@ -674,13 +679,10 @@
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x00000000 0x50 0x00010000 0x0 0x00010000 /* downstream I/O */
0x82000000 0x0 0x40000000 0x50 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
- msi-parent = <&msi3>;
+ msi-parent = <&msi>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0000 0 0 1 &gic 0 154 0x4>,
- <0000 0 0 2 &gic 0 155 0x4>,
- <0000 0 0 3 &gic 0 156 0x4>,
- <0000 0 0 4 &gic 0 157 0x4>;
+ interrupt-map = <0000 0 0 1 &gic 0 154 0x4>;
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/6] arm: dts: ls1021a: update MSI node
From: Minghuan Lian @ 2016-10-25 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477398945-22774-1-git-send-email-Minghuan.Lian@nxp.com>
1. Change compatible to "fsl,ls-scfg-msi"
2. Move two MSI dts node into the parent node "msi-controller".
So a PCIe device can request the MSI from the two MSI controllers.
Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
---
arch/arm/boot/dts/ls1021a.dtsi | 28 ++++++++++++++++------------
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 368e219..7a3b510 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -119,18 +119,22 @@
};
- msi1: msi-controller at 1570e00 {
- compatible = "fsl,1s1021a-msi";
- reg = <0x0 0x1570e00 0x0 0x8>;
+ msi: msi-controller {
+ compatible = "fsl,ls-scfg-msi";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
msi-controller;
- interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
- };
- msi2: msi-controller at 1570e08 {
- compatible = "fsl,1s1021a-msi";
- reg = <0x0 0x1570e08 0x0 0x8>;
- msi-controller;
- interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
+ msi0 at 1570e00 {
+ reg = <0x0 0x1570e00 0x0 0x8>;
+ interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ msi1 at 1570e08 {
+ reg = <0x0 0x1570e08 0x0 0x8>;
+ interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
ifc: ifc at 1530000 {
@@ -643,7 +647,7 @@
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x00000000 0x40 0x00010000 0x0 0x00010000 /* downstream I/O */
0x82000000 0x0 0x40000000 0x40 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
- msi-parent = <&msi1>;
+ msi-parent = <&msi>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0000 0 0 1 &gic GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
@@ -666,7 +670,7 @@
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x00000000 0x48 0x00010000 0x0 0x00010000 /* downstream I/O */
0x82000000 0x0 0x40000000 0x48 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
- msi-parent = <&msi2>;
+ msi-parent = <&msi>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0000 0 0 1 &gic GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
--
1.9.1
^ permalink raw reply related
* [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG MSI
From: Minghuan Lian @ 2016-10-25 12:35 UTC (permalink / raw)
To: linux-arm-kernel
1. The different version of a SoC may have different MSI
implementation. But compatible "fsl,<soc-name>-msi" can not describe
the SoC version. The MSI driver will use SoC match interface to get
SoC type and version instead of compatible string. So all MSI node
can use the common compatible "fsl,ls-scfg-msi" and the original
compatible is unnecessary.
2. Layerscape SoCs may have one or several MSI controllers.
In order to increase MSI interrupt number of a PCIe, the patch
moves all MSI node into the parent node "msi-controller". So a
PCIe can request MSI from all the MSI controllers.
Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
---
.../interrupt-controller/fsl,ls-scfg-msi.txt | 57 +++++++++++++++++++---
1 file changed, 49 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
index 9e38949..29f95fd 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
@@ -1,18 +1,28 @@
* Freescale Layerscape SCFG PCIe MSI controller
+Layerscape SoCs may have one or multiple MSI controllers.
+Each MSI controller must be showed as a child node.
+
Required properties:
-- compatible: should be "fsl,<soc-name>-msi" to identify
- Layerscape PCIe MSI controller block such as:
- "fsl,1s1021a-msi"
- "fsl,1s1043a-msi"
+- compatible: should be "fsl,ls-scfg-msi"
+- #address-cells: must be 2
+- #size-cells: must be 2
+- ranges: allows valid 1:1 translation between child's address space and
+ parent's address space
- msi-controller: indicates that this is a PCIe MSI controller node
+
+Required child node:
+A child node must exist to represent the MSI controller.
+The following are properties specific to those nodes:
+
- reg: physical base address of the controller and length of memory mapped.
- interrupts: an interrupt to the parent interrupt controller.
Optional properties:
- interrupt-parent: the phandle to the parent interrupt controller.
+Notes:
This interrupt controller hardware is a second level interrupt controller that
is hooked to a parent interrupt controller: e.g: ARM GIC for ARM-based
platforms. If interrupt-parent is not provided, the default parent interrupt
@@ -22,9 +32,40 @@ MSI controller node
Examples:
- msi1: msi-controller at 1571000 {
- compatible = "fsl,1s1043a-msi";
- reg = <0x0 0x1571000 0x0 0x8>,
+ msi: msi-controller {
+ compatible = "fsl,ls-scfg-msi";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
msi-controller;
- interrupts = <0 116 0x4>;
+
+ msi0 at 1580000 {
+ reg = <0x0 0x1580000 0x0 0x10000>;
+ interrupts = <0 116 0x4>,
+ <0 111 0x4>,
+ <0 112 0x4>,
+ <0 113 0x4>;
+ };
+
+ msi1 at 1590000 {
+ reg = <0x0 0x1590000 0x0 0x10000>;
+ interrupts = <0 126 0x4>,
+ <0 121 0x4>,
+ <0 122 0x4>,
+ <0 123 0x4>;
+ };
+
+ msi2 at 15a0000 {
+ reg = <0x0 0x15a0000 0x0 0x10000>;
+ interrupts = <0 160 0x4>,
+ <0 155 0x4>,
+ <0 156 0x4>,
+ <0 157 0x4>;
+ };
+ };
+
+ pcie at 3400000 {
+ ...
+ msi-parent = <&msi>;
+ ...
};
--
1.9.1
^ permalink raw reply related
* [v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
From: Matthias Brugger @ 2016-10-25 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFqH_50_OwsbMWHkT_eukF52BVZYyMbGiamXO=pV4PpJq6BADA@mail.gmail.com>
On 10/18/2016 04:37 PM, Enric Balletbo Serra wrote:
[...]
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
[...]
>> +
>> +/* Firmware */
>> +#define PS_FW_NAME "ps864x_fw.bin"
>> +
>
> From where I can download this firmware image?
>
I suppose this FW bits have to be added to linux-firmware repository
first, before this patch can be accepted.
Regards,
Matthias
^ permalink raw reply
* [PATCH/RFT v2 06/17] ARM: davinci: da8xx: Fix some redefined symbol warnings
From: Alexandre Bailon @ 2016-10-25 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9fa01842-cf8e-87e9-75ce-5d4b2841fdfe@ti.com>
On 10/25/2016 12:03 PM, Sekhar Nori wrote:
> On Monday 24 October 2016 10:16 PM, ahaslam at baylibre.com wrote:
>> From: Alexandre Bailon <abailon@baylibre.com>
>>
>> Some macro for DA8xx CFGCHIP are defined in usb-davinci.h,
>> but da8xx-cfgchip.h intend to replace them.
>> The usb-da8xx.c is using both headers, causing redefined symbol warnings.
>> Remove the old macros.
>>
>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>
> This is a v4.9-rc bug fix. Can you please post it as a separate patch
> for Greg to pick up?
>
Done
> You can add:
>
> Acked-by: Sekhar Nori <nsekhar@ti.com>
Actually, I didn't add it because I had to make few changes to
submit as a separate patch. I hope I did it in right way.
>
> Thanks,
> Sekhar
>
Thanks,
Alexandre
^ permalink raw reply
* [PATCH v2] ARM: davinci: da8xx: Fix some redefined symbol warnings
From: Alexandre Bailon @ 2016-10-25 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477397492-7925-1-git-send-email-abailon@baylibre.com>
Some macro for DA8xx CFGCHIP are defined in usb-davinci.h,
but da8xx-cfgchip.h intend to replace them.
The usb-da8xx.c is using both headers, causing redefined symbol warnings.
Remove the macro and update the da830-evm board file to use da8xx-cfgchip.h
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 3 ++-
include/linux/platform_data/usb-davinci.h | 23 -----------------------
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 3d8cf8c..9817316 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -27,6 +27,7 @@
#include <linux/platform_data/mtd-davinci-aemif.h>
#include <linux/platform_data/spi-davinci.h>
#include <linux/platform_data/usb-davinci.h>
+#include <linux/mfd/da8xx-cfgchip.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -133,7 +134,7 @@ static __init void da830_evm_usb_init(void)
* controller won't be able to drive VBUS thinking that it's a B-device.
* Otherwise, we want to use the OTG mode and enable VBUS comparators.
*/
- cfgchip2 &= ~CFGCHIP2_OTGMODE;
+ cfgchip2 &= ~CFGCHIP2_OTGMODE_MASK;
#ifdef CONFIG_USB_MUSB_HOST
cfgchip2 |= CFGCHIP2_FORCE_HOST;
#else
diff --git a/include/linux/platform_data/usb-davinci.h b/include/linux/platform_data/usb-davinci.h
index e0bc4ab..0926e99 100644
--- a/include/linux/platform_data/usb-davinci.h
+++ b/include/linux/platform_data/usb-davinci.h
@@ -11,29 +11,6 @@
#ifndef __ASM_ARCH_USB_H
#define __ASM_ARCH_USB_H
-/* DA8xx CFGCHIP2 (USB 2.0 PHY Control) register bits */
-#define CFGCHIP2_PHYCLKGD (1 << 17)
-#define CFGCHIP2_VBUSSENSE (1 << 16)
-#define CFGCHIP2_RESET (1 << 15)
-#define CFGCHIP2_OTGMODE (3 << 13)
-#define CFGCHIP2_NO_OVERRIDE (0 << 13)
-#define CFGCHIP2_FORCE_HOST (1 << 13)
-#define CFGCHIP2_FORCE_DEVICE (2 << 13)
-#define CFGCHIP2_FORCE_HOST_VBUS_LOW (3 << 13)
-#define CFGCHIP2_USB1PHYCLKMUX (1 << 12)
-#define CFGCHIP2_USB2PHYCLKMUX (1 << 11)
-#define CFGCHIP2_PHYPWRDN (1 << 10)
-#define CFGCHIP2_OTGPWRDN (1 << 9)
-#define CFGCHIP2_DATPOL (1 << 8)
-#define CFGCHIP2_USB1SUSPENDM (1 << 7)
-#define CFGCHIP2_PHY_PLLON (1 << 6) /* override PLL suspend */
-#define CFGCHIP2_SESENDEN (1 << 5) /* Vsess_end comparator */
-#define CFGCHIP2_VBDTCTEN (1 << 4) /* Vbus comparator */
-#define CFGCHIP2_REFFREQ (0xf << 0)
-#define CFGCHIP2_REFFREQ_12MHZ (1 << 0)
-#define CFGCHIP2_REFFREQ_24MHZ (2 << 0)
-#define CFGCHIP2_REFFREQ_48MHZ (3 << 0)
-
struct da8xx_ohci_root_hub;
typedef void (*da8xx_ocic_handler_t)(struct da8xx_ohci_root_hub *hub,
--
2.7.3
^ permalink raw reply related
* [PATCH v2] Fix some potential warnings
From: Alexandre Bailon @ 2016-10-25 12:11 UTC (permalink / raw)
To: linux-arm-kernel
Some changes I'm working on causes some warning because two included
headers defines the same macros.
Change in V2:
Update the d830 evm board file to use the da8xx-cfgchip.h
These changes are required as I'm sending this patch apart from
the series "[PATCH/RFT v2 00/17] Add DT support for ohci-da8xx"
Alexandre Bailon (1):
ARM: davinci: da8xx: Fix some redefined symbol warnings
arch/arm/mach-davinci/board-da830-evm.c | 3 ++-
include/linux/platform_data/usb-davinci.h | 23 -----------------------
2 files changed, 2 insertions(+), 24 deletions(-)
--
2.7.3
^ permalink raw reply
* [PATCH v3 3/6] dt-bindings: pinctrl: Deprecate sunxi pinctrl bindings
From: Linus Walleij @ 2016-10-25 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024194917.g5oezqc4uacsyt24@lukather>
On Mon, Oct 24, 2016 at 9:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> However, it looks like the first patch from this serie is missing from
> your tree, is there a reason for that?
No can you point it out?
> Also, in order to preserve bisectability, could you create an
> immutable branch for those sunxi patches so that I can merge the DT
> bits?
It's too late because they are already in the devel branch
and mixed up with merged of *other* immutable stuff.
However I think it is plain wrong to try to keep any bisectability
between the kernel at large and arch/*/boot/dts/*, because
the DTS stuff is supposed to at some point be maintained outside
of the kernel and for all OSes, they simply shouldn't be sync:ed.
Yours,
Linus Walleij
^ permalink raw reply
* [RFC] shutdown machine when li-ion battery goes below 3V
From: Pali Rohár @ 2016-10-25 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025112757.GC25855@amd>
On Tuesday 25 October 2016 13:27:57 Pavel Machek wrote:
> On Mon 2016-10-24 14:29:33, Tony Lindgren wrote:
> > * Pavel Machek <pavel@ucw.cz> [161024 14:24]:
> > > Hi!
> > >
> > > What about something like this? N900 will drain the battery down to
> > > system crash, which is quite uncool.
> >
> > Can't we make that generic and configurable for the voltage somehow?
> >
> > Also, the shutdown voltage can depend on external devices connected.
> > It could be for example 3.3V depending on eMMC on some devices while
> > devices with no eMMC could have it at 3.0V.
>
> Actually, do we need to make it configurable? It looks like we should
> respect hardware telling us battery is dead, and only use (low)
> hardcoded voltages as a fallback.
>
> Currently patch looks like this. generic_protect() should work for
> other batteries drivers, too.
Now I checked Maemo's BME replacement code and it shutdown device 10
seconds after it read that capacity level is LOW or CRITICAL. bq27xxx
driver reports LOW when EDV1 is set and CRITICAL when EDVF is set. And
bq27xxx reports those LOW/CRITICAL based on EDV1/EDVF flags even if
battery is not calibrated.
So I would be happy if kernel does not issue emergency shutdown before
Maemo's BME replacement issue own "correct" system shutdown. As Maemo is
doing it on EDV1 flag (not EDVF as I thought!) with 10 seconds delay and
check is done every 30 seconds it means that Maemo shutdown process in
worst case is started 40 seconds after EDV1 is set. Shutdown process is
about 60 seconds (probably max.), can we ensure that kernel does not do
its own emergency shutdown earlier then 2 minutes before first see EDV1
flag? Or can test that EDVF flag is set in most cases 2 minutes after
EDV1?
It is really bad idea to start emergency kernel shutdown before even
userspace do it!
> Pavel
>
> diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
> index 0fe278b..04094ad 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -46,6 +46,7 @@
> #include <linux/delay.h>
> #include <linux/platform_device.h>
> #include <linux/power_supply.h>
> +#include <linux/reboot.h>
> #include <linux/slab.h>
> #include <linux/of.h>
>
> @@ -679,10 +680,10 @@ static int bq27xxx_battery_read_health(struct bq27xxx_device_info *di)
> /* Unlikely but important to return first */
> if (unlikely(bq27xxx_battery_overtemp(di, flags)))
> return POWER_SUPPLY_HEALTH_OVERHEAT;
> - if (unlikely(bq27xxx_battery_undertemp(di, flags)))
> - return POWER_SUPPLY_HEALTH_COLD;
> if (unlikely(bq27xxx_battery_dead(di, flags)))
> return POWER_SUPPLY_HEALTH_DEAD;
> + if (unlikely(bq27xxx_battery_undertemp(di, flags)))
> + return POWER_SUPPLY_HEALTH_COLD;
>
> return POWER_SUPPLY_HEALTH_GOOD;
> }
> @@ -740,6 +741,49 @@ void bq27xxx_battery_update(struct bq27xxx_device_info *di)
> }
> EXPORT_SYMBOL_GPL(bq27xxx_battery_update);
>
> +static void shutdown(char *reason)
> +{
> + pr_alert("%s Forcing shutdown\n", reason);
> + orderly_poweroff(true);
> +}
> +
> +static int generic_protect(struct power_supply *psy)
> +{
> + union power_supply_propval val;
> + int res;
> + int mV, mA, mOhm = 430, mVadj = 0;
> +
> + res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_HEALTH, &val);
> + if (res)
> + return res;
> +
> + if (val.intval == POWER_SUPPLY_HEALTH_OVERHEAT)
> + shutdown("Battery overheat.");
> + if (val.intval == POWER_SUPPLY_HEALTH_DEAD)
> + shutdown("Battery dead.");
Generally this is not a good idea. On some boards with bq27xxx devices
you can have another battery device or connected power device. You could
have "dead" battery but device supplied e.g. from wallcharger.
N900 cannot be powered from wallcharger by default, but in specific
conditions (turned everything except display) you can do battery
hotswap (when wallcharger is connected; it can power system).
So this patch basically break lot of other self powered devices.
I would propose check for am_i_power_supplied() (function with such name
in power_supply interface exist) and do that only for negative response.
> + res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_VOLTAGE_NOW, &val);
> + if (res)
> + return res;
> + mV = val.intval / 1000;
> +
> + if (mV < 2950)
> + shutdown("Battery below 2.95V.");
> +
> + res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_CURRENT_NOW, &val);
> + if (res)
> + return res;
> + mA = val.intval / 1000;
> + mVadj = mV + (mA * mOhm) / 1000;
> +
> + if (mVadj < 3150)
> + shutdown("Battery internal voltage below 3.15.");
> +
> + printk(KERN_INFO "Main battery %d mV, internal voltage %d mV\n",
> + mV, mVadj);
Please no printk. There is dev_info or how is that function called. And
spamming dmesg for every poll is not good idea. It should be probably
DEBUG not INFO.
> + return 0;
> +}
> +
> static void bq27xxx_battery_poll(struct work_struct *work)
> {
> struct bq27xxx_device_info *di =
> @@ -747,6 +791,7 @@ static void bq27xxx_battery_poll(struct work_struct *work)
> work.work);
>
> bq27xxx_battery_update(di);
> + generic_protect(di->bat);
>
> if (poll_interval > 0)
> schedule_delayed_work(&di->work, poll_interval * HZ);
>
--
Pali Roh?r
pali.rohar at gmail.com
^ permalink raw reply
* [RFC] shutdown machine when li-ion battery goes below 3V
From: Pavel Machek @ 2016-10-25 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024212932.uhjz752z2cy5hohl@atomide.com>
On Mon 2016-10-24 14:29:33, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [161024 14:24]:
> > Hi!
> >
> > What about something like this? N900 will drain the battery down to
> > system crash, which is quite uncool.
>
> Can't we make that generic and configurable for the voltage somehow?
>
> Also, the shutdown voltage can depend on external devices connected.
> It could be for example 3.3V depending on eMMC on some devices while
> devices with no eMMC could have it at 3.0V.
Actually, do we need to make it configurable? It looks like we should
respect hardware telling us battery is dead, and only use (low)
hardcoded voltages as a fallback.
Currently patch looks like this. generic_protect() should work for
other batteries drivers, too.
Pavel
diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
index 0fe278b..04094ad 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -46,6 +46,7 @@
#include <linux/delay.h>
#include <linux/platform_device.h>
#include <linux/power_supply.h>
+#include <linux/reboot.h>
#include <linux/slab.h>
#include <linux/of.h>
@@ -679,10 +680,10 @@ static int bq27xxx_battery_read_health(struct bq27xxx_device_info *di)
/* Unlikely but important to return first */
if (unlikely(bq27xxx_battery_overtemp(di, flags)))
return POWER_SUPPLY_HEALTH_OVERHEAT;
- if (unlikely(bq27xxx_battery_undertemp(di, flags)))
- return POWER_SUPPLY_HEALTH_COLD;
if (unlikely(bq27xxx_battery_dead(di, flags)))
return POWER_SUPPLY_HEALTH_DEAD;
+ if (unlikely(bq27xxx_battery_undertemp(di, flags)))
+ return POWER_SUPPLY_HEALTH_COLD;
return POWER_SUPPLY_HEALTH_GOOD;
}
@@ -740,6 +741,49 @@ void bq27xxx_battery_update(struct bq27xxx_device_info *di)
}
EXPORT_SYMBOL_GPL(bq27xxx_battery_update);
+static void shutdown(char *reason)
+{
+ pr_alert("%s Forcing shutdown\n", reason);
+ orderly_poweroff(true);
+}
+
+static int generic_protect(struct power_supply *psy)
+{
+ union power_supply_propval val;
+ int res;
+ int mV, mA, mOhm = 430, mVadj = 0;
+
+ res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_HEALTH, &val);
+ if (res)
+ return res;
+
+ if (val.intval == POWER_SUPPLY_HEALTH_OVERHEAT)
+ shutdown("Battery overheat.");
+ if (val.intval == POWER_SUPPLY_HEALTH_DEAD)
+ shutdown("Battery dead.");
+
+ res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_VOLTAGE_NOW, &val);
+ if (res)
+ return res;
+ mV = val.intval / 1000;
+
+ if (mV < 2950)
+ shutdown("Battery below 2.95V.");
+
+ res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_CURRENT_NOW, &val);
+ if (res)
+ return res;
+ mA = val.intval / 1000;
+ mVadj = mV + (mA * mOhm) / 1000;
+
+ if (mVadj < 3150)
+ shutdown("Battery internal voltage below 3.15.");
+
+ printk(KERN_INFO "Main battery %d mV, internal voltage %d mV\n",
+ mV, mVadj);
+ return 0;
+}
+
static void bq27xxx_battery_poll(struct work_struct *work)
{
struct bq27xxx_device_info *di =
@@ -747,6 +791,7 @@ static void bq27xxx_battery_poll(struct work_struct *work)
work.work);
bq27xxx_battery_update(di);
+ generic_protect(di->bat);
if (poll_interval > 0)
schedule_delayed_work(&di->work, poll_interval * HZ);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161025/db1c8616/attachment.sig>
^ permalink raw reply related
* [PATCH] convert orion5x ls-chl to device tree
From: Andrew Lunn @ 2016-10-25 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14522899-679b-2f8b-73ca-493788299790@gmail.com>
On Tue, Oct 25, 2016 at 12:04:49AM +0100, Ash Hughes wrote:
> Hi all,
>
> This patch converts my orion5x ls-chl Linkstation device to device tree.
>
> Signed-off-by: Ashley Hughes <ashley.hughes@blueyonder.co.uk>
Hi Ash
Nicely done.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: Sekhar Nori @ 2016-10-25 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <84648cb0-f1fa-d88b-bac2-79208af01ca6@lechnology.com>
On Tuesday 25 October 2016 02:50 AM, David Lechner wrote:
> On 10/24/2016 02:50 PM, David Lechner wrote:
>> On 10/24/2016 10:50 AM, David Lechner wrote:
>>> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>>>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>>>
>>>>> +&ehrpwm1 {
>>>>> + status = "disabled";
>>>>
>>>> Hmm, disabled? Can you add this node when you actually use it?
>>>
>>> Not sure why I have this disabled. Like the gpios, the pwms can be used
>>> via sysfs, so I would like to leave them.
>>>
>>
>> Now I remember why these are disabled. The clock matching is broken.
>> Only the first ehrpwm and the first ecap get clocks. The others fail.
>>
>> I can change these to "okay". It will just result in a kernel error
>> message until the clocks are fixed.
>>
>
> correction: it is not the clocks that are broken. it is the device names.
>
> In arch/arm/mach-davinci/da8xx-dt.c, we have...
>
>
> OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm", NULL),
> OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm", NULL),
> OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap", NULL),
> OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap", NULL),
> OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap", NULL),
>
>
> Which causes each device to have the same device node name. This causes
> sysfs errors because it is trying to register a second device at the
> same sysfs path.
>
> If you change the names here, then the device do not work because the
> clock lookup fails.
Yeah, this is incorrect (I should have caught it in review). The device
id should have been present in the lookup. Can you fix auxdata and clock
lookup too and send a separate patch? Its probably a v4.9-rc candidate.
Thanks,
Sekhar
^ permalink raw reply
* [RFC] shutdown machine when li-ion battery goes below 3V
From: Pali Rohár @ 2016-10-25 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025105604.GA25855@amd>
On Tuesday 25 October 2016 12:56:04 Pavel Machek wrote:
> Take a look at code. Health is not read from hardware unless battery
> is calibrated.
Then it is bug. EDVF should be accepted also when battery is not
calibrated.
--
Pali Roh?r
pali.rohar at gmail.com
^ permalink raw reply
* [RFC] shutdown machine when li-ion battery goes below 3V
From: Pavel Machek @ 2016-10-25 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025105320.GK12154@pali>
On Tue 2016-10-25 12:53:20, Pali Roh?r wrote:
> On Tuesday 25 October 2016 12:24:35 Pavel Machek wrote:
> > On Mon 2016-10-24 23:48:47, Pali Roh?r wrote:
> > > On Monday 24 October 2016 23:41:52 Pavel Machek wrote:
> > > > On Mon 2016-10-24 14:29:33, Tony Lindgren wrote:
> > > > > Also, the shutdown voltage can depend on external devices
> > > > > connected. It could be for example 3.3V depending on eMMC on some
> > > > > devices while devices with no eMMC could have it at 3.0V.
> > > >
> > > > Actually, I'd like to shutdown at 3.3V or more (like 3.5V), because
> > > > going below that is pretty mean to the battery. But if I set
> > > > threshold too high, GSM activity will push it below that for a very
> > > > short while, and I'll shutdown too soon.
> > > >
> > > > Ideas welcome...
> > >
> > > bq27x00 has EDVF flag which means that battery is empty. Maemo with
> > > bq27x00 driver is configured to issue system shutdown when EDVF is set.
> > >
> > > Maybe kernel should issue emergency shutdown e.g. after minute or two
> > > after EDVF flag is set?
> >
> > Thanks for pointer.
> >
> > EDVF seems to be exposed as health. ... but only if battery is
> > calibrated, AFAICT.
>
> No, EDVF is available also for uncalibrated battery. There are EDV1 and
> EDVF flags. Both are set based on battery voltage and some other
> parameters from bq EEPROM.
>
> > if (has_ci_flag && (cache.flags & BQ27000_FLAG_CI)) {
> > dev_info_once(di->dev, "battery is not calibrated! ignoring capacity values\n");
>
> Yes, it ignores only capacity values (which needs calibration), not
> those raw flags which works also without calibration.
>
> > ...
> > cache.health = -ENODATA;
Take a look at code. Health is not read from hardware unless battery
is calibrated.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161025/61eece66/attachment.sig>
^ permalink raw reply
* [PATCH/RFT v2 00/17] Add DT support for ohci-da8xx
From: Sekhar Nori @ 2016-10-25 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024164634.4330-1-ahaslam@baylibre.com>
Hi Axel,
On Monday 24 October 2016 10:16 PM, ahaslam at baylibre.com wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
>
> The purpose of this patch series is to add DT support and modernize
> the ohci-da8xx glue driver without breaking the non-DT boot,
> which is still used in unconverted davinci devices.
>From a mach-davinci perspective, there are some patches which seem to be
safe to apply and some which depend on corresponding driver changes to
get in.
In order to speed up the process of applying this series, can you split
the mach-davinci updates which are safe to apply into a separate series.
For DT patches, the bindings should be accepted. For other patches, they
should not be causing any regressions.
Thanks,
Sekhar
^ permalink raw reply
* [RFC] shutdown machine when li-ion battery goes below 3V
From: Pali Rohár @ 2016-10-25 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025102435.GA6916@amd>
On Tuesday 25 October 2016 12:24:35 Pavel Machek wrote:
> On Mon 2016-10-24 23:48:47, Pali Roh?r wrote:
> > On Monday 24 October 2016 23:41:52 Pavel Machek wrote:
> > > On Mon 2016-10-24 14:29:33, Tony Lindgren wrote:
> > > > Also, the shutdown voltage can depend on external devices
> > > > connected. It could be for example 3.3V depending on eMMC on some
> > > > devices while devices with no eMMC could have it at 3.0V.
> > >
> > > Actually, I'd like to shutdown at 3.3V or more (like 3.5V), because
> > > going below that is pretty mean to the battery. But if I set
> > > threshold too high, GSM activity will push it below that for a very
> > > short while, and I'll shutdown too soon.
> > >
> > > Ideas welcome...
> >
> > bq27x00 has EDVF flag which means that battery is empty. Maemo with
> > bq27x00 driver is configured to issue system shutdown when EDVF is set.
> >
> > Maybe kernel should issue emergency shutdown e.g. after minute or two
> > after EDVF flag is set?
>
> Thanks for pointer.
>
> EDVF seems to be exposed as health. ... but only if battery is
> calibrated, AFAICT.
No, EDVF is available also for uncalibrated battery. There are EDV1 and
EDVF flags. Both are set based on battery voltage and some other
parameters from bq EEPROM.
> if (has_ci_flag && (cache.flags & BQ27000_FLAG_CI)) {
> dev_info_once(di->dev, "battery is not calibrated! ignoring capacity values\n");
Yes, it ignores only capacity values (which needs calibration), not
those raw flags which works also without calibration.
> ...
> cache.health = -ENODATA;
>
> Plus, it prioritizes battery cold over battery dead. IMO we don't need
> to shutdown on battery cold (we just may not charge the battery), but
> we need to shutdown on battery dead.
>
> So something like this?
>
> Pavel
>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
>
> diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
> index 8eb2f8f..5ddf6d7 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -680,10 +680,10 @@ static int bq27xxx_battery_read_health(struct bq27xxx_device_info *di)
> /* Unlikely but important to return first */
> if (unlikely(bq27xxx_battery_overtemp(di, flags)))
> return POWER_SUPPLY_HEALTH_OVERHEAT;
> - if (unlikely(bq27xxx_battery_undertemp(di, flags)))
> - return POWER_SUPPLY_HEALTH_COLD;
> if (unlikely(bq27xxx_battery_dead(di, flags)))
> return POWER_SUPPLY_HEALTH_DEAD;
> + if (unlikely(bq27xxx_battery_undertemp(di, flags)))
> + return POWER_SUPPLY_HEALTH_COLD;
>
> return POWER_SUPPLY_HEALTH_GOOD;
> }
>
>
Looks like this is OK.
--
Pali Roh?r
pali.rohar at gmail.com
^ permalink raw reply
* [PATCH/RFT v2 12/17] USB: ochi-da8xx: Use a regulator for vbus/overcurrent
From: Axel Haslam @ 2016-10-25 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d7e2b356-4874-fdc1-c505-70e57e3908de@ti.com>
On Tue, Oct 25, 2016 at 12:43 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Monday 24 October 2016 10:16 PM, ahaslam at baylibre.com wrote:
>> From: Axel Haslam <ahaslam@baylibre.com>
>>
>> Currently, the da8xx ohci driver uses a set of gpios and callbacks in
>> board files to handle vbus and overcurrent irqs form the power supply.
>> However, this does not play nice when moving to a DT based boot were
>> we wont have board files.
>>
>> Instead of requesting and handling the gpio, use the regulator framework
>> to take care of enabling and disabling vbus power. This has the benefit
>> that we dont need to pass any more platform data to the driver:
>>
>> These will be handled by the regulator framework:
>> set_power -> regulator_enable/regulator_disable
>> get_power -> regulator_is_enabled
>> get_oci -> regulator_get_mode
>> ocic_notify -> regulator notification
>>
>> We can keep the default potpgt and use the regulator start delay instead:
>> potpgt -> regulator startup delay time
>>
>> The hawk board does not have a GPIO/OVERCURRENT gpio to control vbus,
>> (they should not have been decleared/reserved) so, just remove those
>> definitions from the hwk board file.
>>
>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>> ---
>> arch/arm/mach-davinci/board-da830-evm.c | 97 ++++++++----------------
>> arch/arm/mach-davinci/board-omapl138-hawk.c | 96 +-----------------------
>> arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
>> arch/arm/mach-davinci/usb-da8xx.c | 3 +-
>> drivers/usb/host/ohci-da8xx.c | 111 ++++++++++++++++++----------
>> include/linux/platform_data/usb-davinci.h | 19 -----
>> 6 files changed, 105 insertions(+), 223 deletions(-)
>
> Can you separate out the driver enhancement from the platform
> (mach-davinci) changes? They need to go through different trees.
>
Ok, i will do that, (it might require intermediate code to have
the driver working on each patch)
> Thanks,
> Sekhar
>
>
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: fix the pinmux for UART1
From: Maxime Ripard @ 2016-10-25 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024170831.38819-1-icenowy@aosc.xyz>
On Tue, Oct 25, 2016 at 01:08:31AM +0800, Icenowy Zheng wrote:
> When the patch is applied, the allwinner,driver and allwinner,pull
> properties are removed.
>
> Although they're described to be optional in the devicetree binding,
> without them, the pinmux cannot be initialized, and the uart cannot
> be used.
>
> Add them back to fix the problem, and makes the bluetooth on iNet D978
> Rev2 board work.
>
> Fixes: 82eec384249f (ARM: dts: sun8i: add pinmux for UART1 at PG)
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161025/1babf742/attachment-0001.sig>
^ permalink raw reply
* [PATCH v7 11/11] arm64: dts: r8a7796: salvator-x: Enable UHS-I SDR-104
From: Geert Uytterhoeven @ 2016-10-25 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-12-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57 PM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Add the sd-uhs-sdr104 property to SDHI0 and SDHI1.
SDHI0 and SDHI3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v7 03/11] arm64: dts: r8a7795: salvator-x: Enable UHS-I SDR-104
From: Geert Uytterhoeven @ 2016-10-25 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-4-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57 PM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Add the sd-uhs-sdr104 property to SDHI0 and SDHI1.
SDHI0 and SDHI3?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Disabling an interrupt in the handler locks the system up
From: Marc Zyngier @ 2016-10-25 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <580F1992.2070602@free.fr>
On 25/10/16 09:36, Mason wrote:
> On 25/10/2016 10:29, Sebastian Frias wrote:
>
>> On 10/24/2016 06:55 PM, Thomas Gleixner wrote:
>>
>>> On Mon, 24 Oct 2016, Mason wrote:
>>>
>>>> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
>>>> makes the system lock-up disappear.
>>>
>>> The way how lazy irq disabling works is:
>>>
>>> 1) Interrupt is marked disabled in software, but the hardware is not masked
>>>
>>> 2) If the interrupt fires befor the interrupt is reenabled, then it's
>>> masked at the hardware level in the low level interrupt flow handler.
>>
>> Would you mind explaining what is the intention behind?
>> Because it does not seem obvious why there isn't a direct map between
>> "disable_irq*()" and "mask_irq()"
>
> I had a similar, but slightly different question:
>
> What is the difference between struct irq_chip's
>
> * @irq_shutdown: shut down the interrupt (defaults to ->disable if NULL)
> * @irq_disable: disable the interrupt
> * @irq_mask: mask an interrupt source
One important difference between disable and mask is that disable is
perfectly allowed not to care about pending signals, whereas mask must
preserve an interrupt becoming pending whilst masked.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH/RFT v2 12/17] USB: ochi-da8xx: Use a regulator for vbus/overcurrent
From: Sekhar Nori @ 2016-10-25 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024164634.4330-13-ahaslam@baylibre.com>
On Monday 24 October 2016 10:16 PM, ahaslam at baylibre.com wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
>
> Currently, the da8xx ohci driver uses a set of gpios and callbacks in
> board files to handle vbus and overcurrent irqs form the power supply.
> However, this does not play nice when moving to a DT based boot were
> we wont have board files.
>
> Instead of requesting and handling the gpio, use the regulator framework
> to take care of enabling and disabling vbus power. This has the benefit
> that we dont need to pass any more platform data to the driver:
>
> These will be handled by the regulator framework:
> set_power -> regulator_enable/regulator_disable
> get_power -> regulator_is_enabled
> get_oci -> regulator_get_mode
> ocic_notify -> regulator notification
>
> We can keep the default potpgt and use the regulator start delay instead:
> potpgt -> regulator startup delay time
>
> The hawk board does not have a GPIO/OVERCURRENT gpio to control vbus,
> (they should not have been decleared/reserved) so, just remove those
> definitions from the hwk board file.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
> arch/arm/mach-davinci/board-da830-evm.c | 97 ++++++++----------------
> arch/arm/mach-davinci/board-omapl138-hawk.c | 96 +-----------------------
> arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
> arch/arm/mach-davinci/usb-da8xx.c | 3 +-
> drivers/usb/host/ohci-da8xx.c | 111 ++++++++++++++++++----------
> include/linux/platform_data/usb-davinci.h | 19 -----
> 6 files changed, 105 insertions(+), 223 deletions(-)
Can you separate out the driver enhancement from the platform
(mach-davinci) changes? They need to go through different trees.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/3] phy: sun4i: check PHY id when poking unknown bit of pmu
From: Maxime Ripard @ 2016-10-25 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1773661477366364@web4j.yandex.ru>
Hi,
On Tue, Oct 25, 2016 at 11:32:44AM +0800, Icenowy Zheng wrote:
>
>
> > On Mon, Oct 24, 2016 at 11:59:30AM +0800, Icenowy Zheng wrote:
> >
> >> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
> >> The code that poke some unknown bit of PMU for H3/A64 didn't check
> >> the PHY, and will cause kernel oops when PHY 0 is used.
> >>
> >> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
> >>
> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >
> > Cc'ing stable would be nice.
>
> Yes... As it's also used by H3...
>
> >
> > Apart from that, Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> If I change it to check whether phy->pmu is null, will you keep the ACK?
Yep, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161025/09742e34/attachment.sig>
^ 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