* next-20170110 build: 1 failures 4 warnings (next-20170110)
From: Sekhar Nori @ 2017-01-11 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111072131.51449059@canb.auug.org.au>
On Wednesday 11 January 2017 01:51 AM, Stephen Rothwell wrote:
> Hi Mark,
>
> On Tue, 10 Jan 2017 18:16:07 +0000 Mark Brown <broonie@kernel.org> wrote:
>>
>> On Tue, Jan 10, 2017 at 07:21:32AM +0000, Build bot for Mark Brown wrote:
>>
>> Today's -next fails to build an arm allmodconfig due to:
>>
>>> arm-allmodconfig
>>> ../drivers/net/ethernet/ti/netcp_core.c:1951:28: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>
>> caused by 6a8162e99ef344 (net: netcp: store network statistics in 64
>> bits). It's assigning the function
>>
>> static struct rtnl_link_stats64 *
>> netcp_get_stats(struct net_device *ndev, struct rtnl_link_stats64 *stats)
>>
>> to ndo_get_stats64 which expects a function returning void.
>
> Yes, but only because commit bc1f44709cf2 ("net: make ndo_get_stats64 a
> void function") entered the net-next tree on the same day ... so it
> needs a followup fixup patch for this new usage.
Keerthy sent a patch fixing this yesterday. Looks like he will have to
spin another version though.
https://patchwork.ozlabs.org/patch/713224/
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2017-01-11 10:10 UTC (permalink / raw)
To: linux-arm-kernel
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds this reserved zone and redefines the usable memory range.
The memory node is also moved from the dtsi files into the proper dts files
to handle variants memory sizes.
This patch also fixes the memory sizes for the following platforms :
- gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 5 -----
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 5 -----
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 9 +++++++++
17 files changed, 106 insertions(+), 18 deletions(-)
Changes since resent v2 at [4]:
- Fix invalid comment of useable memory attributes
Changes since original v2 at [3]:
- Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
Changes since v2 at [2]:
- Moved all memory node out of dtsi
- Added comment about useable memory
- Fixed comment about secmon reserved zone
Changes since v1 at [1] :
- Renamed reg into linux,usable-memory to ovveride u-boot memory
- only kept secmon memory zone
[1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong at baylibre.com
[2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong at baylibre.com
[3] http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstrong at baylibre.com
[4] http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstrong at baylibre.com
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 7a078be..360ec0d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -54,11 +54,6 @@
stdout-path = "serial0:115200n8";
};
- memory at 0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
- };
-
vddio_boot: regulator-vddio_boot {
compatible = "regulator-fixed";
regulator-name = "VDDIO_BOOT";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index eada0b5..66677b5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,18 @@
#address-cells = <2>;
#size-cells = <2>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 2MiB reserved for ARM Trusted Firmware (BL31) */
+ secmon: secmon {
+ reg = <0x0 0x10000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <0x2>;
#size-cells = <0x0>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 4cbd626..54ffbff 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -62,7 +62,11 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
leds {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..1b474ba 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -61,7 +61,11 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
usb_otg_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
index 03e3d76..af7b151 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,p200", "amlogic,meson-gxbb";
model = "Amlogic Meson GXBB P200 Development Board";
+
+ memory at 0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
&i2c_B {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
index 39bb037..215096c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
@@ -49,4 +49,13 @@
/ {
compatible = "amlogic,p201", "amlogic,meson-gxbb";
model = "Amlogic Meson GXBB P201 Development Board";
+
+ memory at 0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 4a96e0f..8052a39 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -53,11 +53,6 @@
stdout-path = "serial0:115200n8";
};
- memory at 0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
- };
-
usb_pwr: regulator-usb-pwrs {
compatible = "regulator-fixed";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
index 62fb496..8d6cfb9 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
@@ -50,6 +50,10 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
index 9a9663a..543e03a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
@@ -50,6 +50,10 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
index 2fe167b..9a76fb5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
@@ -50,6 +50,10 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index cea4a3e..ac874ac 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -60,7 +60,11 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
vddio_card: gpio-regulator {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index f66939c..2e2b821 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,p230", "amlogic,s905d", "amlogic,meson-gxl";
model = "Amlogic Meson GXL (S905D) P230 Development Board";
+
+ memory at 0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
+ };
};
/* P230 has exclusive choice between internal or external PHY */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
index 95992cf..d252da9 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,p231", "amlogic,s905d", "amlogic,meson-gxl";
model = "Amlogic Meson GXL (S905D) P231 Development Board";
+
+ memory at 0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
/* P231 has only internal PHY port */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
index 9639f01..86f7db0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
@@ -59,7 +59,11 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index 5a337d3..2b65e06 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -62,7 +62,11 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_boot: regulator-vddio-boot {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
index 5dbc660..cdfe618 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,q200", "amlogic,s912", "amlogic,meson-gxm";
model = "Amlogic Meson GXM (S912) Q200 Development Board";
+
+ memory at 0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
+ };
};
/* Q200 has exclusive choice between internal or external PHY */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
index 95e11d7..9047ffa 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,q201", "amlogic,s912", "amlogic,meson-gxm";
model = "Amlogic Meson GXM (S912) Q201 Development Board";
+
+ memory at 0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
/* Q201 has only internal PHY port */
--
1.9.1
^ permalink raw reply related
* [PATCH] arm64: Add support for DMA_ATTR_SKIP_CPU_SYNC attribute to swiotlb
From: Geert Uytterhoeven @ 2017-01-11 10:11 UTC (permalink / raw)
To: linux-arm-kernel
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
This patch adds support for DMA_ATTR_SKIP_CPU_SYNC attribute for
dma_{un}map_{page,sg} functions family to swiotlb.
DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of
the CPU cache for the given buffer assuming that it has been already
transferred to 'device' domain.
Ported from IOMMU .{un}map_{sg,page} ops.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- Add Acked-by.
Support for DMA_ATTR_SKIP_CPU_SYNC was included when porting the IOMMU
ops from arm to arm64 in commit 13b8629f651164d7 ("arm64: Add IOMMU
dma_ops").
Presumably it was an oversight that the existing swiotlb based
implementation didn't have support for DMA_ATTR_SKIP_CPU_SYNC yet?
---
arch/arm64/mm/dma-mapping.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index e04082700bb16c35..1d7d5d2881db7c19 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -211,7 +211,8 @@ static dma_addr_t __swiotlb_map_page(struct device *dev, struct page *page,
dma_addr_t dev_addr;
dev_addr = swiotlb_map_page(dev, page, offset, size, dir, attrs);
- if (!is_device_dma_coherent(dev))
+ if (!is_device_dma_coherent(dev) &&
+ (attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_map_area(phys_to_virt(dma_to_phys(dev, dev_addr)), size, dir);
return dev_addr;
@@ -222,7 +223,8 @@ static void __swiotlb_unmap_page(struct device *dev, dma_addr_t dev_addr,
size_t size, enum dma_data_direction dir,
unsigned long attrs)
{
- if (!is_device_dma_coherent(dev))
+ if (!is_device_dma_coherent(dev) &&
+ (attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_unmap_area(phys_to_virt(dma_to_phys(dev, dev_addr)), size, dir);
swiotlb_unmap_page(dev, dev_addr, size, dir, attrs);
}
@@ -235,7 +237,8 @@ static int __swiotlb_map_sg_attrs(struct device *dev, struct scatterlist *sgl,
int i, ret;
ret = swiotlb_map_sg_attrs(dev, sgl, nelems, dir, attrs);
- if (!is_device_dma_coherent(dev))
+ if (!is_device_dma_coherent(dev) &&
+ (attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
for_each_sg(sgl, sg, ret, i)
__dma_map_area(phys_to_virt(dma_to_phys(dev, sg->dma_address)),
sg->length, dir);
@@ -251,7 +254,8 @@ static void __swiotlb_unmap_sg_attrs(struct device *dev,
struct scatterlist *sg;
int i;
- if (!is_device_dma_coherent(dev))
+ if (!is_device_dma_coherent(dev) &&
+ (attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
for_each_sg(sgl, sg, nelems, i)
__dma_unmap_area(phys_to_virt(dma_to_phys(dev, sg->dma_address)),
sg->length, dir);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/3] dt: bindings: add documentation for zx2967 family thermal sensor
From: Baoyou Xie @ 2017-01-11 10:14 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds dt-binding documentation for zx2967 family thermal sensor.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
.../devicetree/bindings/thermal/zx2967-thermal.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
new file mode 100644
index 0000000..86f941c
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
@@ -0,0 +1,21 @@
+* ZTE zx2967 family Thermal
+
+Required Properties:
+- compatible: should be one of the following.
+ * zte,zx296718-thermal
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- clocks : Pairs of phandle and specifier referencing the controller's clocks.
+- clock-names: "gate" for the topcrm clock.
+ "pclk" for the apb clock.
+- #thermal-sensor-cells: must be 0.
+
+Example:
+
+ tempsensor: tempsensor at 148a000 {
+ compatible = "zte,zx296718-thermal";
+ reg = <0x0148a000 0x20>;
+ clocks = <&topcrm TEMPSENSOR_GATE>, <&audiocrm AUDIO_TS_PCLK>;
+ clock-names = "gate", "pclk";
+ #thermal-sensor-cells = <0>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] MAINTAINERS: add zx2967 thermal drivers to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-11 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484129651-17531-1-git-send-email-baoyou.xie@linaro.org>
Add the zx2967 thermal drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 64f04df..2593296 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1981,6 +1981,7 @@ S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
F: drivers/soc/zte/
+F: drivers/thermal/zx*
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
F: Documentation/devicetree/bindings/soc/zte/
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family
From: Baoyou Xie @ 2017-01-11 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484129651-17531-1-git-send-email-baoyou.xie@linaro.org>
This patch adds thermal driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/thermal/Kconfig | 6 +
drivers/thermal/Makefile | 1 +
drivers/thermal/zx2967_thermal.c | 247 +++++++++++++++++++++++++++++++++++++++
3 files changed, 254 insertions(+)
create mode 100644 drivers/thermal/zx2967_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 18f2de6..0dd597e 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -445,3 +445,9 @@ config BCM2835_THERMAL
Support for thermal sensors on Broadcom bcm2835 SoCs.
endif
+
+config ZX2967_THERMAL
+ tristate "Thermal sensors on zx2967 SoC"
+ depends on ARCH_ZX
+ help
+ Support for thermal sensors on ZTE zx2967 SoCs.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 677c6d9..c00c05e 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
+obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
diff --git a/drivers/thermal/zx2967_thermal.c b/drivers/thermal/zx2967_thermal.c
new file mode 100644
index 0000000..bdd2d5e
--- /dev/null
+++ b/drivers/thermal/zx2967_thermal.c
@@ -0,0 +1,247 @@
+/*
+ * ZTE's zx2967 family thermal sensor driver
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/thermal.h>
+
+/* Power Mode: 0->low 1->high */
+#define ZX2967_THERMAL_POWER_MODE (0)
+
+/* DCF Control Register */
+#define ZX2967_THERMAL_DCF 0x4
+
+/* Selection Register */
+#define ZX2967_THERMAL_SEL 0x8
+
+/* Control Register */
+#define ZX2967_THERMAL_CTRL 0x10
+
+#define ZX2967_THERMAL_READY (0x1000)
+#define ZX2967_THERMAL_TEMP_MASK (0xfff)
+#define ZX2967_THERMAL_ID_MASK (0x18)
+#define ZX2967_THERMAL_ID0 (0x8)
+#define ZX2967_THERMAL_ID1 (0x10)
+
+struct zx2967_thermal_sensor {
+ struct zx2967_thermal_priv *priv;
+ struct thermal_zone_device *tzd;
+ int id;
+};
+
+#define NUM_SENSORS 1
+
+struct zx2967_thermal_priv {
+ struct zx2967_thermal_sensor sensors[NUM_SENSORS];
+ struct mutex lock;
+ struct clk *clk_gate;
+ struct clk *pclk;
+ void __iomem *regs;
+};
+
+static int zx2967_thermal_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+
+ if (priv && priv->pclk)
+ clk_disable_unprepare(priv->pclk);
+
+ if (priv && priv->clk_gate)
+ clk_disable_unprepare(priv->clk_gate);
+
+ return 0;
+}
+
+static int zx2967_thermal_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+ int error;
+
+ error = clk_prepare_enable(priv->clk_gate);
+ if (error)
+ return error;
+
+ error = clk_prepare_enable(priv->pclk);
+ if (error) {
+ clk_disable_unprepare(priv->clk_gate);
+ return error;
+ }
+
+ return 0;
+}
+
+static int zx2967_thermal_get_temp(void *data, int *temp)
+{
+ void __iomem *regs;
+ struct zx2967_thermal_sensor *sensor = data;
+ struct zx2967_thermal_priv *priv = sensor->priv;
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 val, sel_id;
+
+ regs = priv->regs;
+ mutex_lock(&priv->lock);
+
+ writel_relaxed(0, regs + ZX2967_THERMAL_POWER_MODE);
+ writel_relaxed(2, regs + ZX2967_THERMAL_DCF);
+
+ val = readl_relaxed(regs + ZX2967_THERMAL_SEL);
+ val &= ~ZX2967_THERMAL_ID_MASK;
+ sel_id = sensor->id ? ZX2967_THERMAL_ID0 : ZX2967_THERMAL_ID1;
+ val |= sel_id;
+ writel_relaxed(val, regs + ZX2967_THERMAL_SEL);
+
+ usleep_range(100, 300);
+ val = readl_relaxed(regs + ZX2967_THERMAL_CTRL);
+ while (!(val & ZX2967_THERMAL_READY)) {
+ if (time_after(jiffies, timeout)) {
+ pr_err("Thermal sensor %d data timeout\n",
+ sensor->id);
+ mutex_unlock(&priv->lock);
+ return -ETIMEDOUT;
+ }
+ val = readl_relaxed(regs + ZX2967_THERMAL_CTRL);
+ }
+
+ writel_relaxed(3, regs + ZX2967_THERMAL_DCF);
+ val = readl_relaxed(regs + ZX2967_THERMAL_CTRL)
+ & ZX2967_THERMAL_TEMP_MASK;
+ writel_relaxed(1, regs + ZX2967_THERMAL_POWER_MODE);
+
+ /** Calculate temperature */
+ *temp = DIV_ROUND_CLOSEST((val - 922) * 1000, 1951);
+
+ mutex_unlock(&priv->lock);
+
+ return 0;
+}
+
+static struct thermal_zone_of_device_ops zx2967_of_thermal_ops = {
+ .get_temp = zx2967_thermal_get_temp,
+};
+
+static int zx2967_thermal_probe(struct platform_device *pdev)
+{
+ struct zx2967_thermal_priv *priv;
+ struct resource *res;
+ int ret, i;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(priv->regs))
+ return PTR_ERR(priv->regs);
+
+ priv->clk_gate = devm_clk_get(&pdev->dev, "gate");
+ if (IS_ERR(priv->clk_gate)) {
+ ret = PTR_ERR(priv->clk_gate);
+ dev_err(&pdev->dev, "failed to get clock gate: %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(priv->clk_gate);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to enable converter clock: %d\n",
+ ret);
+ return ret;
+ }
+
+ priv->pclk = devm_clk_get(&pdev->dev, "pclk");
+ if (IS_ERR(priv->pclk)) {
+ ret = PTR_ERR(priv->pclk);
+ dev_err(&pdev->dev, "failed to get apb clock: %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(priv->pclk);
+ if (ret) {
+ clk_disable_unprepare(priv->clk_gate);
+ dev_err(&pdev->dev, "failed to enable converter clock: %d\n",
+ ret);
+ return ret;
+ }
+
+ mutex_init(&priv->lock);
+ for (i = 0; i < NUM_SENSORS; i++) {
+ struct zx2967_thermal_sensor *sensor = &priv->sensors[i];
+
+ sensor->priv = priv;
+ sensor->id = i;
+ sensor->tzd = thermal_zone_of_sensor_register(&pdev->dev,
+ i, sensor, &zx2967_of_thermal_ops);
+ if (IS_ERR(sensor->tzd)) {
+ ret = PTR_ERR(sensor->tzd);
+ dev_err(&pdev->dev, "failed to register sensor %d: %d\n",
+ i, ret);
+ goto remove_ts;
+ }
+ }
+ platform_set_drvdata(pdev, priv);
+
+ return 0;
+
+remove_ts:
+ clk_disable_unprepare(priv->clk_gate);
+ clk_disable_unprepare(priv->pclk);
+ for (i--; i >= 0; i--)
+ thermal_zone_of_sensor_unregister(&pdev->dev,
+ priv->sensors[i].tzd);
+
+ return ret;
+}
+
+static int zx2967_thermal_exit(struct platform_device *pdev)
+{
+ struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+ int i;
+
+ for (i = 0; i < NUM_SENSORS; i++) {
+ struct zx2967_thermal_sensor *sensor = &priv->sensors[i];
+
+ thermal_zone_of_sensor_unregister(&pdev->dev, sensor->tzd);
+ }
+ clk_disable_unprepare(priv->pclk);
+ clk_disable_unprepare(priv->clk_gate);
+
+ return 0;
+}
+
+static const struct of_device_id zx2967_thermal_id_table[] = {
+ { .compatible = "zte,zx296718-thermal" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, zx2967_thermal_id_table);
+
+static SIMPLE_DEV_PM_OPS(zx2967_thermal_pm_ops,
+ zx2967_thermal_suspend, zx2967_thermal_resume);
+
+static struct platform_driver zx2967_thermal_driver = {
+ .probe = zx2967_thermal_probe,
+ .remove = zx2967_thermal_exit,
+ .driver = {
+ .name = "zx2967_thermal",
+ .of_match_table = zx2967_thermal_id_table,
+ .pm = &zx2967_thermal_pm_ops,
+ },
+};
+module_platform_driver(zx2967_thermal_driver);
+
+MODULE_AUTHOR("Baoyou Xie <baoyou.xie@linaro.org>");
+MODULE_DESCRIPTION("ZTE zx2967 thermal driver");
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [PATCH] rtc: armada38x: make struct rtc_class_ops const
From: Russell King @ 2017-01-11 10:16 UTC (permalink / raw)
To: linux-arm-kernel
Armada38x wants to modify its rtc_class_ops to remove the interrupt
handling when there is no usable interrupt, but this means we leave
function pointers in writable memory.
Since rtc_class_ops is small, arrange to have two instances, one for
when we have interrupts, and one for when we have none, both marked
const. This allows the compiler to place them in read-only memory,
which is better than placing them in __ro_after_init.
Thanks to Bhumika Goyal <bhumirks@gmail.com> for pointing out that
the structure was writable and submitting a patch to add
__ro_after_init.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
As the thread has gone quiet, I'm submitting the patch I sent within that
thread. No one appears to have raised an objection to it (other than what
appears to be a misunderstanding.)
drivers/rtc/rtc-armada38x.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/rtc/rtc-armada38x.c b/drivers/rtc/rtc-armada38x.c
index 9a3f2a6f512e..a4166ccfce36 100644
--- a/drivers/rtc/rtc-armada38x.c
+++ b/drivers/rtc/rtc-armada38x.c
@@ -202,7 +202,7 @@ static irqreturn_t armada38x_rtc_alarm_irq(int irq, void *data)
return IRQ_HANDLED;
}
-static struct rtc_class_ops armada38x_rtc_ops = {
+static const struct rtc_class_ops armada38x_rtc_ops = {
.read_time = armada38x_rtc_read_time,
.set_time = armada38x_rtc_set_time,
.read_alarm = armada38x_rtc_read_alarm,
@@ -210,8 +210,15 @@ static struct rtc_class_ops armada38x_rtc_ops = {
.alarm_irq_enable = armada38x_rtc_alarm_irq_enable,
};
+static const struct rtc_class_ops armada38x_rtc_ops_noirq = {
+ .read_time = armada38x_rtc_read_time,
+ .set_time = armada38x_rtc_set_time,
+ .read_alarm = armada38x_rtc_read_alarm,
+};
+
static __init int armada38x_rtc_probe(struct platform_device *pdev)
{
+ const struct rtc_class_ops *ops;
struct resource *res;
struct armada38x_rtc *rtc;
int ret;
@@ -242,19 +249,22 @@ static __init int armada38x_rtc_probe(struct platform_device *pdev)
0, pdev->name, rtc) < 0) {
dev_warn(&pdev->dev, "Interrupt not available.\n");
rtc->irq = -1;
+ }
+ platform_set_drvdata(pdev, rtc);
+
+ if (rtc->irq != -1) {
+ device_init_wakeup(&pdev->dev, 1);
+ ops = &armada38x_rtc_ops;
+ } else {
/*
* If there is no interrupt available then we can't
* use the alarm
*/
- armada38x_rtc_ops.set_alarm = NULL;
- armada38x_rtc_ops.alarm_irq_enable = NULL;
+ ops = &armada38x_rtc_ops_noirq;
}
- platform_set_drvdata(pdev, rtc);
- if (rtc->irq != -1)
- device_init_wakeup(&pdev->dev, 1);
rtc->rtc_dev = devm_rtc_device_register(&pdev->dev, pdev->name,
- &armada38x_rtc_ops, THIS_MODULE);
+ ops, THIS_MODULE);
if (IS_ERR(rtc->rtc_dev)) {
ret = PTR_ERR(rtc->rtc_dev);
dev_err(&pdev->dev, "Failed to register RTC device: %d\n", ret);
--
2.7.4
^ permalink raw reply related
* [PATCHv3 3/8] rtc: add STM32 RTC driver
From: Alexandre Belloni @ 2017-01-11 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1feb3a23-7450-2b5c-9c1c-c7ecacd7fa17@st.com>
On 11/01/2017 at 11:07:16 +0100, Amelie DELAUNAY wrote :
> > This will never happen, tm is already checked multiple times (up to
> > three) in the core before this function can be called.
> >
> You're right. I'll remove all rtc_valid_tm calls.
You can keep the one in read_time
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] arm64: hugetlb: fix the wrong return value for huge_ptep_set_access_flags
From: Catalin Marinas @ 2017-01-11 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111060044.GA6112@sha-win-210.asiapac.arm.com>
On Wed, Jan 11, 2017 at 02:00:46PM +0800, Huang Shijie wrote:
> On Wed, Jan 11, 2017 at 01:58:28PM +0800, Huang Shijie wrote:
> > In current code, the @changed always returns the last one's
> > status for the huge page with the contiguous bit set.
> > This is really not what we want. Even one of the PTEs is changed,
> > we should tell it to the caller.
> >
> > This patch fixes this issue.
> >
> > Fixes: 66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit")
> > Cc: stable at vger.kernel.org
> > Signed-off-by: Huang Shijie <shijie.huang@arm.com>
> > ---
> > arch/arm64/mm/hugetlbpage.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > index 964b7549af5c..e25584d72396 100644
> > --- a/arch/arm64/mm/hugetlbpage.c
> > +++ b/arch/arm64/mm/hugetlbpage.c
> > @@ -239,7 +239,7 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma,
> > ncontig = find_num_contig(vma->vm_mm, addr, cpte,
> > *cpte, &pgsize);
> > for (i = 0; i < ncontig; ++i, ++cpte, addr += pgsize) {
> > - changed = ptep_set_access_flags(vma, addr, cpte,
> > + changed |= ptep_set_access_flags(vma, addr, cpte,
> > pfn_pte(pfn,
> > hugeprot),
> > dirty);
> > --
> > 2.5.5
> >
> sorry, I missed to remove the disclaimer.
The disclaimer is not the main issue. The patch that ended up on the
list seems to have been corrupted probably by the SMTP server (all tabs
converted to spaces).
--
Catalin
^ permalink raw reply
* [PATCH v6 02/14] irqchip: gic-v3-its: keep the head file include in alphabetic order
From: Matthias Brugger @ 2017-01-11 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-3-git-send-email-hanjun.guo@linaro.org>
On 02/01/17 14:31, Hanjun Guo wrote:
> The head file is strictly in alphabetic order now, so let's
> be the rule breaker. As acpi_iort.h includes acpi.h so remove
> the duplidate acpi.h inclusion as well.
>
Sounds strange, maybe someting like:
Rearrange header file includes to alphabetic order. As acpi_iort.h...
Regards,
Matthias
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Majun <majun258@huawei.com>
> Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 69b040f..f471939 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -15,14 +15,13 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> -#include <linux/acpi.h>
> +#include <linux/acpi_iort.h>
> #include <linux/bitmap.h>
> #include <linux/cpu.h>
> #include <linux/delay.h>
> #include <linux/dma-iommu.h>
> #include <linux/interrupt.h>
> #include <linux/irqdomain.h>
> -#include <linux/acpi_iort.h>
> #include <linux/log2.h>
> #include <linux/mm.h>
> #include <linux/msi.h>
>
^ permalink raw reply
* [PATCH v6 02/14] irqchip: gic-v3-its: keep the head file include in alphabetic order
From: Matthias Brugger @ 2017-01-11 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-3-git-send-email-hanjun.guo@linaro.org>
On 02/01/17 14:31, Hanjun Guo wrote:
> The head file is strictly in alphabetic order now, so let's
> be the rule breaker. As acpi_iort.h includes acpi.h so remove
> the duplidate acpi.h inclusion as well.
>
Sounds strange, maybe someting like:
Rearrange header file includes to alphabetic order. As acpi_iort.h...
Regards,
Matthias
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Majun <majun258@huawei.com>
> Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 69b040f..f471939 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -15,14 +15,13 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> -#include <linux/acpi.h>
> +#include <linux/acpi_iort.h>
> #include <linux/bitmap.h>
> #include <linux/cpu.h>
> #include <linux/delay.h>
> #include <linux/dma-iommu.h>
> #include <linux/interrupt.h>
> #include <linux/irqdomain.h>
> -#include <linux/acpi_iort.h>
> #include <linux/log2.h>
> #include <linux/mm.h>
> #include <linux/msi.h>
>
^ permalink raw reply
* [PATCH] PCI/MSI: pci-xgene-msi: Fix CPU hotplug registration handling
From: Marc Zyngier @ 2017-01-11 10:26 UTC (permalink / raw)
To: linux-arm-kernel
The conversion to the new hotplug state machine introduced a regression
where a successful hotplug registration would be treated as an error,
effectively disabling the MSI driver forever.
Fix it by doing the proper check on the return value.
Fixes: 9c248f8896e6 ("PCI/xgene-msi: Convert to hotplug state machine")
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Duc Dang <dhdang@apm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable at vger.kernel.org
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/pci/host/pci-xgene-msi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
index 1f38d08..f1b633b 100644
--- a/drivers/pci/host/pci-xgene-msi.c
+++ b/drivers/pci/host/pci-xgene-msi.c
@@ -517,7 +517,7 @@ static int xgene_msi_probe(struct platform_device *pdev)
rc = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "pci/xgene:online",
xgene_msi_hwirq_alloc, NULL);
- if (rc)
+ if (rc < 0)
goto err_cpuhp;
pci_xgene_online = rc;
rc = cpuhp_setup_state(CPUHP_PCI_XGENE_DEAD, "pci/xgene:dead", NULL,
--
2.1.4
^ permalink raw reply related
* [PATCH v2] arm64: hugetlb: fix the wrong return value for huge_ptep_set_access_flags
From: Catalin Marinas @ 2017-01-11 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484114520-6168-1-git-send-email-shijie.huang@arm.com>
On Wed, Jan 11, 2017 at 02:02:00PM +0800, Huang Shijie wrote:
> In current code, the @changed always returns the last one's
> status for the huge page with the contiguous bit set.
> This is really not what we want. Even one of the PTEs is changed,
> we should tell it to the caller.
>
> This patch fixes this issue.
>
> Fixes: 66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit")
> Cc: stable at vger.kernel.org
> Signed-off-by: Huang Shijie <shijie.huang@arm.com>
Applied for 4.10. Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v6 04/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
From: Matthias Brugger @ 2017-01-11 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-5-git-send-email-hanjun.guo@linaro.org>
On 02/01/17 14:31, Hanjun Guo wrote:
> Adding ACPI support for platform MSI, we need to retrieve the
> dev id in ACPI way instead of device tree, we already have
> a well formed function its_pmsi_prepare() to get the dev id
> but it's OF dependent, so collect OF related code and put them
> into a single function to make its_pmsi_prepare() more friendly
> to ACPI later.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Tested-by: Majun <majun258@huawei.com>
> Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 23 ++++++++++++++++-------
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index 470b4aa..3c94278 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -24,15 +24,11 @@
> .name = "ITS-pMSI",
> };
>
> -static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
> - int nvec, msi_alloc_info_t *info)
> +static int of_pmsi_get_dev_id(struct irq_domain *domain, struct device *dev,
> + u32 *dev_id)
> {
> - struct msi_domain_info *msi_info;
> - u32 dev_id;
> int ret, index = 0;
>
> - msi_info = msi_get_domain_info(domain->parent);
> -
> /* Suck the DeviceID out of the msi-parent property */
> do {
> struct of_phandle_args args;
> @@ -43,11 +39,24 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
> if (args.np == irq_domain_get_of_node(domain)) {
> if (WARN_ON(args.args_count != 1))
> return -EINVAL;
> - dev_id = args.args[0];
> + *dev_id = args.args[0];
> break;
> }
> } while (!ret);
>
> + return ret;
> +}
> +
> +static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
> + int nvec, msi_alloc_info_t *info)
> +{
> + struct msi_domain_info *msi_info;
> + u32 dev_id;
> + int ret;
> +
> + msi_info = msi_get_domain_info(domain->parent);
> +
> + ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
> if (ret)
> return ret;
>
>
^ permalink raw reply
* [PATCH v2 1/2] virtio_mmio: Set DMA masks appropriately
From: Jean-Philippe Brucker @ 2017-01-11 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <85015f1653eb7e36f992708362b75d1f4391b783.1484070340.git.robin.murphy@arm.com>
On 10/01/17 17:51, Robin Murphy wrote:
> Once DMA API usage is enabled, it becomes apparent that virtio-mmio is
> inadvertently relying on the default 32-bit DMA mask, which leads to
> problems like rapidly exhausting SWIOTLB bounce buffers.
>
> Ensure that we set the appropriate 64-bit DMA mask whenever possible,
> with the coherent mask suitably limited for the legacy vring as per
> a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for legacy virtio
> devices").
Thanks, and for what it's worth:
Tested-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Reported-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> Fixes: b42111382f0e ("virtio_mmio: Use the DMA API if enabled")
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/virtio/virtio_mmio.c | 20 +++++++++++++++++++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
> index d47a2fcef818..c71fde5fe835 100644
> --- a/drivers/virtio/virtio_mmio.c
> +++ b/drivers/virtio/virtio_mmio.c
> @@ -59,6 +59,7 @@
> #define pr_fmt(fmt) "virtio-mmio: " fmt
>
> #include <linux/acpi.h>
> +#include <linux/dma-mapping.h>
> #include <linux/highmem.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> @@ -498,6 +499,7 @@ static int virtio_mmio_probe(struct platform_device *pdev)
> struct virtio_mmio_device *vm_dev;
> struct resource *mem;
> unsigned long magic;
> + int rc;
>
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!mem)
> @@ -547,9 +549,25 @@ static int virtio_mmio_probe(struct platform_device *pdev)
> }
> vm_dev->vdev.id.vendor = readl(vm_dev->base + VIRTIO_MMIO_VENDOR_ID);
>
> - if (vm_dev->version == 1)
> + if (vm_dev->version == 1) {
> writel(PAGE_SIZE, vm_dev->base + VIRTIO_MMIO_GUEST_PAGE_SIZE);
>
> + rc = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> + /*
> + * In the legacy case, ensure our coherently-allocated virtio
> + * ring will be at an address expressable as a 32-bit PFN.
> + */
> + if (!rc)
> + dma_set_coherent_mask(&pdev->dev,
> + DMA_BIT_MASK(32 + PAGE_SHIFT));
> + } else {
> + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> + }
> + if (rc)
> + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> + if (rc)
> + dev_warn(&pdev->dev, "Failed to enable 64-bit or 32-bit DMA. Trying to continue, but this might not work.\n");
> +
> platform_set_drvdata(pdev, vm_dev);
>
> return register_virtio_device(&vm_dev->vdev);
>
^ permalink raw reply
* [PATCH] PCI/MSI: pci-xgene-msi: Fix CPU hotplug registration handling
From: Sebastian Andrzej Siewior @ 2017-01-11 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484130407-24707-1-git-send-email-marc.zyngier@arm.com>
On 2017-01-11 10:26:47 [+0000], Marc Zyngier wrote:
> The conversion to the new hotplug state machine introduced a regression
> where a successful hotplug registration would be treated as an error,
> effectively disabling the MSI driver forever.
>
> Fix it by doing the proper check on the return value.
>
> Fixes: 9c248f8896e6 ("PCI/xgene-msi: Convert to hotplug state machine")
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Sebastian
^ permalink raw reply
* [PATCHv3 3/8] rtc: add STM32 RTC driver
From: Amelie DELAUNAY @ 2017-01-11 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111101708.ujcgo7kpyywymyzp@piout.net>
On 01/11/2017 11:17 AM, Alexandre Belloni wrote:
> On 11/01/2017 at 11:07:16 +0100, Amelie DELAUNAY wrote :
>>> This will never happen, tm is already checked multiple times (up to
>>> three) in the core before this function can be called.
>>>
>> You're right. I'll remove all rtc_valid_tm calls.
>
> You can keep the one in read_time
>
Even if rtc_valid_tm is called just after rtc->ops->read_time() in
__rtc_read_time ?
^ permalink raw reply
* [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: Sekhar Nori @ 2017-01-11 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483677228-2325-6-git-send-email-david@lechnology.com>
On Friday 06 January 2017 10:03 AM, David Lechner wrote:
> + beeper {
> + compatible = "pwm-beeper";
> + pinctrl-names = "default";
> + pinctrl-0 = <&ehrpwm0b_pins>, <&_pins>;
> + pwms = <&ehrpwm0 1 0 0>;
> + enable-gpios = <&gpio 111 GPIO_ACTIVE_HIGH>;
Since the enable-gpios binding for pwm beeper is still not accepted, can
you drop the property or the node itself (if that makes more sense)?
> +&spi0 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
> +
> + flash at 0 {
> + compatible = "n25q128a13", "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <50000000>;
> + ti,spi-wdelay = <8>;
> +
> + /* Partitions are based on the official firmware from LEGO */
> + partitions {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition at 0 {
> + label = "U-Boot";
> + reg = <0 0x40000>;
> + };
> +
> + partition at 40000 {
> + label = "U-Boot Env";
> + reg = <0x40000 0x10000>;
> + };
> +
> + partition at 50000 {
> + label = "Kernel";
> + reg = <0x50000 0x200000>;
> + };
> +
> + partition at 250000 {
> + label = "Filesystem";
> + reg = <0x250000 0xa50000>;
> + };
> +
> + partition at cb0000 {
> + label = "Storage";
> + reg = <0xcb0000 0x2f0000>;
> + };
> + };
> + };
> +
> + adc at 3 {
> + compatible = "ti-ads7957";
So looks like this works because of_register_spi_device() sets up
modalias of spi device from compatible string. I am fine with it, just
highlighting it here to make sure this is acceptable practice. I did not
really find any precedence for using SPI device name as compatible
property in existing DTS files.
> + reg = <3>;
> + spi-max-frequency = <10000000>;
> + refin-supply = <&adc_ref>;
> + };
Rest of the patch looks good to me.
Thanks,
Sekhar
^ permalink raw reply
* [PATCHv3 3/8] rtc: add STM32 RTC driver
From: Alexandre Belloni @ 2017-01-11 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff7a532e-a2a7-920a-29d9-e8a82d6ed915@st.com>
On 11/01/2017 at 11:42:50 +0100, Amelie DELAUNAY wrote :
>
> On 01/11/2017 11:17 AM, Alexandre Belloni wrote:
> > On 11/01/2017 at 11:07:16 +0100, Amelie DELAUNAY wrote :
> > > > This will never happen, tm is already checked multiple times (up to
> > > > three) in the core before this function can be called.
> > > >
> > > You're right. I'll remove all rtc_valid_tm calls.
> >
> > You can keep the one in read_time
> >
> Even if rtc_valid_tm is called just after rtc->ops->read_time() in
> __rtc_read_time ?
Ah yes, I forgot it was added, you can remove all of them.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] rtc: armada38x: make struct rtc_class_ops const
From: Alexandre Belloni @ 2017-01-11 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cRFxi-00083n-FY@rmk-PC.armlinux.org.uk>
On 11/01/2017 at 10:16:58 +0000, Russell King wrote :
> Armada38x wants to modify its rtc_class_ops to remove the interrupt
> handling when there is no usable interrupt, but this means we leave
> function pointers in writable memory.
>
> Since rtc_class_ops is small, arrange to have two instances, one for
> when we have interrupts, and one for when we have none, both marked
> const. This allows the compiler to place them in read-only memory,
> which is better than placing them in __ro_after_init.
>
> Thanks to Bhumika Goyal <bhumirks@gmail.com> for pointing out that
> the structure was writable and submitting a patch to add
> __ro_after_init.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> As the thread has gone quiet, I'm submitting the patch I sent within that
> thread. No one appears to have raised an objection to it (other than what
> appears to be a misunderstanding.)
>
> drivers/rtc/rtc-armada38x.c | 24 +++++++++++++++++-------
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Guenter Roeck @ 2017-01-11 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd56e90c-5cb8-02d8-3518-c8f5483a6df4@sigmadesigns.com>
On 01/11/2017 01:07 AM, Marc Gonzalez wrote:
>> @@ -134,12 +134,15 @@ static int tangox_wdt_probe(struct platform_device *pdev)
>> err = clk_prepare_enable(dev->clk);
>> if (err)
>> return err;
>> + err = devm_add_action_or_reset(&pdev->dev,
>> + (void(*)(void *))clk_disable_unprepare,
>> + dev->clk);
>> + if (err)
>> + return err;
>
> Hello Guenter,
>
> I would rather avoid the function pointer cast.
> How about defining an auxiliary function for the cleanup action?
>
> clk_disable_unprepare() is static inline, so gcc will have to
> define an auxiliary function either way. What do you think?
>
Not really. It would just make it more complicated to replace the
call with devm_clk_prepare_enable(), should it ever find its way
into the light of day.
Guenter
^ permalink raw reply
* [PATCH v29 4/9] arm64: kdump: implement machine_crash_shutdown()
From: Will Deacon @ 2017-01-11 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111063626.GE20972@linaro.org>
On Wed, Jan 11, 2017 at 03:36:28PM +0900, AKASHI Takahiro wrote:
> On Tue, Jan 10, 2017 at 11:32:48AM +0000, Will Deacon wrote:
> > On Wed, Dec 28, 2016 at 01:36:01PM +0900, AKASHI Takahiro wrote:
> > > @@ -22,6 +25,7 @@
> > > extern const unsigned char arm64_relocate_new_kernel[];
> > > extern const unsigned long arm64_relocate_new_kernel_size;
> > >
> > > +static bool in_crash_kexec;
> >
> > Do you actually need this bool? Why not call kexec_crash_loaded() instead?
>
> The two have different meanings:
> "in_crash_kexec" indicates that kdump is taking place, while
> kexec_crash_loaded() tells us only whether crash dump kernel has been
> loaded or not.
>
> It is crucial to distinguish them especially for machine_kexec()
> which can be called on normal kexec even if kdump has been set up.
Ah, I see. So how about just doing:
if (kimage == kexec_crash_image)
in machine_kexec?
Will
^ permalink raw reply
* [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle
From: Jean-Jacques Hiblot @ 2017-01-11 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <F9F4555C4E01D7469D37975B62D0EFBB496BE4@CHN-SV-EXMX07.mchp-main.com>
2017-01-11 9:15 GMT+01:00 <Wenyou.Yang@microchip.com>:
> Hi Jean-Jacques,
>
>> -----Original Message-----
>> From: Jean-Jacques Hiblot [mailto:jjhiblot at gmail.com]
>> Sent: 2017?1?11? 0:51
>> To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>> Cc: Wenyou Yang - A41535 <Wenyou.Yang@microchip.com>; Mark Rutland
>> <mark.rutland@arm.com>; devicetree <devicetree@vger.kernel.org>; Russell
>> King <linux@arm.linux.org.uk>; Wenyou Yang - A41535
>> <Wenyou.Yang@microchip.com>; Nicolas Ferre <nicolas.ferre@atmel.com>;
>> Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Rob Herring
>> <robh+dt@kernel.org>; linux-arm-kernel at lists.infradead.org
>> Subject: Re: [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle
>>
>> 2017-01-10 17:18 GMT+01:00 Alexandre Belloni
>> <alexandre.belloni@free-electrons.com>:
>> > I though a bit more about it, and I don't really like the new
>> > compatible string. I don't feel this should be necessary.
>> >
>> > What about the following:
>> >
>> > diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index
>> > b4332b727e9c..0333aca63e44 100644
>> > --- a/arch/arm/mach-at91/pm.c
>> > +++ b/arch/arm/mach-at91/pm.c
>> > @@ -53,6 +53,7 @@ extern void at91_pinctrl_gpio_resume(void); static
>> > struct {
>> > unsigned long uhp_udp_mask;
>> > int memctrl;
>> > + bool has_l2_cache;
>> > } at91_pm_data;
>> >
>> > void __iomem *at91_ramc_base[2];
>> > @@ -267,6 +268,11 @@ static void at91_ddr_standby(void)
>> > u32 lpr0, lpr1 = 0;
>> > u32 saved_lpr0, saved_lpr1 = 0;
>> >
>>
>> > + if (at91_pm_data.has_l2_cache) {
>> > + flush_cache_all();
>> what is the point of calling flush_cache_all() here ? Do we really care that dirty
>> data in L1 is written to DDR ? I may be missing something but to me it's just extra
>> latency.
>
> Are you mean use outer_flush_all() to flush all cache lines in the outer cache only?
Yes that's what I meant. You see, you don't flush the cache for
sama5d3 so it shouldn't be required either for sam5d4. You should be
able to test it quickly and see if L1 flush is indeed required by
replacing flush_cache_all() with outer_flush_all(). BTW is highly
probable that L2 cache flush is done in outer_disable() so calling
outer_flush_all() is probably no required.
However the more I think on it, the more I wonder about the reason why
L2 flushing is required or to put it differently: is flusing the L2
cache the correct thing to do or just a workaround ?
Could it be that L2 is doing some maintenance operation when DDR
enters self refresh? In that case maybe a simple cache sync could be
used.
>
>> > + outer_disable();
>> It seems to me that if there's no L2 cache, then outer_disable() is a no-op. It
>> could be called unconditionally.
>> > + }
>> > +
>> > if (at91_ramc_base[1]) {
>> > saved_lpr1 = at91_ramc_read(1, AT91_DDRSDRC_LPR);
>> > lpr1 = saved_lpr1 & ~AT91_DDRSDRC_LPCB; @@ -287,6
>> > +293,9 @@ static void at91_ddr_standby(void)
>> > at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr0);
>> > if (at91_ramc_base[1])
>> > at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
>> > +
>> > + if (at91_pm_data.has_l2_cache)
>> > + outer_resume();
>>
>> same remark as for outer_disable()
>>
>> Jean-Jacques
>>
>> > }
>> >
>> > /* We manage both DDRAM/SDRAM controllers, we need more than one
>> > value
>> > * to
>> > @@ -353,6 +362,11 @@ static __init void at91_dt_ramc(void)
>> > return;
>> > }
>> >
>> > + np = of_find_compatible_node(NULL, NULL, "arm,pl310-cache");
>> > + if (np)
>> > + at91_pm_data.has_l2_cache = true;
>> > + of_node_put(np);
>> > +
>> > at91_pm_set_standby(standby);
>> > }
>> >
>> >
>> > This has the following benefits:
>> > - everybody will have the fix, regardless of whether the dtb is
>> > updated
>> > - has_l2_cache can be used later in at91_pm_suspend instead of calling
>> > it unconditionnaly (I'll send a patch)
>> >
>> >
>> > On 06/01/2017 at 14:59:45 +0800, Wenyou Yang wrote :
>> >> For the SoCs such as SAMA5D2 and SAMA5D4 which have L2 cache, flush
>> >> the L2 cache first before entering the cpu idle.
>> >>
>> >> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
>> >> ---
>> >>
>> >> arch/arm/mach-at91/pm.c | 19 +++++++++++++++++++
>> >> drivers/memory/atmel-sdramc.c | 1 +
>> >> 2 files changed, 20 insertions(+)
>> >>
>> >> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index
>> >> b4332b727e9c..1a60dede1a01 100644
>> >> --- a/arch/arm/mach-at91/pm.c
>> >> +++ b/arch/arm/mach-at91/pm.c
>> >> @@ -289,6 +289,24 @@ static void at91_ddr_standby(void)
>> >> at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1); }
>> >>
>> >> +static void at91_ddr_cache_standby(void) {
>> >> + u32 saved_lpr;
>> >> +
>> >> + flush_cache_all();
>> >> + outer_disable();
>> >> +
>> >> + saved_lpr = at91_ramc_read(0, AT91_DDRSDRC_LPR);
>> >> + at91_ramc_write(0, AT91_DDRSDRC_LPR, (saved_lpr &
>> >> + (~AT91_DDRSDRC_LPCB)) |
>> >> + AT91_DDRSDRC_LPCB_SELF_REFRESH);
>> >> +
>> >> + cpu_do_idle();
>> >> +
>> >> + at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr);
>> >> +
>> >> + outer_resume();
>> >> +}
>> >> +
>> >> /* We manage both DDRAM/SDRAM controllers, we need more than one
>> value to
>> >> * remember.
>> >> */
>> >> @@ -324,6 +342,7 @@ static const struct of_device_id const ramc_ids[]
>> __initconst = {
>> >> { .compatible = "atmel,at91sam9260-sdramc", .data =
>> at91sam9_sdram_standby },
>> >> { .compatible = "atmel,at91sam9g45-ddramc", .data = at91_ddr_standby },
>> >> { .compatible = "atmel,sama5d3-ddramc", .data =
>> >> at91_ddr_standby },
>> >> + { .compatible = "atmel,sama5d4-ddramc", .data =
>> >> + at91_ddr_cache_standby },
>> >> { /*sentinel*/ }
>> >> };
>> >>
>> >> diff --git a/drivers/memory/atmel-sdramc.c
>> >> b/drivers/memory/atmel-sdramc.c index b418b39af180..7e5c5c6c1348
>> >> 100644
>> >> --- a/drivers/memory/atmel-sdramc.c
>> >> +++ b/drivers/memory/atmel-sdramc.c
>> >> @@ -48,6 +48,7 @@ static const struct of_device_id atmel_ramc_of_match[]
>> = {
>> >> { .compatible = "atmel,at91sam9260-sdramc", .data =
>> &at91rm9200_caps, },
>> >> { .compatible = "atmel,at91sam9g45-ddramc", .data =
>> &at91sam9g45_caps, },
>> >> { .compatible = "atmel,sama5d3-ddramc", .data = &sama5d3_caps,
>> >> },
>> >> + { .compatible = "atmel,sama5d4-ddramc", .data = &sama5d3_caps,
>> >> + },
>> >> {},
>> >> };
>> >>
>> >> --
>> >> 2.11.0
>> >>
>> >
>> > --
>> > Alexandre Belloni, Free Electrons
>> > Embedded Linux and Kernel engineering
>> > http://free-electrons.com
>> >
>> > _______________________________________________
>> > linux-arm-kernel mailing list
>> > linux-arm-kernel at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle
From: Russell King - ARM Linux @ 2017-01-11 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACh+v5M3tU4WHMqAX0zm2H=zzwc0+XChyG1tnH2aHxaacm6C=A@mail.gmail.com>
On Wed, Jan 11, 2017 at 12:05:05PM +0100, Jean-Jacques Hiblot wrote:
> 2017-01-11 9:15 GMT+01:00 <Wenyou.Yang@microchip.com>:
> > Hi Jean-Jacques,
> >
> >> -----Original Message-----
> >> From: Jean-Jacques Hiblot [mailto:jjhiblot at gmail.com]
> >> Sent: 2017?1?11? 0:51
> >> To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> >> Cc: Wenyou Yang - A41535 <Wenyou.Yang@microchip.com>; Mark Rutland
> >> <mark.rutland@arm.com>; devicetree <devicetree@vger.kernel.org>; Russell
> >> King <linux@arm.linux.org.uk>; Wenyou Yang - A41535
> >> <Wenyou.Yang@microchip.com>; Nicolas Ferre <nicolas.ferre@atmel.com>;
> >> Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Rob Herring
> >> <robh+dt@kernel.org>; linux-arm-kernel at lists.infradead.org
> >> Subject: Re: [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle
> >>
> >> 2017-01-10 17:18 GMT+01:00 Alexandre Belloni
> >> <alexandre.belloni@free-electrons.com>:
> >> > I though a bit more about it, and I don't really like the new
> >> > compatible string. I don't feel this should be necessary.
> >> >
> >> > What about the following:
> >> >
> >> > diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index
> >> > b4332b727e9c..0333aca63e44 100644
> >> > --- a/arch/arm/mach-at91/pm.c
> >> > +++ b/arch/arm/mach-at91/pm.c
> >> > @@ -53,6 +53,7 @@ extern void at91_pinctrl_gpio_resume(void); static
> >> > struct {
> >> > unsigned long uhp_udp_mask;
> >> > int memctrl;
> >> > + bool has_l2_cache;
> >> > } at91_pm_data;
> >> >
> >> > void __iomem *at91_ramc_base[2];
> >> > @@ -267,6 +268,11 @@ static void at91_ddr_standby(void)
> >> > u32 lpr0, lpr1 = 0;
> >> > u32 saved_lpr0, saved_lpr1 = 0;
> >> >
> >>
> >> > + if (at91_pm_data.has_l2_cache) {
> >> > + flush_cache_all();
> >> what is the point of calling flush_cache_all() here ? Do we really care that dirty
> >> data in L1 is written to DDR ? I may be missing something but to me it's just extra
> >> latency.
> >
> > Are you mean use outer_flush_all() to flush all cache lines in the outer cache only?
>
> Yes that's what I meant. You see, you don't flush the cache for
> sama5d3 so it shouldn't be required either for sam5d4. You should be
> able to test it quickly and see if L1 flush is indeed required by
> replacing flush_cache_all() with outer_flush_all(). BTW is highly
> probable that L2 cache flush is done in outer_disable() so calling
> outer_flush_all() is probably no required.
Please don't. Read the comments in the code, and understand the APIs
that you're suggesting people use _before_ making the suggestion:
/**
* outer_flush_all - clean and invalidate all cache lines in the outer cache
*
* Note: depending on implementation, this may not be atomic - it must
* only be called with interrupts disabled and no other active outer
* cache masters.
*
* It is intended that this function is only used by implementations
* needing to override the outer_cache.disable() method due to security.
* (Some implementations perform this as a clean followed by an invalidate.)
*/
So, outer_flush_all() should not be called except from L2 cache code
implementing the outer_disable() function - it's not intended for
platforms to use.
There are, however, sadly three users of outer_flush_all() which have
crept in through arm-soc, that should be outer_disable() instead.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] coresight: STM: Balance enable/disable
From: Chunyan Zhang @ 2017-01-11 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110173637.GA12100@linaro.org>
On 11 January 2017 at 01:36, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> On Tue, Jan 10, 2017 at 11:21:55AM +0000, Suzuki K Poulose wrote:
>> The stm is automatically enabled when an application sets the policy
>> via ->link() call back by using coresight_enable(), which keeps the
>> refcount of the current users of the STM. However, the unlink() callback
>> issues stm_disable() directly, which leaves the STM turned off, without
>> the coresight layer knowing about it. This prevents any further uses
>> of the STM hardware as the coresight layer still thinks the STM is
>> turned on and doesn't issue an stm_enable(). Even manually enabling
>> the STM via sysfs can't really enable the hw.
>>
>> e.g,
>>
>> $ echo 1 > $CS_DEVS/$ETR/enable_sink
>> $ mkdir -p $CONFIG_FS/stp-policy/$source.0/stm_test/
>> $ echo 32768 65535 > $CONFIG_FS/stp-policy/$source.0/stm_test/channels
>> $ echo 64 > $CS_DEVS/$source/traceid
>> $ ./stm_app
>> Sending 64000 byte blocks of pattern 0 at 0us intervals
>> Success to map channel(32768~32783) to 0xffffa95fa000
>> Sending on channel 32768
>> $ dd if=/dev/$ETR of=~/trace.bin.1
>> 597+1 records in
>> 597+1 records out
>> 305920 bytes (306 kB) copied, 0.399952 s, 765 kB/s
>> $ ./stm_app
>> Sending 64000 byte blocks of pattern 0 at 0us intervals
>> Success to map channel(32768~32783) to 0xffff7e9e2000
>> Sending on channel 32768
>> $ dd if=/dev/$ETR of=~/trace.bin.2
>> 0+0 records in
>> 0+0 records out
>> 0 bytes (0 B) copied, 0.0232083 s, 0.0 kB/s
>>
>> Note that we don't get any data from the ETR for the second session.
>>
>> Also dmesg shows :
>>
>> [ 77.520458] coresight-tmc 20800000.etr: TMC-ETR enabled
>> [ 77.537097] coresight-replicator etr_replicator at 20890000: REPLICATOR enabled
>> [ 77.558828] coresight-replicator main_replicator at 208a0000: REPLICATOR enabled
>> [ 77.581068] coresight-funnel 208c0000.main_funnel: FUNNEL inport 0 enabled
>> [ 77.602217] coresight-tmc 20840000.etf: TMC-ETF enabled
>> [ 77.618422] coresight-stm 20860000.stm: STM tracing enabled
>> [ 139.554252] coresight-stm 20860000.stm: STM tracing disabled
>> # End of first tracing session
>> [ 146.351135] coresight-tmc 20800000.etr: TMC read start
>> [ 146.514486] coresight-tmc 20800000.etr: TMC read end
>> # Note that the STM is not turned on via stm_generic_link()->coresight_enable()
>> # and hence none of the components are turned on.
>> [ 152.479080] coresight-tmc 20800000.etr: TMC read start
>> [ 152.542632] coresight-tmc 20800000.etr: TMC read end
>>
>> This patch balances the unlink operation by using the coresight_disable(),
>> keeping the coresight layer in sync with the hardware state.
>>
>> Fixes: commit 237483aa5cf43 ("coresight: stm: adding driver for CoreSight STM component")
>> Cc: Pratik Patel <pratikp@codeaurora.org>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Cc: Chunyan Zhang <zhang.chunyan@linaro.org>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: stable at vger.kernel.org # 4.7+
>> Reported-by: Robert Walker <robert.walker@arm.com>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>> drivers/hwtracing/coresight/coresight-stm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
>> index 3524452..57b7330 100644
>> --- a/drivers/hwtracing/coresight/coresight-stm.c
>> +++ b/drivers/hwtracing/coresight/coresight-stm.c
>> @@ -356,7 +356,7 @@ static void stm_generic_unlink(struct stm_data *stm_data,
>> if (!drvdata || !drvdata->csdev)
>> return;
>>
>> - stm_disable(drvdata->csdev, NULL);
>> + coresight_disable(drvdata->csdev);
>
> This looks valid to me.
>
> Chunyan, any reason to use stm_disable() directly rather than calling it as part
> of the device OPS in coresight_disable()?
I don't think there's some special reason for this. I simply hadn't
noticed that these two operations didn't use two balanced functions.
Thanks,
Chunyan
>
> Thanks,
> Mathieu
>
>> }
>>
>> static phys_addr_t
>> --
>> 2.7.4
>>
^ 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