* [PATCH v8 3/6] mfd: at91-usart: added mfd driver for usart
From: Radu Pirea @ 2018-06-18 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618100829.13875-1-radu.pirea@microchip.com>
This mfd driver is just a wrapper over atmel_serial driver and
spi-at91-usart driver. Selection of one of the drivers is based on a
property from device tree. If the property is not specified, the default
driver is atmel_serial.
Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/Kconfig | 9 +++++
drivers/mfd/Makefile | 1 +
drivers/mfd/at91-usart.c | 71 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 81 insertions(+)
create mode 100644 drivers/mfd/at91-usart.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5aa194..a886672b960d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -99,6 +99,15 @@ config MFD_AAT2870_CORE
additional drivers must be enabled in order to use the
functionality of the device.
+config MFD_AT91_USART
+ tristate "AT91 USART Driver"
+ select MFD_CORE
+ help
+ Select this to get support for AT91 USART IP. This is a wrapper
+ over at91-usart-serial driver and usart-spi-driver. Only one function
+ can be used at a time. The choice is done at boot time by the probe
+ function of this MFD driver according to a device tree property.
+
config MFD_ATMEL_FLEXCOM
tristate "Atmel Flexcom (Flexible Serial Communication Unit)"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d9d2cf0d32ef..db1332aa96db 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -185,6 +185,7 @@ obj-$(CONFIG_MFD_SPMI_PMIC) += qcom-spmi-pmic.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
obj-$(CONFIG_MFD_TPS65090) += tps65090.o
obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
+obj-$(CONFIG_MFD_AT91_USART) += at91-usart.o
obj-$(CONFIG_MFD_ATMEL_FLEXCOM) += atmel-flexcom.o
obj-$(CONFIG_MFD_ATMEL_HLCDC) += atmel-hlcdc.o
obj-$(CONFIG_MFD_ATMEL_SMC) += atmel-smc.o
diff --git a/drivers/mfd/at91-usart.c b/drivers/mfd/at91-usart.c
new file mode 100644
index 000000000000..ba5754a1b7af
--- /dev/null
+++ b/drivers/mfd/at91-usart.c
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for AT91 USART
+ *
+ * Copyright (C) 2018 Microchip Technology
+ *
+ * Author: Radu Pirea <radu.pirea@microchip.com>
+ *
+ */
+
+#include <dt-bindings/mfd/at91-usart.h>
+
+#include <linux/module.h>
+#include <linux/mfd/core.h>
+#include <linux/property.h>
+
+static struct mfd_cell at91_usart_spi_subdev = {
+ .name = "at91_usart_spi",
+ .of_compatible = "microchip,at91sam9g45-usart-spi",
+ };
+
+static struct mfd_cell at91_usart_serial_subdev = {
+ .name = "atmel_usart_serial",
+ .of_compatible = "atmel,at91rm9200-usart-serial",
+ };
+
+static int at91_usart_mode_probe(struct platform_device *pdev)
+{
+ struct mfd_cell cell;
+ u32 opmode = AT91_USART_MODE_SERIAL;
+
+ device_property_read_u32(&pdev->dev, "atmel,usart-mode", &opmode);
+
+ switch (opmode) {
+ case AT91_USART_MODE_SPI:
+ cell = at91_usart_spi_subdev;
+ break;
+ case AT91_USART_MODE_SERIAL:
+ cell = at91_usart_serial_subdev;
+ break;
+ default:
+ dev_err(&pdev->dev, "atmel,usart-mode has an invalid value %u\n",
+ opmode);
+ return -EINVAL;
+ }
+
+ return devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO, &cell, 1,
+ NULL, 0, NULL);
+}
+
+static const struct of_device_id at91_usart_mode_of_match[] = {
+ { .compatible = "atmel,at91rm9200-usart" },
+ { .compatible = "atmel,at91sam9260-usart" },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, at91_flexcom_of_match);
+
+static struct platform_driver at91_usart_mfd = {
+ .probe = at91_usart_mode_probe,
+ .driver = {
+ .name = "at91_usart_mode",
+ .of_match_table = at91_usart_mode_of_match,
+ },
+};
+
+module_platform_driver(at91_usart_mfd);
+
+MODULE_AUTHOR("Radu Pirea <radu.pirea@microchip.com>");
+MODULE_DESCRIPTION("AT91 USART MFD driver");
+MODULE_LICENSE("GPL v2");
--
2.17.1
^ permalink raw reply related
* [PATCH v8 2/6] dt-bindings: add binding for atmel-usart in SPI mode
From: Radu Pirea @ 2018-06-18 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618100829.13875-1-radu.pirea@microchip.com>
This patch moves the bindings for serial from serial/atmel-usart.txt to
mfd/atmel-usart.txt and adds bindings for USART in SPI mode.
Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../bindings/{serial => mfd}/atmel-usart.txt | 25 +++++++++++++++++--
include/dt-bindings/mfd/at91-usart.h | 17 +++++++++++++
2 files changed, 40 insertions(+), 2 deletions(-)
rename Documentation/devicetree/bindings/{serial => mfd}/atmel-usart.txt (76%)
create mode 100644 include/dt-bindings/mfd/at91-usart.h
diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt b/Documentation/devicetree/bindings/mfd/atmel-usart.txt
similarity index 76%
rename from Documentation/devicetree/bindings/serial/atmel-usart.txt
rename to Documentation/devicetree/bindings/mfd/atmel-usart.txt
index 7c0d6b2f53e4..3b9e18642c3b 100644
--- a/Documentation/devicetree/bindings/serial/atmel-usart.txt
+++ b/Documentation/devicetree/bindings/mfd/atmel-usart.txt
@@ -1,6 +1,6 @@
* Atmel Universal Synchronous Asynchronous Receiver/Transmitter (USART)
-Required properties:
+Required properties for USART:
- compatible: Should be "atmel,<chip>-usart" or "atmel,<chip>-dbgu"
The compatible <chip> indicated will be the first SoC to support an
additional mode or an USART new feature.
@@ -11,7 +11,13 @@ Required properties:
Required elements: "usart"
- clocks: phandles to input clocks.
-Optional properties:
+Required properties for USART in SPI mode:
+- #size-cells : Must be <0>
+- #address-cells : Must be <1>
+- cs-gpios: chipselects (internal cs not supported)
+- atmel,usart-mode : Must be <USART_MODE_SPI> (found in dt-bindings/mfd/at91-usart.h)
+
+Optional properties in serial mode:
- atmel,use-dma-rx: use of PDC or DMA for receiving data
- atmel,use-dma-tx: use of PDC or DMA for transmitting data
- {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD line respectively.
@@ -62,3 +68,18 @@ Example:
dma-names = "tx", "rx";
atmel,fifo-size = <32>;
};
+
+- SPI mode:
+ #include <dt-bindings/mfd/at91-usart.h>
+
+ spi0: spi at f001c000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "atmel,at91rm9200-usart", "atmel,at91sam9260-usart";
+ atmel,usart-mode = <USART_MODE_SPI>;
+ reg = <0xf001c000 0x100>;
+ interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&usart0_clk>;
+ clock-names = "usart";
+ cs-gpios = <&pioB 3 0>;
+ };
diff --git a/include/dt-bindings/mfd/at91-usart.h b/include/dt-bindings/mfd/at91-usart.h
new file mode 100644
index 000000000000..2de5bc312e1e
--- /dev/null
+++ b/include/dt-bindings/mfd/at91-usart.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides macros for AT91 USART DT bindings.
+ *
+ * Copyright (C) 2018 Microchip Technology
+ *
+ * Author: Radu Pirea <radu.pirea@microchip.com>
+ *
+ */
+
+#ifndef __DT_BINDINGS_AT91_USART_H__
+#define __DT_BINDINGS_AT91_USART_H__
+
+#define AT91_USART_MODE_SERIAL 0
+#define AT91_USART_MODE_SPI 1
+
+#endif /* __DT_BINDINGS_AT91_USART_H__ */
--
2.17.1
^ permalink raw reply related
* [PATCH v8 1/6] MAINTAINERS: add at91 usart mfd driver
From: Radu Pirea @ 2018-06-18 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618100829.13875-1-radu.pirea@microchip.com>
Added entry for at91 usart mfd driver.
Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8e2a2fddbd19..12203d07c6af 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9160,6 +9160,7 @@ M: Richard Genoud <richard.genoud@gmail.com>
S: Maintained
F: drivers/tty/serial/atmel_serial.c
F: drivers/tty/serial/atmel_serial.h
+F: Documentation/devicetree/bindings/mfd/atmel-usart.txt
MICROCHIP / ATMEL DMA DRIVER
M: Ludovic Desroches <ludovic.desroches@microchip.com>
@@ -9192,6 +9193,14 @@ S: Supported
F: drivers/mtd/nand/raw/atmel/*
F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
+MICROCHIP AT91 USART MFD DRIVER
+M: Radu Pirea <radu.pirea@microchip.com>
+L: linux-kernel at vger.kernel.org
+S: Supported
+F: drivers/mfd/at91-usart.c
+F: include/dt-bindings/mfd/at91-usart.h
+F: Documentation/devicetree/bindings/mfd/atmel-usart.txt
+
MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
M: Woojung Huh <Woojung.Huh@microchip.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
--
2.17.1
^ permalink raw reply related
* [PATCH v8 0/6] Driver for at91 usart in spi mode
From: Radu Pirea @ 2018-06-18 10:08 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This is the second version of driver. I added a mfd driver which by
default probes atmel_serial driver and if in dt is specified to probe
the spi driver, then the spi-at91-usart driver will be probed. The
compatible for atmel_serial is now the compatible for at91-usart mfd
driver and compatilbe for atmel_serial driver was changed in order to
keep the bindings for serial as they are.
Changes in v8:
- fixed passing an empty mfd cell if "atmel,usart-mode" value is invalid
Changes in v7:
- synced up SPDIX license with module license
- numbering of usart modes starts from 0 insteand of 1
Changes in v6:
- removed unused compatible strings from serial and spi drivers
Changes in v5:
- fixed usage of stdout-path property with atmel_serial driver
Changes in v4:
- modified the spi driver to use cs gpio support form spi subsystem
- fixed dma transfers for serial driver
- squashed binding for spi and serial and moved them to mfd/atmel-usart.txt
Changes in v3:
- fixed spi slaves probing
Changes in v2:
- added at91-usart mfd driver
- modified spi-at91-usart driver to work as mfd driver child
- modified atmel_serial driver to work as mfd driver child
Changes in v1:
- added spi-at91-usart driver
Radu Pirea (6):
MAINTAINERS: add at91 usart mfd driver
dt-bindings: add binding for atmel-usart in SPI mode
mfd: at91-usart: added mfd driver for usart
MAINTAINERS: add at91 usart spi driver
spi: at91-usart: add driver for at91-usart as spi
tty/serial: atmel: change the driver to work under at91-usart mfd
.../bindings/{serial => mfd}/atmel-usart.txt | 25 +-
MAINTAINERS | 16 +
drivers/mfd/Kconfig | 9 +
drivers/mfd/Makefile | 1 +
drivers/mfd/at91-usart.c | 71 +++
drivers/spi/Kconfig | 9 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-at91-usart.c | 434 ++++++++++++++++++
drivers/tty/serial/Kconfig | 1 +
drivers/tty/serial/atmel_serial.c | 42 +-
include/dt-bindings/mfd/at91-usart.h | 17 +
11 files changed, 609 insertions(+), 17 deletions(-)
rename Documentation/devicetree/bindings/{serial => mfd}/atmel-usart.txt (76%)
create mode 100644 drivers/mfd/at91-usart.c
create mode 100644 drivers/spi/spi-at91-usart.c
create mode 100644 include/dt-bindings/mfd/at91-usart.h
--
2.17.1
^ permalink raw reply
* [PATCH v2] ARM: dts: rockchip: convert rk3288 to operating-points-v2
From: Heiko Stuebner @ 2018-06-18 10:05 UTC (permalink / raw)
To: linux-arm-kernel
Operating points need to be present in each cpu core using it, not only
the first one. With operating-points-v1 this would require duplicating
this table into each cpu node.
With opp-v2 we can share the same table on all nodes.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
changes in v2:
- adapt opp node names as suggested by Viresh
arch/arm/boot/dts/rk3288-veyron.dtsi | 36 +++++++-------
arch/arm/boot/dts/rk3288.dtsi | 70 ++++++++++++++++++++++------
2 files changed, 75 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 823c7ed47fcf..2075120cfc4d 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -91,22 +91,26 @@
&cpu0 {
cpu0-supply = <&vdd_cpu>;
- operating-points = <
- /* KHz uV */
- 1800000 1400000
- 1704000 1350000
- 1608000 1300000
- 1512000 1250000
- 1416000 1200000
- 1200000 1100000
- 1008000 1050000
- 816000 1000000
- 696000 950000
- 600000 900000
- 408000 900000
- 216000 900000
- 126000 900000
- >;
+};
+
+/* rk3288-c used in Veyron Chrome-devices has slightly changed OPPs */
+&cpu_opp_table {
+ /delete-node/ opp-312000000;
+
+ opp-1512000000 {
+ opp-microvolt = <1250000>;
+ };
+ opp-1608000000 {
+ opp-microvolt = <1300000>;
+ };
+ opp-1704000000 {
+ opp-hz = /bits/ 64 <1704000000>;
+ opp-microvolt = <1350000>;
+ };
+ opp-1800000000 {
+ opp-hz = /bits/ 64 <1800000000>;
+ opp-microvolt = <1400000>;
+ };
};
&emmc {
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 2a060c2dc383..7094f95b967f 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -60,21 +60,7 @@
compatible = "arm,cortex-a12";
reg = <0x500>;
resets = <&cru SRST_CORE0>;
- operating-points = <
- /* KHz uV */
- 1608000 1350000
- 1512000 1300000
- 1416000 1200000
- 1200000 1100000
- 1008000 1050000
- 816000 1000000
- 696000 950000
- 600000 900000
- 408000 900000
- 312000 900000
- 216000 900000
- 126000 900000
- >;
+ operating-points-v2 = <&cpu_opp_table>;
#cooling-cells = <2>; /* min followed by max */
clock-latency = <40000>;
clocks = <&cru ARMCLK>;
@@ -99,6 +85,60 @@
};
};
+ cpu_opp_table: cpu-opp-table {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-126000000 {
+ opp-hz = /bits/ 64 <126000000>;
+ opp-microvolt = <900000>;
+ };
+ opp-216000000 {
+ opp-hz = /bits/ 64 <216000000>;
+ opp-microvolt = <900000>;
+ };
+ opp-312000000 {
+ opp-hz = /bits/ 64 <312000000>;
+ opp-microvolt = <900000>;
+ };
+ opp-408000000 {
+ opp-hz = /bits/ 64 <408000000>;
+ opp-microvolt = <900000>;
+ };
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <900000>;
+ };
+ opp-696000000 {
+ opp-hz = /bits/ 64 <696000000>;
+ opp-microvolt = <950000>;
+ };
+ opp-816000000 {
+ opp-hz = /bits/ 64 <816000000>;
+ opp-microvolt = <1000000>;
+ };
+ opp-1008000000 {
+ opp-hz = /bits/ 64 <1008000000>;
+ opp-microvolt = <1050000>;
+ };
+ opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt = <1100000>;
+ };
+ opp-1416000000 {
+ opp-hz = /bits/ 64 <1416000000>;
+ opp-microvolt = <1200000>;
+ };
+ opp-1512000000 {
+ opp-hz = /bits/ 64 <1512000000>;
+ opp-microvolt = <1300000>;
+ };
+ opp-1608000000 {
+ opp-hz = /bits/ 64 <1608000000>;
+ opp-microvolt = <1350000>;
+ };
+ };
+
amba {
compatible = "simple-bus";
#address-cells = <2>;
--
2.17.0
^ permalink raw reply related
* [PATCH v2] mtd: atmel-quadspi: add suspend/resume hooks
From: Marek Vasut @ 2018-06-18 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618114920.654647c0@bbrezillon>
On 06/18/2018 11:49 AM, Boris Brezillon wrote:
> Hi Claudiu,
>
> The subject prefix should be "mtd: spi-nor: atmel-quadspi: ". No need
> to send a new version just for that, I'll fix it when applying the
> patch.
>
> Looks good otherwise. Marek, any objection? If not, can you add your
> Acked-by?
Will this work if you have ie. ubifs mounted on that QSPI NOR and you
suspect and resume during IO ? I think it would, but just curious if
there could be some problem.
> Thanks,
>
> Boris
>
> On Mon, 4 Jun 2018 11:46:33 +0300
> Claudiu Beznea <claudiu.beznea@microchip.com> wrote:
>
>> Implement suspend/resume hooks.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
>> ---
>>
>> Changes in v2:
>> - use __maybe_unused instead of #ifdef CONFIG_PM_SLEEP
>>
>> drivers/mtd/spi-nor/atmel-quadspi.c | 21 +++++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/atmel-quadspi.c b/drivers/mtd/spi-nor/atmel-quadspi.c
>> index 6c5708bacad8..ceaaef47f02e 100644
>> --- a/drivers/mtd/spi-nor/atmel-quadspi.c
>> +++ b/drivers/mtd/spi-nor/atmel-quadspi.c
>> @@ -737,6 +737,26 @@ static int atmel_qspi_remove(struct platform_device *pdev)
>> return 0;
>> }
>>
>> +static int __maybe_unused atmel_qspi_suspend(struct device *dev)
>> +{
>> + struct atmel_qspi *aq = dev_get_drvdata(dev);
>> +
>> + clk_disable_unprepare(aq->clk);
>> +
>> + return 0;
>> +}
>> +
>> +static int __maybe_unused atmel_qspi_resume(struct device *dev)
>> +{
>> + struct atmel_qspi *aq = dev_get_drvdata(dev);
>> +
>> + clk_prepare_enable(aq->clk);
>> +
>> + return atmel_qspi_init(aq);
>> +}
>> +
>> +static SIMPLE_DEV_PM_OPS(atmel_qspi_pm_ops, atmel_qspi_suspend,
>> + atmel_qspi_resume);
>>
>> static const struct of_device_id atmel_qspi_dt_ids[] = {
>> { .compatible = "atmel,sama5d2-qspi" },
>> @@ -749,6 +769,7 @@ static struct platform_driver atmel_qspi_driver = {
>> .driver = {
>> .name = "atmel_qspi",
>> .of_match_table = atmel_qspi_dt_ids,
>> + .pm = &atmel_qspi_pm_ops,
>> },
>> .probe = atmel_qspi_probe,
>> .remove = atmel_qspi_remove,
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 2/4] ARM: NOMMU: Postpone MPU activation till __after_proc_init
From: Vladimir Murzin @ 2018-06-18 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a266d2d9-44dc-16aa-6b35-7bbda080c4ef@kernel.org>
On 18/06/18 02:20, Greg Ungerer wrote:
> Hi Vladimir,
Hi Greg,
>
> On 12/02/2018 11:19:31, Vladimir Murzin wrote:
>> This patch postpone MPU activation till __after_proc_init (which is
>> placed in .text section) rather than doing it in __setup_mpu. It
>> allows us ignore used-only-once .head.text section while programming
>> PMSAv8 MPU (for PMSAv7 it stays covered anyway).
>>
>> Tested-by: Szemz? Andr?s <sza@xxxxxx>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@xxxxxxx>
>> ---
>> ?arch/arm/kernel/head-nommu.S | 45 ++++++++++++++++++++++----------------------
>> ?1 file changed, 22 insertions(+), 23 deletions(-)
>>
>> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
>> index aaa25a6..482936a 100644
>> --- a/arch/arm/kernel/head-nommu.S
>> +++ b/arch/arm/kernel/head-nommu.S
>> @@ -125,11 +125,24 @@ __secondary_data:
>> ? */
>> ???? .text
>> ?__after_proc_init:
>> +#ifdef CONFIG_ARM_MPU
>> +M_CLASS(movw??? r12, #:lower16:BASEADDR_V7M_SCB)
>> +M_CLASS(movt??? r12, #:upper16:BASEADDR_V7M_SCB)
>> +M_CLASS(ldr??? r3, [r12, 0x50])
>> +AR_CLASS(mrc??? p15, 0, r3, c0, c1, 4)????????? @ Read ID_MMFR0
>> +??? and??? r3, r3, #(MMFR0_PMSA)?????????? @ PMSA field
>> +??? teq??? r3, #(MMFR0_PMSAv7)???????????? @ PMSA v7
>> +#endif
>> ?#ifdef CONFIG_CPU_CP15
>> ???? /*
>> ????? * CP15 system control register value returned in r0 from
>> ????? * the CPU init function.
>> ????? */
>> +
>> +#ifdef CONFIG_ARM_MPU
>> +??? biceq??? r0, r0, #CR_BR??????????? @ Disable the 'default mem-map'
>> +??? orreq??? r0, r0, #CR_M??????????? @ Set SCTRL.M (MPU on)
>> +#endif
>> ?#if defined(CONFIG_ALIGNMENT_TRAP) && __LINUX_ARM_ARCH__ < 6
>> ???? orr??? r0, r0, #CR_A
>> ?#else
>> @@ -145,7 +158,15 @@ __after_proc_init:
>> ???? bic??? r0, r0, #CR_I
>> ?#endif
>> ???? mcr??? p15, 0, r0, c1, c0, 0??????? @ write control reg
>> +??? isb
>
> This is causing breakage for me when building with my patches to
> support the old Versatile platform in no-MMU mode:
>
> ? AS????? arch/arm/kernel/head-nommu.o
> arch/arm/kernel/head-nommu.S: Assembler messages:
> arch/arm/kernel/head-nommu.S:180: Error: selected processor does not support `isb' in ARM mode
> scripts/Makefile.build:417: recipe for target 'arch/arm/kernel/head-nommu.o' failed
> make[2]: *** [arch/arm/kernel/head-nommu.o] Error 1
> Makefile:1034: recipe for target 'arch/arm/kernel' failed
> make[1]: *** [arch/arm/kernel] Error 2
>
> You may recall that patch series from some time back:
> https://www.spinics.net/lists/arm-kernel/msg547602.html
>
> That patch series is pretty much unchanged, and I am running it
> on top of linux-4.18-rc1, using a gcc-5.4.0 based toolchain.
> (I really need to make an effort again to push this further...)
>
> Is the "isb" instruction valid on ARM926T?
Thanks for report and sorry for causing you problems. I've just sent
a patch to address that which I've quickly tested with
qemu-system-arm -M versatilepb ...
sure your patches were applied.
Cheers
Vladimir
>
> Regards
> Greg
>
>
>
^ permalink raw reply
* [PATCH 2/2] media: stm32-dcmi: add mandatory of_node_put() in success path
From: Hugues FRUCHET @ 2018-06-18 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528824138-19089-2-git-send-email-hofrat@osadl.org>
Hi Nicholas,
Thanks for patch.
BR,
Hugues.
On 06/12/2018 07:22 PM, Nicholas Mc Guire wrote:
> The endpoint allocated by of_graph_get_next_endpoint() needs an of_node_put()
> in both error and success path. As ep is not used the refcount decrement
> can be right after the last use of ep.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Acked-by: Hugues Fruchet <hugues.fruchet@st.com>
> Fixes: commit 37404f91ef8b ("[media] stm32-dcmi: STM32 DCMI camera interface driver")
> ---
>
> Problem located with an experimental coccinelle script
>
> Patch was compile tested with: x86_64_defconfig, MEDIA_SUPPORT=y
> MEDIA_CAMERA_SUPPORT=y, V4L_PLATFORM_DRIVERS=y, OF=y, COMPILE_TEST=y
> CONFIG_VIDEO_STM32_DCMI=y
> (There are a number of sparse warnings - not related to the changes though)
>
> Patch is on top of "[PATCH 1/2] media: stm32-dcmi: drop unneceeary while(1)
> loop" against 4.17.0 (localversion-next is next-20180608)
>
> drivers/media/platform/stm32/stm32-dcmi.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> index 70b81d2..542d148 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -1610,10 +1610,9 @@ static int dcmi_graph_parse(struct stm32_dcmi *dcmi, struct device_node *node)
> return -EINVAL;
>
> remote = of_graph_get_remote_port_parent(ep);
> - if (!remote) {
> - of_node_put(ep);
> + of_node_put(ep);
> + if (!remote)
> return -EINVAL;
> - }
>
> /* Remote node to connect */
> dcmi->entity.node = remote;
>
^ permalink raw reply
* [PATCH v2] mtd: atmel-quadspi: add suspend/resume hooks
From: Boris Brezillon @ 2018-06-18 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528101993-4772-1-git-send-email-claudiu.beznea@microchip.com>
Hi Claudiu,
The subject prefix should be "mtd: spi-nor: atmel-quadspi: ". No need
to send a new version just for that, I'll fix it when applying the
patch.
Looks good otherwise. Marek, any objection? If not, can you add your
Acked-by?
Thanks,
Boris
On Mon, 4 Jun 2018 11:46:33 +0300
Claudiu Beznea <claudiu.beznea@microchip.com> wrote:
> Implement suspend/resume hooks.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---
>
> Changes in v2:
> - use __maybe_unused instead of #ifdef CONFIG_PM_SLEEP
>
> drivers/mtd/spi-nor/atmel-quadspi.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/atmel-quadspi.c b/drivers/mtd/spi-nor/atmel-quadspi.c
> index 6c5708bacad8..ceaaef47f02e 100644
> --- a/drivers/mtd/spi-nor/atmel-quadspi.c
> +++ b/drivers/mtd/spi-nor/atmel-quadspi.c
> @@ -737,6 +737,26 @@ static int atmel_qspi_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static int __maybe_unused atmel_qspi_suspend(struct device *dev)
> +{
> + struct atmel_qspi *aq = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(aq->clk);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused atmel_qspi_resume(struct device *dev)
> +{
> + struct atmel_qspi *aq = dev_get_drvdata(dev);
> +
> + clk_prepare_enable(aq->clk);
> +
> + return atmel_qspi_init(aq);
> +}
> +
> +static SIMPLE_DEV_PM_OPS(atmel_qspi_pm_ops, atmel_qspi_suspend,
> + atmel_qspi_resume);
>
> static const struct of_device_id atmel_qspi_dt_ids[] = {
> { .compatible = "atmel,sama5d2-qspi" },
> @@ -749,6 +769,7 @@ static struct platform_driver atmel_qspi_driver = {
> .driver = {
> .name = "atmel_qspi",
> .of_match_table = atmel_qspi_dt_ids,
> + .pm = &atmel_qspi_pm_ops,
> },
> .probe = atmel_qspi_probe,
> .remove = atmel_qspi_remove,
^ permalink raw reply
* [PATCH] ARM: NOMMU: Use instr_sync instead of plain isb in common code
From: Vladimir Murzin @ 2018-06-18 9:48 UTC (permalink / raw)
To: linux-arm-kernel
Greg reported that commit 3c24121039c9d ("ARM: 8756/1: NOMMU: Postpone
MPU activation till __after_proc_init") is causing breakage for the
old Versatile platform in no-MMU mode (with out-of-tree patches):
AS arch/arm/kernel/head-nommu.o
arch/arm/kernel/head-nommu.S: Assembler messages:
arch/arm/kernel/head-nommu.S:180: Error: selected processor does not support `isb' in ARM mode
scripts/Makefile.build:417: recipe for target 'arch/arm/kernel/head-nommu.o' failed
make[2]: *** [arch/arm/kernel/head-nommu.o] Error 1
Makefile:1034: recipe for target 'arch/arm/kernel' failed
make[1]: *** [arch/arm/kernel] Error 2
Since the code is common for all NOMMU builds usage of the isb was a
bad idea (please, note that isb also used in MPU related code which is
fine because MPU has dependency on CPU_V7/CPU_V7M), instead use more
robust instr_sync assembler macro.
Fixes: 3c24121039c9 ("ARM: 8756/1: NOMMU: Postpone MPU activation till __after_proc_init")
Reported-by: Greg Ungerer <gerg@kernel.org>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/kernel/head-nommu.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index dd546d6..7a9b869 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -177,7 +177,7 @@ M_CLASS(streq r3, [r12, #PMSAv8_MAIR1])
bic r0, r0, #CR_I
#endif
mcr p15, 0, r0, c1, c0, 0 @ write control reg
- isb
+ instr_sync
#elif defined (CONFIG_CPU_V7M)
#ifdef CONFIG_ARM_MPU
ldreq r3, [r12, MPU_CTRL]
--
1.9.1
^ permalink raw reply related
* [PATCH] media: stm32-dcmi: simplify of_node_put usage
From: Hugues FRUCHET @ 2018-06-18 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528824196-19149-1-git-send-email-hofrat@osadl.org>
Hi Nicholas,
Thanks for patch,
On 06/12/2018 07:23 PM, Nicholas Mc Guire wrote:
> This does not fix any bug - this is just a code simplification. As
> np is not used after passing it to v4l2_fwnode_endpoint_parse() its
> refcount can be decremented immediately and at one location.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Acked-by: Hugues Fruchet <hugues.fruchet@st.com>
> ---
>
> Issue found during code reading.
>
> Patch was compile tested with: x86_64_defconfig, MEDIA_SUPPORT=y
> MEDIA_CAMERA_SUPPORT=y, V4L_PLATFORM_DRIVERS=y, OF=y, COMPILE_TEST=y
> CONFIG_VIDEO_STM32_DCMI=y
> (There are a few sparse warnings - but unrelated to the lines changed)
>
> Patch is against 4.17.0 (localversion-next is next-20180608)
>
> drivers/media/platform/stm32/stm32-dcmi.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> index 2e1933d..0b61042 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -1696,23 +1696,20 @@ static int dcmi_probe(struct platform_device *pdev)
> }
>
> ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(np), &ep);
> + of_node_put(np);
> if (ret) {
> dev_err(&pdev->dev, "Could not parse the endpoint\n");
> - of_node_put(np);
> return -ENODEV;
> }
>
> if (ep.bus_type == V4L2_MBUS_CSI2) {
> dev_err(&pdev->dev, "CSI bus not supported\n");
> - of_node_put(np);
> return -ENODEV;
> }
> dcmi->bus.flags = ep.bus.parallel.flags;
> dcmi->bus.bus_width = ep.bus.parallel.bus_width;
> dcmi->bus.data_shift = ep.bus.parallel.data_shift;
>
> - of_node_put(np);
> -
> irq = platform_get_irq(pdev, 0);
> if (irq <= 0) {
> dev_err(&pdev->dev, "Could not get irq\n");
>
^ permalink raw reply
* [PATCH v2 0/2] Add R8A77980/Condor PCIe support
From: Simon Horman @ 2018-06-18 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b37d458c-071a-833a-2057-be8a07c880be@cogentembedded.com>
On Thu, Jun 14, 2018 at 10:16:32PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20180614v2-v4.17' tag. We're adding the R8A77980 PCIe related
> device nodes and then enable PCIe on the Condor board. These patches depend
> on the R8A77980 PCIe PHY driver support in order to work properly. Note that
> in case the PCIe PHY driver is not enabled, the kernel will BUG() due to I/O
> space page leak in the PCIe driver...
Is that problem specific to the presence of PCIe nodes for
condor/r8a77980 or is it also true of other (R-Car) boards where
PCIe is enabled?
Regardless, it sounds like these patches expose a kernel bug.
Is it being fixed?
>
> [1/2] arm64: dts: renesas: r8a77980: add PCIe support
> [2/2] arm64: dts: renesas: condor: add PCIe support
>
> WBR, Sergei
>
^ permalink raw reply
* Charge counter on droid 4
From: Pavel Machek @ 2018-06-18 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618082858.GO112168@atomide.com>
On Mon 2018-06-18 01:28:58, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [180618 07:43]:
> >
> > So... there are mA, mAh values. Those come from hardware, and I
> > believe we should keep them.
> >
> > But there are also mW, mWh values, which are synthetic. Userland can
> > compute them from mV, mA values... and it is confusing that kernel
> > provides them. (My tendency was to start computing these synthetic
> > values in userland, to compare them with "real hardware" values from
> > kernel. But then I looked at kernel implementation, and realized they
> > are synthetic, tooo...)
>
> Hmm mWh value is based on the hardware sampled shunt
> values and number of samples gathered between the
> two readings. I'd rather call the calculated values
> based on userland reading mV and mA values "synthetic" :)
As far as I know, shunt resistors provide you with current (mA) not
power (mW) measurement... and cpcap-battery computes power_now as
voltage * current. I'd rather have kernel tell me "hardware can't
measure power" and do "voltage*current" computation in userspace.
So I'm proposing to apply patch below.
Best regards,
Pavel
+++ b/drivers/power/supply/cpcap-battery.c
@@ -490,24 +490,6 @@ static int cpcap_battery_get_property(struct power_supply *psy,
case POWER_SUPPLY_PROP_CHARGE_COUNTER:
val->intval = latest->counter_uah;
break;
- case POWER_SUPPLY_PROP_POWER_NOW:
- tmp = (latest->voltage / 10000) * latest->current_ua;
- val->intval = div64_s64(tmp, 100);
- break;
- case POWER_SUPPLY_PROP_POWER_AVG:
- if (cached) {
- tmp = cpcap_battery_cc_get_avg_current(ddata);
- tmp *= (latest->voltage / 10000);
- val->intval = div64_s64(tmp, 100);
- break;
- }
- sample = latest->cc.sample - previous->cc.sample;
- accumulator = latest->cc.accumulator - previous->cc.accumulator;
- tmp = cpcap_battery_cc_to_ua(ddata, sample, accumulator,
- latest->cc.offset);
- tmp *= ((latest->voltage + previous->voltage) / 20000);
- val->intval = div64_s64(tmp, 100);
- break;
case POWER_SUPPLY_PROP_CAPACITY_LEVEL:
if (cpcap_battery_full(ddata))
val->intval = POWER_SUPPLY_CAPACITY_LEVEL_FULL;
--
(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/20180618/be105e1c/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] media: stm32-dcmi: drop unnecessary while(1) loop
From: Hugues FRUCHET @ 2018-06-18 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528824138-19089-1-git-send-email-hofrat@osadl.org>
Hi Nicholas,
thanks for patch !
On 06/12/2018 07:22 PM, Nicholas Mc Guire wrote:
> The while(1) is effectively useless as all possible paths within it
> return thus there is no way to loop.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Acked-by: Hugues Fruchet <hugues.fruchet@st.com>
> ---
>
> This is not actually fixing any bug - the while(1){ } will not hurt here
> it is though simply unnecessary. Found during code review.
>
> The diff output is not very readable - essentially only the outer
> while(1){ } was removed.
>
> Patch was compile tested with: x86_64_defconfig, MEDIA_SUPPORT=y
> MEDIA_CAMERA_SUPPORT=y, V4L_PLATFORM_DRIVERS=y, OF=y, COMPILE_TEST=y
> CONFIG_VIDEO_STM32_DCMI=y
> (There are a number of sparse warnings - not related to the changes though)
>
> Patch is against 4.17.0 (localversion-next is next-20180608)
>
> drivers/media/platform/stm32/stm32-dcmi.c | 28 +++++++++++++---------------
> 1 file changed, 13 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> index 2e1933d..70b81d2 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -1605,23 +1605,21 @@ static int dcmi_graph_parse(struct stm32_dcmi *dcmi, struct device_node *node)
> struct device_node *ep = NULL;
> struct device_node *remote;
>
> - while (1) {
> - ep = of_graph_get_next_endpoint(node, ep);
> - if (!ep)
> - return -EINVAL;
> -
> - remote = of_graph_get_remote_port_parent(ep);
> - if (!remote) {
> - of_node_put(ep);
> - return -EINVAL;
> - }
> + ep = of_graph_get_next_endpoint(node, ep);
> + if (!ep)
> + return -EINVAL;
>
> - /* Remote node to connect */
> - dcmi->entity.node = remote;
> - dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> - dcmi->entity.asd.match.fwnode = of_fwnode_handle(remote);
> - return 0;
> + remote = of_graph_get_remote_port_parent(ep);
> + if (!remote) {
> + of_node_put(ep);
> + return -EINVAL;
> }
> +
> + /* Remote node to connect */
> + dcmi->entity.node = remote;
> + dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> + dcmi->entity.asd.match.fwnode = of_fwnode_handle(remote);
> + return 0;
> }
>
> static int dcmi_graph_init(struct stm32_dcmi *dcmi)
>
BR,
Hugues.
^ permalink raw reply
* [PATCH] soc: imx: gpc: fix PDN delay & improve readability
From: Lucas Stach @ 2018-06-18 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529312474617.59395@mixed-mode.de>
Am Montag, den 18.06.2018, 09:01 +0000 schrieb Sven Schmitt:
> - imx6_pm_domain_power_off(): reads iso and iso2sw
> ? from GPC_PGC_PUPSCR_OFFS which stores the power up delays
> ? => use GPC_PGC_PDNSCR_OFFS for the correct delays
>
> - remove unused #defines
>
> - struct imx_pm_domain: introduce cntr_pup_bit
> ? to replace usage of cntr_pdn_bit+1 in imx6_pm_domain_power_on()
I'm not sure I see the value in that one.
Otherwise this change looks fine.
Regards,
Lucas
>
> - GPC_PGC_DOMAIN_*: made consistent use of index defines
>
> Signed-off-by: Sven Schmitt <sven.schmitt@mixed-mode.de>
> ---
> ?drivers/soc/imx/gpc.c | 41 ++++++++++++++++++++---------------------
> ?1 file changed, 20 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index c4d35f32af8d..b92377c75ddf 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -24,15 +24,6 @@
> ?#define GPC_PGC_CTRL_OFFS 0x0
> ?#define GPC_PGC_PUPSCR_OFFS 0x4
> ?#define GPC_PGC_PDNSCR_OFFS 0x8
> -#define GPC_PGC_SW2ISO_SHIFT 0x8
> -#define GPC_PGC_SW_SHIFT 0x0
> -
> -#define GPC_PGC_GPU_PDN 0x260
> -#define GPC_PGC_GPU_PUPSCR 0x264
> -#define GPC_PGC_GPU_PDNSCR 0x268
> -
> -#define GPU_VPU_PUP_REQ BIT(1)
> -#define GPU_VPU_PDN_REQ BIT(0)
> ?
> ?#define GPC_CLK_MAX 6
> ?
> @@ -46,6 +37,7 @@ struct imx_pm_domain {
> ? int num_clks;
> ? unsigned int reg_offs;
> ? signed char cntr_pdn_bit;
> + signed char cntr_pup_bit;
> ? unsigned int ipg_rate_mhz;
> ? unsigned int flags;
> ?};
> @@ -66,7 +58,7 @@ static int imx6_pm_domain_power_off(struct
> generic_pm_domain *genpd)
> ? return -EBUSY;
> ?
> ? /* Read ISO and ISO2SW power down delays */
> - regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS,
> &val);
> + regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PDNSCR_OFFS,
> &val);
> ? iso = val & 0x3f;
> ? iso2sw = (val >> 8) & 0x3f;
> ?
> @@ -116,7 +108,7 @@ static int imx6_pm_domain_power_on(struct
> generic_pm_domain *genpd)
> ? sw2iso = (val >> 8) & 0x3f;
> ?
> ? /* Request GPC to power up domain */
> - val = BIT(pd->cntr_pdn_bit + 1);
> + val = BIT(pd->cntr_pup_bit);
> ? regmap_update_bits(pd->regmap, GPC_CNTR, val, val);
> ?
> ? /* Wait ISO + ISO2SW IPG clock cycles */
> @@ -241,22 +233,24 @@ static struct platform_driver
> imx_pgc_power_domain_driver = {
> ?};
> ?builtin_platform_driver(imx_pgc_power_domain_driver)
> ?
> -#define GPC_PGC_DOMAIN_ARM 0
> -#define GPC_PGC_DOMAIN_PU 1
> -#define GPC_PGC_DOMAIN_DISPLAY 2
> -
> ?static struct genpd_power_state imx6_pm_domain_pu_state = {
> ? .power_off_latency_ns = 25000,
> ? .power_on_latency_ns = 2000000,
> ?};
> ?
> +#define GPC_PGC_DOMAIN_ARM 0
> +#define GPC_PGC_DOMAIN_PU 1
> +#define GPC_PGC_DOMAIN_DISPLAY 2
> +#define GPC_PGC_DOMAIN_PCI 3
> +
> ?static struct imx_pm_domain imx_gpc_domains[] = {
> - {
> + [GPC_PGC_DOMAIN_ARM] {
> ? .base = {
> ? .name = "ARM",
> ? .flags = GENPD_FLAG_ALWAYS_ON,
> ? },
> - }, {
> + },
> + [GPC_PGC_DOMAIN_PU] {
> ? .base = {
> ? .name = "PU",
> ? .power_off = imx6_pm_domain_power_off,
> @@ -266,7 +260,9 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> ? },
> ? .reg_offs = 0x260,
> ? .cntr_pdn_bit = 0,
> - }, {
> + .cntr_pup_bit = 1,
> + },
> + [GPC_PGC_DOMAIN_DISPLAY] {
> ? .base = {
> ? .name = "DISPLAY",
> ? .power_off = imx6_pm_domain_power_off,
> @@ -274,7 +270,9 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> ? },
> ? .reg_offs = 0x240,
> ? .cntr_pdn_bit = 4,
> - }, {
> + .cntr_pup_bit = 5,
> + },
> + [GPC_PGC_DOMAIN_PCI] {
> ? .base = {
> ? .name = "PCI",
> ? .power_off = imx6_pm_domain_power_off,
> @@ -282,6 +280,7 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> ? },
> ? .reg_offs = 0x200,
> ? .cntr_pdn_bit = 6,
> + .cntr_pup_bit = 7,
> ? },
> ?};
> ?
> @@ -326,8 +325,8 @@ static const struct regmap_config
> imx_gpc_regmap_config = {
> ?};
> ?
> ?static struct generic_pm_domain *imx_gpc_onecell_domains[] = {
> - &imx_gpc_domains[0].base,
> - &imx_gpc_domains[1].base,
> + &imx_gpc_domains[GPC_PGC_DOMAIN_ARM].base,
> + &imx_gpc_domains[GPC_PGC_DOMAIN_PU].base,
> ?};
> ?
> ?static struct genpd_onecell_data imx_gpc_onecell_data = {
^ permalink raw reply
* [PATCH] ARM: dts: rockchip: convert rk3288 to operating-points-v2
From: Viresh Kumar @ 2018-06-18 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617131808.30283-1-heiko@sntech.de>
On 17-06-18, 15:18, Heiko Stuebner wrote:
> + cpu_opp_table: cpu-opp-table {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
Most of the platforms write it as "opp-126000000". Maybe follow the same
nomenclature ?
--
viresh
^ permalink raw reply
* [PATCH] soc: imx: gpc: fix PDN delay & improve readability
From: Sven Schmitt @ 2018-06-18 9:01 UTC (permalink / raw)
To: linux-arm-kernel
- imx6_pm_domain_power_off(): reads iso and iso2sw
from GPC_PGC_PUPSCR_OFFS which stores the power up delays
=> use GPC_PGC_PDNSCR_OFFS for the correct delays
- remove unused #defines
- struct imx_pm_domain: introduce cntr_pup_bit
to replace usage of cntr_pdn_bit+1 in imx6_pm_domain_power_on()
- GPC_PGC_DOMAIN_*: made consistent use of index defines
Signed-off-by: Sven Schmitt <sven.schmitt@mixed-mode.de>
---
drivers/soc/imx/gpc.c | 41 ++++++++++++++++++++---------------------
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index c4d35f32af8d..b92377c75ddf 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -24,15 +24,6 @@
#define GPC_PGC_CTRL_OFFS 0x0
#define GPC_PGC_PUPSCR_OFFS 0x4
#define GPC_PGC_PDNSCR_OFFS 0x8
-#define GPC_PGC_SW2ISO_SHIFT 0x8
-#define GPC_PGC_SW_SHIFT 0x0
-
-#define GPC_PGC_GPU_PDN 0x260
-#define GPC_PGC_GPU_PUPSCR 0x264
-#define GPC_PGC_GPU_PDNSCR 0x268
-
-#define GPU_VPU_PUP_REQ BIT(1)
-#define GPU_VPU_PDN_REQ BIT(0)
#define GPC_CLK_MAX 6
@@ -46,6 +37,7 @@ struct imx_pm_domain {
int num_clks;
unsigned int reg_offs;
signed char cntr_pdn_bit;
+ signed char cntr_pup_bit;
unsigned int ipg_rate_mhz;
unsigned int flags;
};
@@ -66,7 +58,7 @@ static int imx6_pm_domain_power_off(struct generic_pm_domain *genpd)
return -EBUSY;
/* Read ISO and ISO2SW power down delays */
- regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, &val);
+ regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PDNSCR_OFFS, &val);
iso = val & 0x3f;
iso2sw = (val >> 8) & 0x3f;
@@ -116,7 +108,7 @@ static int imx6_pm_domain_power_on(struct generic_pm_domain *genpd)
sw2iso = (val >> 8) & 0x3f;
/* Request GPC to power up domain */
- val = BIT(pd->cntr_pdn_bit + 1);
+ val = BIT(pd->cntr_pup_bit);
regmap_update_bits(pd->regmap, GPC_CNTR, val, val);
/* Wait ISO + ISO2SW IPG clock cycles */
@@ -241,22 +233,24 @@ static struct platform_driver imx_pgc_power_domain_driver = {
};
builtin_platform_driver(imx_pgc_power_domain_driver)
-#define GPC_PGC_DOMAIN_ARM 0
-#define GPC_PGC_DOMAIN_PU 1
-#define GPC_PGC_DOMAIN_DISPLAY 2
-
static struct genpd_power_state imx6_pm_domain_pu_state = {
.power_off_latency_ns = 25000,
.power_on_latency_ns = 2000000,
};
+#define GPC_PGC_DOMAIN_ARM 0
+#define GPC_PGC_DOMAIN_PU 1
+#define GPC_PGC_DOMAIN_DISPLAY 2
+#define GPC_PGC_DOMAIN_PCI 3
+
static struct imx_pm_domain imx_gpc_domains[] = {
- {
+ [GPC_PGC_DOMAIN_ARM] {
.base = {
.name = "ARM",
.flags = GENPD_FLAG_ALWAYS_ON,
},
- }, {
+ },
+ [GPC_PGC_DOMAIN_PU] {
.base = {
.name = "PU",
.power_off = imx6_pm_domain_power_off,
@@ -266,7 +260,9 @@ static struct imx_pm_domain imx_gpc_domains[] = {
},
.reg_offs = 0x260,
.cntr_pdn_bit = 0,
- }, {
+ .cntr_pup_bit = 1,
+ },
+ [GPC_PGC_DOMAIN_DISPLAY] {
.base = {
.name = "DISPLAY",
.power_off = imx6_pm_domain_power_off,
@@ -274,7 +270,9 @@ static struct imx_pm_domain imx_gpc_domains[] = {
},
.reg_offs = 0x240,
.cntr_pdn_bit = 4,
- }, {
+ .cntr_pup_bit = 5,
+ },
+ [GPC_PGC_DOMAIN_PCI] {
.base = {
.name = "PCI",
.power_off = imx6_pm_domain_power_off,
@@ -282,6 +280,7 @@ static struct imx_pm_domain imx_gpc_domains[] = {
},
.reg_offs = 0x200,
.cntr_pdn_bit = 6,
+ .cntr_pup_bit = 7,
},
};
@@ -326,8 +325,8 @@ static const struct regmap_config imx_gpc_regmap_config = {
};
static struct generic_pm_domain *imx_gpc_onecell_domains[] = {
- &imx_gpc_domains[0].base,
- &imx_gpc_domains[1].base,
+ &imx_gpc_domains[GPC_PGC_DOMAIN_ARM].base,
+ &imx_gpc_domains[GPC_PGC_DOMAIN_PU].base,
};
static struct genpd_onecell_data imx_gpc_onecell_data = {
--
2.17.1
^ permalink raw reply related
* [PATCH v2] mmc: sdhci-of-arasan: Add quirk for unstable clocks
From: Ulf Hansson @ 2018-06-18 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615081830.zrgx6arwn6ga27gu@laureti-dev>
On 15 June 2018 at 10:18, Helmut Grohne <h.grohne@intenta.de> wrote:
> Some controllers immediately report SDHCI_CLOCK_INT_STABLE after
> enabling the clock even when the clock is not stable. When used in
> conjunction with older/slower cards, this can result in:
>
> mmc0: error -84 whilst initialising SD card
>
> When the stable reporting is broken, we simply wait for the maximum
> stabilization period.
>
> Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
> ---
> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 2 ++
Please split this. DT doc should be a separate patch.
Otherwise this looks good to me.
Kind regards
Uffe
> drivers/mmc/host/sdhci-of-arasan.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+)
>
> Changes since v1 (RFC):
> * Use an arasan-specific quirk in the ->set_clock() callback as requested by
> Adrian Hunter.
>
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> index 60481bfc3d31..c0e0f04a8504 100644
> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -39,6 +39,8 @@ Optional Properties:
> - xlnx,fails-without-test-cd: when present, the controller doesn't work when
> the CD line is not connected properly, and the line is not connected
> properly. Test mode can be used to force the controller to function.
> + - xlnx,int-clock-stable-broken: when present, the controller always reports
> + that the internal clock is stable even when it is not.
>
> Example:
> sdhci at e0100000 {
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index c33a5f7393bd..f7fe26c75150 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -102,6 +102,9 @@ struct sdhci_arasan_data {
>
> /* Controller does not have CD wired and will not function normally without */
> #define SDHCI_ARASAN_QUIRK_FORCE_CDTEST BIT(0)
> +/* Controller immediately reports SDHCI_CLOCK_INT_STABLE after enabling the
> + * internal clock even when the clock isn't stable */
> +#define SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE BIT(1)
> };
>
> static const struct sdhci_arasan_soc_ctl_map rk3399_soc_ctl_map = {
> @@ -207,6 +210,16 @@ static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
>
> sdhci_set_clock(host, clock);
>
> + if (sdhci_arasan->quirks & SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE)
> + /*
> + * Some controllers immediately report SDHCI_CLOCK_INT_STABLE
> + * after enabling the clock even though the clock is not
> + * stable. Trying to use a clock without waiting here results
> + * in EILSEQ while detecting some older/slower cards. The
> + * chosen delay is the maximum delay from sdhci_set_clock.
> + */
> + msleep(20);
> +
> if (ctrl_phy) {
> phy_power_on(sdhci_arasan->phy);
> sdhci_arasan->is_phy_on = true;
> @@ -759,6 +772,9 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> if (of_property_read_bool(np, "xlnx,fails-without-test-cd"))
> sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_FORCE_CDTEST;
>
> + if (of_property_read_bool(np, "xlnx,int-clock-stable-broken"))
> + sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE;
> +
> pltfm_host->clk = clk_xin;
>
> if (of_device_is_compatible(pdev->dev.of_node,
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH V2 4/4] soc: imx: add SC firmware IPC and APIs
From: Leonard Crestez @ 2018-06-18 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529239789-26849-5-git-send-email-aisheng.dong@nxp.com>
On Sun, 2018-06-17 at 20:49 +0800, Dong Aisheng wrote:
> The System Controller Firmware (SCFW) is a low-level system function
> which runs on a dedicated Cortex-M core to provide power, clock, and
> resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> (QM, QP), and i.MX8QX (QXP, DX).
>
> This patch adds the SC firmware service APIs used by the system.
> It mainly consists of two parts:
> 1) Implementation of the IPC functions using MUs (client side).
> 2) SCU firmware services APIs implemented based on RPC calls
Most of the code in this patch is auto-generated but some of it (like
ipc.c) is not. Maybe that part should go to a separate patch?
It's otherwise difficult to tell which parts of this +5000 line patch
should be looked at by a human.
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: mailbox: provide imx-mailbox documentation
From: Leonard Crestez @ 2018-06-18 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615095107.24610-3-o.rempel@pengutronix.de>
On Fri, 2018-06-15 at 11:51 +0200, Oleksij Rempel wrote:
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> .../bindings/mailbox/imx-mailbox.txt | 35 +++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
A recent patch was posted which adds a similar but different binding
for the MU on 8qm/8qxp SOCs:
https://patchwork.kernel.org/patch/10468885/
Looking at manuals side-by-side the hardware seems to be the same so
there should be a single binding. Right?
That series I pointed to uses the MU to implement a communication with
a special "SCU" core which runs NXP firmware for handling details like
power management. However imx8 socs also have other MUs and M4 cores
for customers to use pretty exactly like they would on 7d.
The hardware exposes a very generic interface and my impression is that
drivers for the MU are actually highly specific to what is on the
other side of the MU. For example your driver code seems to be mapping
the 4 MU registers to separate "channels" but for SCU messages are
written in all registers in a round-robin way.
Shouldn't your MU-using driver be a separate node which references the
MU by phandle? Like in this patch:
https://patchwork.kernel.org/patch/10468887/
> diff --git a/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt b/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
> new file mode 100644
> index 000000000000..1577b86f1206
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
> @@ -0,0 +1,35 @@
> +i.MX Messaging Unit
> +===================
> +
> +The i.MX Messaging Unit (MU) contains two register sets: "A" and "B". In most
> +cases they are accessible from all Processor Units. On one hand, at least for
> +mailbox functionality, it makes no difference which application or processor is
> +using which set of the MU. On other hand, the register sets for each of the MU
> +parts are not identical.
> +
> +Required properties:
> +- compatible : Shell be one of:
> + "fsl,imx7s-mu-a" and "fsl,imx7s-mu-b" for i.MX7S or i.MX7D
> +- reg : physical base address of the mailbox and length of
> + memory mapped region.
> +- #mbox-cells: Common mailbox binding property to identify the number
> + of cells required for the mailbox specifier. Should be 1.
> +- interrupts : The interrupt number
> +- clocks : phandle to the input clock.
> +
> +Example:
> + mu0a: mailbox at 30aa0000 {
> + compatible = "fsl,imx7s-mu-a";
> + reg = <0x30aa0000 0x28>;
> + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> + #mbox-cells = <1>;
> + };
> +
> + mu0b: mailbox at 30ab0000 {
> + compatible = "fsl,imx7s-mu-b";
> + reg = <0x30ab0000 0x28>;
> + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> + #mbox-cells = <1>;
> + };
^ permalink raw reply
* [PATCH v3 00/14] ARM: pxa: switch to DMA slave maps
From: Boris Brezillon @ 2018-06-18 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617170217.24177-1-robert.jarzmik@free.fr>
Hi Robert,
On Sun, 17 Jun 2018 19:02:03 +0200
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> As I gathered almost all the required acks, this is an information only post
> before queuing to the PXA tree.
We'll need an immutable branch/tag containing those changes, just in
case other conflicting changes get submitted to the NAND driver.
Thanks,
Boris
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Boris Brezillon @ 2018-06-18 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180329131054.22506-1-peda@axentia.se>
On Thu, 29 Mar 2018 15:10:54 +0200
Peter Rosin <peda@axentia.se> wrote:
> On a sama5d31 with a Full-HD dual LVDS panel (132MHz pixel clock) NAND
> flash accesses have a tendency to cause display disturbances. Add a
> module param to disable DMA from the NAND controller, since that fixes
> the display problem for me.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
Miquel, can you queue this one to nand/next.
> ---
> drivers/mtd/nand/raw/atmel/nand-controller.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
> index b2f00b398490..2ff7a77c7b8e 100644
> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> @@ -129,6 +129,11 @@
> #define DEFAULT_TIMEOUT_MS 1000
> #define MIN_DMA_LEN 128
>
> +static bool atmel_nand_avoid_dma __read_mostly;
> +
> +MODULE_PARM_DESC(avoiddma, "Avoid using DMA");
> +module_param_named(avoiddma, atmel_nand_avoid_dma, bool, 0400);
> +
> enum atmel_nand_rb_type {
> ATMEL_NAND_NO_RB,
> ATMEL_NAND_NATIVE_RB,
> @@ -1977,7 +1982,7 @@ static int atmel_nand_controller_init(struct atmel_nand_controller *nc,
> return ret;
> }
>
> - if (nc->caps->has_dma) {
> + if (nc->caps->has_dma && !atmel_nand_avoid_dma) {
> dma_cap_mask_t mask;
>
> dma_cap_zero(mask);
^ permalink raw reply
* Charge counter on droid 4
From: Tony Lindgren @ 2018-06-18 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074023.GA16955@amd>
* Pavel Machek <pavel@ucw.cz> [180618 07:43]:
>
> So... there are mA, mAh values. Those come from hardware, and I
> believe we should keep them.
>
> But there are also mW, mWh values, which are synthetic. Userland can
> compute them from mV, mA values... and it is confusing that kernel
> provides them. (My tendency was to start computing these synthetic
> values in userland, to compare them with "real hardware" values from
> kernel. But then I looked at kernel implementation, and realized they
> are synthetic, tooo...)
Hmm mWh value is based on the hardware sampled shunt
values and number of samples gathered between the
two readings. I'd rather call the calculated values
based on userland reading mV and mA values "synthetic" :)
Regards,
Tony
^ permalink raw reply
* [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"
From: Maxime Ripard @ 2018-06-18 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613081647.31183-1-paul.kocialkowski@bootlin.com>
On Wed, Jun 13, 2018 at 10:16:47AM +0200, Paul Kocialkowski wrote:
> This reverts commit 2c17a4368aad2b88b68e4390c819e226cf320f70.
>
> The offending commit triggers a run-time fault when accessing the panel
> element of the sun4i_tcon structure when no such panel is attached.
>
> It was apparently assumed in said commit that a panel is always used with
> the TCON. Although it is often the case, this is not always true.
> For instance a bridge might be used instead of a panel.
>
> This issue was discovered using an A13-OLinuXino, that uses the TCON
> in RGB mode for a simple DAC-based VGA bridge.
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Applied, thanks
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180618/9bd97802/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/2] ARM: imx_v6_v7_defconfig: Enable imx6qdl-sabreauto sensors
From: Leonard Crestez @ 2018-06-18 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1be8dc197f842d3be31a15315594a25c8ad8f298.1529309235.git.leonard.crestez@nxp.com>
CONFIG_SENSORS_ISL29018 supports isil,il29023 light sensor
CONFIG_MMA8452 supports fsl,mma8451 accelerometer
CONFIG_MAG3110 for fsl,mag3110 is already enabled
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
Changes since v1:
* Added "ARM:" prefix in title (Fabio)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f70507ab91ee..a647cbb0e59f 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -372,12 +372,14 @@ CONFIG_MXS_DMA=y
CONFIG_STAGING=y
CONFIG_STAGING_MEDIA=y
CONFIG_VIDEO_IMX_MEDIA=y
CONFIG_COMMON_CLK_PWM=y
CONFIG_IIO=y
+CONFIG_MMA8452=y
CONFIG_IMX7D_ADC=y
CONFIG_VF610_ADC=y
+CONFIG_SENSORS_ISL29018=y
CONFIG_MAG3110=y
CONFIG_MPL3115=y
CONFIG_PWM=y
CONFIG_PWM_FSL_FTM=y
CONFIG_PWM_IMX=y
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox