* Re: [PATCH 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Gregory CLEMENT @ 2017-01-05 12:55 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring, Mark Rutland,
Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <5a40436a-ebad-8a94-c5c5-546ba33ba545-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Florian,
On mer., janv. 04 2017, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 01/04/2017 09:23 AM, Gregory CLEMENT wrote:
>> Hi Florian,
>>
>> On lun., janv. 02 2017, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net:
>>> dsa: Document new binding"). The legacy binding node is kept included, but is
>>> marked disabled.
>>>
>>
>> I tested this patch on mvebu/dt (I needed to reduce the context to apply
>> the patch due to the changes made by Russell King on this file). I also
>> set the status of the old binding to "disable" (instead of "okay").
>
> Yes, that needs fixing, thanks for mentioning that.
>
>>
>> It seems to work with the limited test did:
>> ifconfig eth1 up
>> udhcpc -i lan1
>> iperf -c mylaptop
>>
>> (same for lan4)
>>
>> However is there a way to be sure that the new binding is used?
>
> The best way is probably to make sure that your switch device appears
> parented to the MDIO bus driver under /sys/class/mdio_bus/*mvmdio*.
> Alternatively, if you see a message like:
>
> DSA: switch 0 0 parsed
>
> in your dmesg, that would also be indicative of using the new binding
> and corresponding code.
So it's OK I had this message.
Gregory
>
> Thanks a lot for trying that out!
> --
> Florian
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] ARM: dts: armada388-clearfog: add phy reset gpio-hog
From: Gregory CLEMENT @ 2017-01-05 13:04 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Rutland, Andrew Lunn, Jason Cooper, devicetree, Rob Herring,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20170105103134.GS14217@n2100.armlinux.org.uk>
Hi Russell King,
On jeu., janv. 05 2017, Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> On Thu, Jan 05, 2017 at 11:29:48AM +0100, Gregory CLEMENT wrote:
>> Hi Russell King,
>>
>> On jeu., janv. 05 2017, Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
>>
>> > On Wed, Jan 04, 2017 at 05:26:08PM +0100, Gregory CLEMENT wrote:
>> >> Hi Russell,
>> >>
>> >> On lun., janv. 02 2017, Russell King <rmk+kernel@armlinux.org.uk> wrote:
>> >>
>> >>
>> >> It would be nice to have some word here about this patch. Especially why
>> >> we need it now. I guess it is for being less dependent on the
>> >> initialization done by the bootloader but maybe you have other reasons.
>> >
>> > I'm not sure I follow. This is adding it to the new platform, not the
>> > old one. I guess I should've rolled this into the patch creating the
>> > clearfog-base dts file, and this question wouldn't have come up.
>> >
>>
>> Indeed I missed the fact that it was on the new board as all the other
>> patches were related to the common part.
>>
>> Do you agree that I squash this patch into the "ARM: dts:
>> armada388-clearfog: add base model DTS file" patch?
>
> Yep, thanks.
It's done and it is also part of mvebu/for-next now.
Gregory
>
> --
> 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.
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCHv2 0/5] Support for Marvell switches with integrated CPUs
From: Andrew Lunn @ 2017-01-05 13:09 UTC (permalink / raw)
To: Chris Packham
Cc: Mark Rutland, Geert Uytterhoeven, Michael Turquette,
Laxman Dewangan, linux-clk@vger.kernel.org, Florian Fainelli,
Juri Lelli, Russell King, Thierry Reding, Linus Walleij,
Sebastian Hesselbarth, devicetree@vger.kernel.org, Jason Cooper,
Arnd Bergmann, Kalyan Kinthada, Rob Herring, Gregory Clement,
linux-arm-kernel@lists.infradead.org, Thomas Petazzoni
In-Reply-To: <185147a37cab4d7eaea5f79d86cc9451@svr-chch-ex1.atlnz.lc>
> I'd love to see a switchdev driver but it's a huge task (and no I'm not
> committing to writing it). As it stands Marvell ship a switch SDK
> largely executes in userspace with a small kernel module providing some
> linkage to the underlying hardware.
Is there any similarity to the mv88e6xxx family?
If it was similar registers, just a different access mechanising, we
could probably extend the mv88e6xxx to support MMIO as well as MDIO.
Andrew
^ permalink raw reply
* [PATCH] iio: accel: st_accel: handle deprecated bindings
From: Linus Walleij @ 2017-01-05 13:32 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: Linus Walleij, devicetree-u79uwXL29TY76Z2rM5mHXA
The earlier deployed LIS3LV02DL driver had already defined a few
DT bindings that need to be supported by the new more generic
driver and listed as compatible but deprecated bindings in the
documentation.
After this we can start to activate the new driver with the old
systems where applicable.
As part of this enablement: make us depend on the old drivers
not being in use so we don't get a kernel with two competing
drivers.
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/iio/accel/lis302.txt | 2 +-
Documentation/devicetree/bindings/iio/st-sensors.txt | 2 ++
drivers/iio/accel/Kconfig | 2 ++
drivers/iio/accel/st_accel_i2c.c | 5 +++++
drivers/iio/accel/st_accel_spi.c | 9 +++++++++
5 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/accel/lis302.txt b/Documentation/devicetree/bindings/iio/accel/lis302.txt
index 2a19bff9693f..dfdce67826ba 100644
--- a/Documentation/devicetree/bindings/iio/accel/lis302.txt
+++ b/Documentation/devicetree/bindings/iio/accel/lis302.txt
@@ -5,7 +5,7 @@ that apply in on the generic device (independent from the bus).
Required properties for the SPI bindings:
- - compatible: should be set to "st,lis3lv02d_spi"
+ - compatible: should be set to "st,lis3lv02d-spi"
- reg: the chipselect index
- spi-max-frequency: maximal bus speed, should be set to 1000000 unless
constrained by external circuitry
diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt b/Documentation/devicetree/bindings/iio/st-sensors.txt
index c040c9ad1889..eaa8fbba34e2 100644
--- a/Documentation/devicetree/bindings/iio/st-sensors.txt
+++ b/Documentation/devicetree/bindings/iio/st-sensors.txt
@@ -27,6 +27,8 @@ standard bindings from pinctrl/pinctrl-bindings.txt.
Valid compatible strings:
Accelerometers:
+- st,lis3lv02d (deprecated, use st,lis3lv02dl-accel)
+- st,lis302dl-spi (deprecated, use st,lis3lv02dl-accel)
- st,lis3lv02dl-accel
- st,lsm303dlh-accel
- st,lsm303dlhc-accel
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index c68bdb649005..ea295fe0f561 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -140,11 +140,13 @@ config IIO_ST_ACCEL_3AXIS
config IIO_ST_ACCEL_I2C_3AXIS
tristate
+ depends on !SENSORS_LIS3_I2C
depends on IIO_ST_ACCEL_3AXIS
depends on IIO_ST_SENSORS_I2C
config IIO_ST_ACCEL_SPI_3AXIS
tristate
+ depends on !SENSORS_LIS3_SPI
depends on IIO_ST_ACCEL_3AXIS
depends on IIO_ST_SENSORS_SPI
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index c0f8867aa1ea..99a7cdbe3d5d 100644
--- a/drivers/iio/accel/st_accel_i2c.c
+++ b/drivers/iio/accel/st_accel_i2c.c
@@ -21,6 +21,11 @@
#ifdef CONFIG_OF
static const struct of_device_id st_accel_of_match[] = {
{
+ /* An older compatible */
+ .compatible = "st,lis3lv02d",
+ .data = LIS3LV02DL_ACCEL_DEV_NAME,
+ },
+ {
.compatible = "st,lis3lv02dl-accel",
.data = LIS3LV02DL_ACCEL_DEV_NAME,
},
diff --git a/drivers/iio/accel/st_accel_spi.c b/drivers/iio/accel/st_accel_spi.c
index c25ac50d4600..29a15f27a51b 100644
--- a/drivers/iio/accel/st_accel_spi.c
+++ b/drivers/iio/accel/st_accel_spi.c
@@ -65,9 +65,18 @@ static const struct spi_device_id st_accel_id_table[] = {
};
MODULE_DEVICE_TABLE(spi, st_accel_id_table);
+#ifdef CONFIG_OF
+static const struct of_device_id lis302dl_spi_dt_ids[] = {
+ { .compatible = "st,lis302dl-spi" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, lis302dl_spi_dt_ids);
+#endif
+
static struct spi_driver st_accel_driver = {
.driver = {
.name = "st-accel-spi",
+ .of_match_table = of_match_ptr(lis302dl_spi_dt_ids),
},
.probe = st_accel_spi_probe,
.remove = st_accel_spi_remove,
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v4 1/4] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Cédric Le Goater @ 2017-01-05 13:39 UTC (permalink / raw)
To: Boris Brezillon, Cyrille Pitchen
Cc: Mark Rutland, devicetree, Richard Weinberger, Marek Vasut,
Rob Herring, linux-mtd, Joel Stanley, Cyrille Pitchen,
Brian Norris, David Woodhouse
In-Reply-To: <20170104185005.7fcafd2d@bbrezillon>
Hello Cyrille, Boris
On 01/04/2017 06:50 PM, Boris Brezillon wrote:
> Cyrille, Cédric,
>
> On Wed, 4 Jan 2017 15:52:07 +0100
> Cyrille Pitchen <cyrille.pitchen@atmel.com> wrote:
>
>>>
>>>> Anyway, since the review is done now, on my side I won't ask you to remove
>>>> or split the support of the 'Command' mode in a separated patch.
>>>> I let you do as you want, if it help you to introduce some part of the
>>>> support of this 'Command' mode now even if not completed yet, no problem on
>>>> my side :)
>>>>
>>>> I was just giving you some pieces of advice for the next time if you want
>>>> to speed up the review of another patch introducing new features.
>>>>
>>>> However, I will just ask you one more version handling the dummy cycles
>>>> properly as it would help us for the global maintenance of the spi-nor
>>>> subsystem. This is the only mandatory modification I ask you, after that I
>>>> think it would be ok for me and since Marek has already reviewed your
>>>> driver, it would be ready to be merged into the spi-nor tree.
>>>
>>> Sending a v5 which should address your comments.
>>>
>>> I have removed the label property and will start a new thread in the
>>> topic. Any hints on which binding we could add this label prop ?
>>>
>>
>> Here I will provide just few thoughts about this new DT property. I don't
>> pretend this is what should be done. I still think other mtd maintainers
>> should be involved to discuss this topic.
>>
>> First the DT property name "label" sounds good to me: it is consistent with
>> "label" DT property used to name mtd partitions. However, I don't think it
>> should be documented in jedec,spi-nor.txt but *maybe* in partition.txt as
>> the purpose of this new DT property seems very close to the "label"
>> property of partition nodes: let's think about some hard-disk device
>> (/dev/sda) and its partition devices (/dev/sdaX).
yes this is very similar. I first looked at introducing a name to
an overall containing partition but the partition binding is not
designed for that. There are constraints on the start address and
the size which does not fit the purpose.
> Hm, partition.txt may not be appropriate here. We're not documenting
> the MTD partition binding, but the MTD device one. Maybe we should
> create mtd.txt and put all generic MTD dev properties here.
>>
>> Besides, the concept of this memory label is not limited to SPI NOR but
>> could also apply to NAND memories or any other MTD handled memories.
>
> Definitely. Actually I think I'll need that for the Atmel NAND
> controller driver rework I'm currently working on, to keep mtdparts
> parser happy even after changing the NAND device naming scheme.
>
>> Hence the DT property might be handled by drivers/mtd/ofpart.c instead of
>> being handled by spi-nor.c or by each SPI NOR memory controller driver.
>
> Actually, that could be done at the mtdcore level in
> mtd_set_dev_defaults() [1].
that would be perfect.
>> Finally, I guess we should take time to discuss and all agree what should
>> be done precisely before introducing a new DT property because one general
>> rule with DTB files is that users should be able to update their kernel
>> image (zImage, uImage, ...) without changing their DTB: device trees should
>> be backward compatible. Hence if we make a wrong choice today, we are
>> likely to have to live with it and keep supporting that bad choice.
>
> Rob already acked the patch, so, if all MTD maintainers agree that this
> new property is acceptable, we should be fine ;-).
yes but we would need to move the binding property to another file.
What I sent applied to "jedec,spi-nor" and we want to generalize the
property to other devices.
>> Anyway, maybe you could describe a little bit your use case; what you
>> intend to do with this label from you userspace application.
>
> Here is mine: I want the mtdparts parser to work correctly with
> existing bootloaders even after changing the NAND device naming scheme
> to allow one NAND controller to expose multiple devices.
>
> Current naming scheme: NAND device name is always atmel_nand
> New naming sheme: atmel-nand.%d where %d is replaced by the CS line
> number the NAND device is connected too.
>
> Also note that it's easier to refer to a flash device by it's purpose
> (like System-firmware in Cedric's example) rather than the controller
> CS line this device is connected to.
Yes this is what we use. There are possibly other ways but adding
a label property at the flash device level is a practical solution [1]
So here's our need. Systems can have multiple chips for different
purposes :
- BMC Firmware
- BMC Firmware golden image
- Host Firmware
- Video Firmware
- etc
The goal is to simplify the identification of a specific chip for
userspace tools or daemons which need to select the appropriate
mtd device.
Thanks,
C.
[1] https://github.com/openbmc/linux/blob/dev-4.7/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts#L36
> Regards,
>
> Boris
>
> [1]http://code.bulix.org/p019ah-107877
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCHv3 0/8] Add support for STM32 RTC
From: Amelie Delaunay @ 2017-01-05 13:43 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Gabriel Fernandez,
Amelie Delaunay
v3:
- rework set_alarm
- return platform_get_irq error code instead of -ENOENT
v2:
- remove clock-names and interrupt-names from bindings
- remove unuseful headers
- clean stm32_rtc structure
- replace stm32_rtc_readl/_writel by readl/writel_relaxed
- use threaded IRQ
- rework set_alarm
- add various comments
- select COMPILE_TEST and REGMAP_MMIO
This patchset adds support for the STM32 Real-Time Clock.
This RTC is an independent BCD timer/counter and provides a time-of-day
clock/calendar with programmable alarm interrupt.
RTC calendar can be driven by three clock sources LSE, LSI or HSE.
Amelie Delaunay (8):
ARM: dts: stm32: set HSE_RTC clock frequency to 1 MHz on stm32f429
dt-bindings: document the STM32 RTC bindings
rtc: add STM32 RTC driver
ARM: dts: stm32: Add RTC support for STM32F429 MCU
ARM: dts: stm32: enable RTC on stm32f429-disco
ARM: dts: stm32: enable RTC on stm32f469-disco
ARM: dts: stm32: enable RTC on stm32429i-eval
ARM: configs: stm32: Add RTC support in STM32 defconfig
.../devicetree/bindings/rtc/st,stm32-rtc.txt | 27 +
arch/arm/boot/dts/stm32429i-eval.dts | 4 +
arch/arm/boot/dts/stm32f429-disco.dts | 6 +
arch/arm/boot/dts/stm32f429.dtsi | 16 +
arch/arm/boot/dts/stm32f469-disco.dts | 4 +
arch/arm/configs/stm32_defconfig | 2 +
drivers/rtc/Kconfig | 11 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-stm32.c | 776 +++++++++++++++++++++
9 files changed, 847 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
create mode 100644 drivers/rtc/rtc-stm32.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCHv3 1/8] ARM: dts: stm32: set HSE_RTC clock frequency to 1 MHz on stm32f429
From: Amelie Delaunay @ 2017-01-05 13:43 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: devicetree, Amelie Delaunay, rtc-linux, linux-kernel,
Gabriel Fernandez, linux-arm-kernel
In-Reply-To: <1483623809-29937-1-git-send-email-amelie.delaunay@st.com>
This patch set HSE_RTC clock frequency to 1 MHz, as the clock supplied to
the RTC must be 1 MHz.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index b077f99..d195ccf 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -371,6 +371,8 @@
reg = <0x40023800 0x400>;
clocks = <&clk_hse>, <&clk_i2s_ckin>;
st,syscfg = <&pwrcfg>;
+ assigned-clocks = <&rcc 1 CLK_HSE_RTC>;
+ assigned-clock-rates = <1000000>;
};
dma1: dma-controller@40026000 {
--
1.9.1
^ permalink raw reply related
* [PATCHv3 2/8] dt-bindings: document the STM32 RTC bindings
From: Amelie Delaunay @ 2017-01-05 13:43 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: devicetree, Amelie Delaunay, rtc-linux, linux-kernel,
Gabriel Fernandez, linux-arm-kernel
In-Reply-To: <1483623809-29937-1-git-send-email-amelie.delaunay@st.com>
This patch adds documentation of device tree bindings for the STM32 RTC.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/rtc/st,stm32-rtc.txt | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
new file mode 100644
index 0000000..e2837b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
@@ -0,0 +1,27 @@
+STM32 Real Time Clock
+
+Required properties:
+- compatible: "st,stm32-rtc".
+- reg: address range of rtc register set.
+- clocks: reference to the clock entry ck_rtc.
+- interrupt-parent: phandle for the interrupt controller.
+- interrupts: rtc alarm interrupt.
+- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
+ (RTC registers) write protection.
+
+Optional properties (to override default ck_rtc parent clock):
+- assigned-clocks: reference to the ck_rtc clock entry.
+- assigned-clock-parents: phandle of the new parent clock of ck_rtc.
+
+Example:
+
+ rtc: rtc@40002800 {
+ compatible = "st,stm32-rtc";
+ reg = <0x40002800 0x400>;
+ clocks = <&rcc 1 CLK_RTC>;
+ assigned-clocks = <&rcc 1 CLK_RTC>;
+ assigned-clock-parents = <&rcc 1 CLK_LSE>;
+ interrupt-parent = <&exti>;
+ interrupts = <17 1>;
+ st,syscfg = <&pwrcfg>;
+ };
--
1.9.1
^ permalink raw reply related
* [PATCHv3 3/8] rtc: add STM32 RTC driver
From: Amelie Delaunay @ 2017-01-05 13:43 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: devicetree, Amelie Delaunay, rtc-linux, linux-kernel,
Gabriel Fernandez, linux-arm-kernel
In-Reply-To: <1483623809-29937-1-git-send-email-amelie.delaunay@st.com>
This patch adds support for the STM32 RTC.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
drivers/rtc/Kconfig | 11 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-stm32.c | 776 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 788 insertions(+)
create mode 100644 drivers/rtc/rtc-stm32.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e859d14..11eb28a 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1706,6 +1706,17 @@ config RTC_DRV_PIC32
This driver can also be built as a module. If so, the module
will be called rtc-pic32
+config RTC_DRV_STM32
+ tristate "STM32 RTC"
+ select REGMAP_MMIO
+ depends on ARCH_STM32 || COMPILE_TEST
+ help
+ If you say yes here you get support for the STM32 On-Chip
+ Real Time Clock.
+
+ This driver can also be built as a module, if so, the module
+ will be called "rtc-stm32".
+
comment "HID Sensor RTC drivers"
config RTC_DRV_HID_SENSOR_TIME
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 1ac694a..87bd9cc 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -144,6 +144,7 @@ obj-$(CONFIG_RTC_DRV_SNVS) += rtc-snvs.o
obj-$(CONFIG_RTC_DRV_SPEAR) += rtc-spear.o
obj-$(CONFIG_RTC_DRV_STARFIRE) += rtc-starfire.o
obj-$(CONFIG_RTC_DRV_STK17TA8) += rtc-stk17ta8.o
+obj-$(CONFIG_RTC_DRV_STM32) += rtc-stm32.o
obj-$(CONFIG_RTC_DRV_STMP) += rtc-stmp3xxx.o
obj-$(CONFIG_RTC_DRV_ST_LPC) += rtc-st-lpc.o
obj-$(CONFIG_RTC_DRV_SUN4V) += rtc-sun4v.o
diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
new file mode 100644
index 0000000..fdd3a31
--- /dev/null
+++ b/drivers/rtc/rtc-stm32.c
@@ -0,0 +1,776 @@
+/*
+ * Copyright (C) Amelie Delaunay 2016
+ * Author: Amelie Delaunay <amelie.delaunay@st.com>
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include <linux/bcd.h>
+#include <linux/clk.h>
+#include <linux/iopoll.h>
+#include <linux/ioport.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/rtc.h>
+#include <linux/spinlock.h>
+
+#define DRIVER_NAME "stm32_rtc"
+
+/* STM32 RTC registers */
+#define STM32_RTC_TR 0x00
+#define STM32_RTC_DR 0x04
+#define STM32_RTC_CR 0x08
+#define STM32_RTC_ISR 0x0C
+#define STM32_RTC_PRER 0x10
+#define STM32_RTC_ALRMAR 0x1C
+#define STM32_RTC_WPR 0x24
+
+/* STM32_RTC_TR bit fields */
+#define STM32_RTC_TR_SEC_SHIFT 0
+#define STM32_RTC_TR_SEC GENMASK(6, 0)
+#define STM32_RTC_TR_MIN_SHIFT 8
+#define STM32_RTC_TR_MIN GENMASK(14, 8)
+#define STM32_RTC_TR_HOUR_SHIFT 16
+#define STM32_RTC_TR_HOUR GENMASK(21, 16)
+
+/* STM32_RTC_DR bit fields */
+#define STM32_RTC_DR_DATE_SHIFT 0
+#define STM32_RTC_DR_DATE GENMASK(5, 0)
+#define STM32_RTC_DR_MONTH_SHIFT 8
+#define STM32_RTC_DR_MONTH GENMASK(12, 8)
+#define STM32_RTC_DR_WDAY_SHIFT 13
+#define STM32_RTC_DR_WDAY GENMASK(15, 13)
+#define STM32_RTC_DR_YEAR_SHIFT 16
+#define STM32_RTC_DR_YEAR GENMASK(23, 16)
+
+/* STM32_RTC_CR bit fields */
+#define STM32_RTC_CR_FMT BIT(6)
+#define STM32_RTC_CR_ALRAE BIT(8)
+#define STM32_RTC_CR_ALRAIE BIT(12)
+
+/* STM32_RTC_ISR bit fields */
+#define STM32_RTC_ISR_ALRAWF BIT(0)
+#define STM32_RTC_ISR_INITS BIT(4)
+#define STM32_RTC_ISR_RSF BIT(5)
+#define STM32_RTC_ISR_INITF BIT(6)
+#define STM32_RTC_ISR_INIT BIT(7)
+#define STM32_RTC_ISR_ALRAF BIT(8)
+
+/* STM32_RTC_PRER bit fields */
+#define STM32_RTC_PRER_PRED_S_SHIFT 0
+#define STM32_RTC_PRER_PRED_S GENMASK(14, 0)
+#define STM32_RTC_PRER_PRED_A_SHIFT 16
+#define STM32_RTC_PRER_PRED_A GENMASK(22, 16)
+
+/* STM32_RTC_ALRMAR and STM32_RTC_ALRMBR bit fields */
+#define STM32_RTC_ALRMXR_SEC_SHIFT 0
+#define STM32_RTC_ALRMXR_SEC GENMASK(6, 0)
+#define STM32_RTC_ALRMXR_SEC_MASK BIT(7)
+#define STM32_RTC_ALRMXR_MIN_SHIFT 8
+#define STM32_RTC_ALRMXR_MIN GENMASK(14, 8)
+#define STM32_RTC_ALRMXR_MIN_MASK BIT(15)
+#define STM32_RTC_ALRMXR_HOUR_SHIFT 16
+#define STM32_RTC_ALRMXR_HOUR GENMASK(21, 16)
+#define STM32_RTC_ALRMXR_PM BIT(22)
+#define STM32_RTC_ALRMXR_HOUR_MASK BIT(23)
+#define STM32_RTC_ALRMXR_DATE_SHIFT 24
+#define STM32_RTC_ALRMXR_DATE GENMASK(29, 24)
+#define STM32_RTC_ALRMXR_WDSEL BIT(30)
+#define STM32_RTC_ALRMXR_WDAY_SHIFT 24
+#define STM32_RTC_ALRMXR_WDAY GENMASK(27, 24)
+#define STM32_RTC_ALRMXR_DATE_MASK BIT(31)
+
+/* STM32_RTC_WPR key constants */
+#define RTC_WPR_1ST_KEY 0xCA
+#define RTC_WPR_2ND_KEY 0x53
+#define RTC_WPR_WRONG_KEY 0xFF
+
+/*
+ * RTC registers are protected agains parasitic write access.
+ * PWR_CR_DBP bit must be set to enable write access to RTC registers.
+ */
+/* STM32_PWR_CR */
+#define PWR_CR 0x00
+/* STM32_PWR_CR bit field */
+#define PWR_CR_DBP BIT(8)
+
+static struct regmap *dbp;
+
+struct stm32_rtc {
+ struct rtc_device *rtc_dev;
+ void __iomem *base;
+ struct clk *ck_rtc;
+ spinlock_t lock; /* Protects registers accesses */
+ int irq_alarm;
+};
+
+static void stm32_rtc_wpr_unlock(struct stm32_rtc *rtc)
+{
+ writel_relaxed(RTC_WPR_1ST_KEY, rtc->base + STM32_RTC_WPR);
+ writel_relaxed(RTC_WPR_2ND_KEY, rtc->base + STM32_RTC_WPR);
+}
+
+static void stm32_rtc_wpr_lock(struct stm32_rtc *rtc)
+{
+ writel_relaxed(RTC_WPR_WRONG_KEY, rtc->base + STM32_RTC_WPR);
+}
+
+static int stm32_rtc_enter_init_mode(struct stm32_rtc *rtc)
+{
+ unsigned int isr = readl_relaxed(rtc->base + STM32_RTC_ISR);
+
+ if (!(isr & STM32_RTC_ISR_INITF)) {
+ isr |= STM32_RTC_ISR_INIT;
+ writel_relaxed(isr, rtc->base + STM32_RTC_ISR);
+
+ /*
+ * It takes around 2 ck_rtc clock cycles to enter in
+ * initialization phase mode (and have INITF flag set). As
+ * slowest ck_rtc frequency may be 32kHz and highest should be
+ * 1MHz, we poll every 10 us with a timeout of 100ms.
+ */
+ return readl_relaxed_poll_timeout_atomic(
+ rtc->base + STM32_RTC_ISR,
+ isr, (isr & STM32_RTC_ISR_INITF),
+ 10, 100000);
+ }
+
+ return 0;
+}
+
+static void stm32_rtc_exit_init_mode(struct stm32_rtc *rtc)
+{
+ unsigned int isr = readl_relaxed(rtc->base + STM32_RTC_ISR);
+
+ isr &= ~STM32_RTC_ISR_INIT;
+ writel_relaxed(isr, rtc->base + STM32_RTC_ISR);
+}
+
+static int stm32_rtc_wait_sync(struct stm32_rtc *rtc)
+{
+ unsigned int isr = readl_relaxed(rtc->base + STM32_RTC_ISR);
+
+ isr &= ~STM32_RTC_ISR_RSF;
+ writel_relaxed(isr, rtc->base + STM32_RTC_ISR);
+
+ /*
+ * Wait for RSF to be set to ensure the calendar registers are
+ * synchronised, it takes around 2 ck_rtc clock cycles
+ */
+ return readl_relaxed_poll_timeout_atomic(rtc->base + STM32_RTC_ISR,
+ isr,
+ (isr & STM32_RTC_ISR_RSF),
+ 10, 100000);
+}
+
+static irqreturn_t stm32_rtc_alarm_irq(int irq, void *dev_id)
+{
+ struct stm32_rtc *rtc = (struct stm32_rtc *)dev_id;
+ unsigned int isr, cr;
+
+ mutex_lock(&rtc->rtc_dev->ops_lock);
+
+ isr = readl_relaxed(rtc->base + STM32_RTC_ISR);
+ cr = readl_relaxed(rtc->base + STM32_RTC_CR);
+
+ if ((isr & STM32_RTC_ISR_ALRAF) &&
+ (cr & STM32_RTC_CR_ALRAIE)) {
+ /* Alarm A flag - Alarm interrupt */
+ dev_dbg(&rtc->rtc_dev->dev, "Alarm occurred\n");
+
+ /* Pass event to the kernel */
+ rtc_update_irq(rtc->rtc_dev, 1, RTC_IRQF | RTC_AF);
+
+ /* Clear event flag, otherwise new events won't be received */
+ writel_relaxed(isr & ~STM32_RTC_ISR_ALRAF,
+ rtc->base + STM32_RTC_ISR);
+ }
+
+ mutex_unlock(&rtc->rtc_dev->ops_lock);
+
+ return IRQ_HANDLED;
+}
+
+/* Convert rtc_time structure from bin to bcd format */
+static void tm2bcd(struct rtc_time *tm)
+{
+ tm->tm_sec = bin2bcd(tm->tm_sec);
+ tm->tm_min = bin2bcd(tm->tm_min);
+ tm->tm_hour = bin2bcd(tm->tm_hour);
+
+ tm->tm_mday = bin2bcd(tm->tm_mday);
+ tm->tm_mon = bin2bcd(tm->tm_mon + 1);
+ tm->tm_year = bin2bcd(tm->tm_year - 100);
+ /*
+ * Number of days since Sunday
+ * - on kernel side, 0=Sunday...6=Saturday
+ * - on rtc side, 0=invalid,1=Monday...7=Sunday
+ */
+ tm->tm_wday = (!tm->tm_wday) ? 7 : tm->tm_wday;
+}
+
+/* Convert rtc_time structure from bcd to bin format */
+static void bcd2tm(struct rtc_time *tm)
+{
+ tm->tm_sec = bcd2bin(tm->tm_sec);
+ tm->tm_min = bcd2bin(tm->tm_min);
+ tm->tm_hour = bcd2bin(tm->tm_hour);
+
+ tm->tm_mday = bcd2bin(tm->tm_mday);
+ tm->tm_mon = bcd2bin(tm->tm_mon) - 1;
+ tm->tm_year = bcd2bin(tm->tm_year) + 100;
+ /*
+ * Number of days since Sunday
+ * - on kernel side, 0=Sunday...6=Saturday
+ * - on rtc side, 0=invalid,1=Monday...7=Sunday
+ */
+ tm->tm_wday %= 7;
+}
+
+static int stm32_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct stm32_rtc *rtc = dev_get_drvdata(dev);
+ unsigned int tr, dr;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&rtc->lock, irqflags);
+
+ /* Time and Date in BCD format */
+ tr = readl_relaxed(rtc->base + STM32_RTC_TR);
+ dr = readl_relaxed(rtc->base + STM32_RTC_DR);
+
+ spin_unlock_irqrestore(&rtc->lock, irqflags);
+
+ tm->tm_sec = (tr & STM32_RTC_TR_SEC) >> STM32_RTC_TR_SEC_SHIFT;
+ tm->tm_min = (tr & STM32_RTC_TR_MIN) >> STM32_RTC_TR_MIN_SHIFT;
+ tm->tm_hour = (tr & STM32_RTC_TR_HOUR) >> STM32_RTC_TR_HOUR_SHIFT;
+
+ tm->tm_mday = (dr & STM32_RTC_DR_DATE) >> STM32_RTC_DR_DATE_SHIFT;
+ tm->tm_mon = (dr & STM32_RTC_DR_MONTH) >> STM32_RTC_DR_MONTH_SHIFT;
+ tm->tm_year = (dr & STM32_RTC_DR_YEAR) >> STM32_RTC_DR_YEAR_SHIFT;
+ tm->tm_wday = (dr & STM32_RTC_DR_WDAY) >> STM32_RTC_DR_WDAY_SHIFT;
+
+ /* We don't report tm_yday and tm_isdst */
+
+ bcd2tm(tm);
+
+ if (rtc_valid_tm(tm) < 0) {
+ dev_err(dev, "%s: rtc_time is not valid.\n", __func__);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int stm32_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ struct stm32_rtc *rtc = dev_get_drvdata(dev);
+ unsigned int tr, dr;
+ unsigned long irqflags;
+ int ret = 0;
+
+ if (rtc_valid_tm(tm) < 0) {
+ dev_err(dev, "%s: rtc_time is not valid.\n", __func__);
+ return -EINVAL;
+ }
+
+ tm2bcd(tm);
+
+ /* Time in BCD format */
+ tr = ((tm->tm_sec << STM32_RTC_TR_SEC_SHIFT) & STM32_RTC_TR_SEC) |
+ ((tm->tm_min << STM32_RTC_TR_MIN_SHIFT) & STM32_RTC_TR_MIN) |
+ ((tm->tm_hour << STM32_RTC_TR_HOUR_SHIFT) & STM32_RTC_TR_HOUR);
+
+ /* Date in BCD format */
+ dr = ((tm->tm_mday << STM32_RTC_DR_DATE_SHIFT) & STM32_RTC_DR_DATE) |
+ ((tm->tm_mon << STM32_RTC_DR_MONTH_SHIFT) & STM32_RTC_DR_MONTH) |
+ ((tm->tm_year << STM32_RTC_DR_YEAR_SHIFT) & STM32_RTC_DR_YEAR) |
+ ((tm->tm_wday << STM32_RTC_DR_WDAY_SHIFT) & STM32_RTC_DR_WDAY);
+
+ spin_lock_irqsave(&rtc->lock, irqflags);
+
+ stm32_rtc_wpr_unlock(rtc);
+
+ ret = stm32_rtc_enter_init_mode(rtc);
+ if (ret) {
+ dev_err(dev, "Can't enter in init mode. Set time aborted.\n");
+ goto end;
+ }
+
+ writel_relaxed(tr, rtc->base + STM32_RTC_TR);
+ writel_relaxed(dr, rtc->base + STM32_RTC_DR);
+
+ stm32_rtc_exit_init_mode(rtc);
+
+ ret = stm32_rtc_wait_sync(rtc);
+end:
+ stm32_rtc_wpr_lock(rtc);
+
+ spin_unlock_irqrestore(&rtc->lock, irqflags);
+
+ return ret;
+}
+
+static int stm32_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+ struct stm32_rtc *rtc = dev_get_drvdata(dev);
+ struct rtc_time *tm = &alrm->time;
+ unsigned int alrmar, cr, isr;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&rtc->lock, irqflags);
+
+ alrmar = readl_relaxed(rtc->base + STM32_RTC_ALRMAR);
+ cr = readl_relaxed(rtc->base + STM32_RTC_CR);
+ isr = readl_relaxed(rtc->base + STM32_RTC_ISR);
+
+ spin_unlock_irqrestore(&rtc->lock, irqflags);
+
+ if (alrmar & STM32_RTC_ALRMXR_DATE_MASK) {
+ /*
+ * Date/day doesn't matter in Alarm comparison so alarm
+ * triggers every day
+ */
+ tm->tm_mday = -1;
+ tm->tm_wday = -1;
+ } else {
+ if (alrmar & STM32_RTC_ALRMXR_WDSEL) {
+ /* Alarm is set to a day of week */
+ tm->tm_mday = -1;
+ tm->tm_wday = (alrmar & STM32_RTC_ALRMXR_WDAY) >>
+ STM32_RTC_ALRMXR_WDAY_SHIFT;
+ tm->tm_wday %= 7;
+ } else {
+ /* Alarm is set to a day of month */
+ tm->tm_wday = -1;
+ tm->tm_mday = (alrmar & STM32_RTC_ALRMXR_DATE) >>
+ STM32_RTC_ALRMXR_DATE_SHIFT;
+ }
+ }
+
+ if (alrmar & STM32_RTC_ALRMXR_HOUR_MASK) {
+ /* Hours don't matter in Alarm comparison */
+ tm->tm_hour = -1;
+ } else {
+ tm->tm_hour = (alrmar & STM32_RTC_ALRMXR_HOUR) >>
+ STM32_RTC_ALRMXR_HOUR_SHIFT;
+ if (alrmar & STM32_RTC_ALRMXR_PM)
+ tm->tm_hour += 12;
+ }
+
+ if (alrmar & STM32_RTC_ALRMXR_MIN_MASK) {
+ /* Minutes don't matter in Alarm comparison */
+ tm->tm_min = -1;
+ } else {
+ tm->tm_min = (alrmar & STM32_RTC_ALRMXR_MIN) >>
+ STM32_RTC_ALRMXR_MIN_SHIFT;
+ }
+
+ if (alrmar & STM32_RTC_ALRMXR_SEC_MASK) {
+ /* Seconds don't matter in Alarm comparison */
+ tm->tm_sec = -1;
+ } else {
+ tm->tm_sec = (alrmar & STM32_RTC_ALRMXR_SEC) >>
+ STM32_RTC_ALRMXR_SEC_SHIFT;
+ }
+
+ bcd2tm(tm);
+
+ alrm->enabled = (cr & STM32_RTC_CR_ALRAE) ? 1 : 0;
+ alrm->pending = (isr & STM32_RTC_ISR_ALRAF) ? 1 : 0;
+
+ return 0;
+}
+
+static int stm32_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
+{
+ struct stm32_rtc *rtc = dev_get_drvdata(dev);
+ unsigned long irqflags;
+ unsigned int isr, cr;
+
+ spin_lock_irqsave(&rtc->lock, irqflags);
+
+ cr = readl_relaxed(rtc->base + STM32_RTC_CR);
+
+ stm32_rtc_wpr_unlock(rtc);
+
+ /* We expose Alarm A to the kernel */
+ if (enabled)
+ cr |= (STM32_RTC_CR_ALRAIE | STM32_RTC_CR_ALRAE);
+ else
+ cr &= ~(STM32_RTC_CR_ALRAIE | STM32_RTC_CR_ALRAE);
+ writel_relaxed(cr, rtc->base + STM32_RTC_CR);
+
+ /* Clear event irqflags, otherwise new events won't be received */
+ isr = readl_relaxed(rtc->base + STM32_RTC_ISR);
+ isr &= ~STM32_RTC_ISR_ALRAF;
+ writel_relaxed(isr, rtc->base + STM32_RTC_ISR);
+
+ stm32_rtc_wpr_lock(rtc);
+
+ spin_unlock_irqrestore(&rtc->lock, irqflags);
+
+ return 0;
+}
+
+static int stm32_rtc_valid_alrm(struct stm32_rtc *rtc, struct rtc_time *tm)
+{
+ unsigned int cur_day, cur_mon, cur_year, cur_hour, cur_min, cur_sec;
+ unsigned int dr = readl_relaxed(rtc->base + STM32_RTC_DR);
+ unsigned int tr = readl_relaxed(rtc->base + STM32_RTC_TR);
+
+ cur_day = (dr & STM32_RTC_DR_DATE) >> STM32_RTC_DR_DATE_SHIFT;
+ cur_mon = (dr & STM32_RTC_DR_MONTH) >> STM32_RTC_DR_MONTH_SHIFT;
+ cur_year = (dr & STM32_RTC_DR_YEAR) >> STM32_RTC_DR_YEAR_SHIFT;
+ cur_sec = (tr & STM32_RTC_TR_SEC) >> STM32_RTC_TR_SEC_SHIFT;
+ cur_min = (tr & STM32_RTC_TR_MIN) >> STM32_RTC_TR_MIN_SHIFT;
+ cur_hour = (tr & STM32_RTC_TR_HOUR) >> STM32_RTC_TR_HOUR_SHIFT;
+
+ /*
+ * Assuming current date is M-D-Y H:M:S.
+ * RTC alarm can't be set on a specific month and year.
+ * So the valid alarm range is:
+ * M-D-Y H:M:S < alarm <= (M+1)-D-Y H:M:S
+ * with a specific case for December...
+ */
+ if ((((tm->tm_year > cur_year) &&
+ (tm->tm_mon == 0x1) && (cur_mon == 0x12)) ||
+ ((tm->tm_year == cur_year) &&
+ (tm->tm_mon <= cur_mon + 1))) &&
+ ((tm->tm_mday < cur_day) ||
+ ((tm->tm_mday == cur_day) &&
+ ((tm->tm_hour < cur_hour) ||
+ ((tm->tm_hour == cur_hour) && (tm->tm_min < cur_min)) ||
+ ((tm->tm_hour == cur_hour) && (tm->tm_min == cur_min) &&
+ (tm->tm_sec <= cur_sec))))))
+ return 0;
+
+ return -EINVAL;
+}
+
+static int stm32_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+ struct stm32_rtc *rtc = dev_get_drvdata(dev);
+ struct rtc_time *tm = &alrm->time;
+ unsigned long irqflags;
+ unsigned int cr, isr, alrmar;
+ int ret = 0;
+
+ if (rtc_valid_tm(tm)) {
+ dev_err(dev, "Alarm time not valid.\n");
+ return -EINVAL;
+ }
+
+ tm2bcd(tm);
+
+ /*
+ * RTC alarm can't be set on a specific date, unless this date is
+ * up to the same day of month next month.
+ */
+ if (stm32_rtc_valid_alrm(rtc, tm) < 0) {
+ dev_err(dev, "Alarm can be set only on upcoming month.\n");
+ return -EINVAL;
+ }
+
+ alrmar = 0;
+ /* tm_year and tm_mon are not used because not supported by RTC */
+ alrmar |= (tm->tm_mday << STM32_RTC_ALRMXR_DATE_SHIFT) &
+ STM32_RTC_ALRMXR_DATE;
+ /* 24-hour format */
+ alrmar &= ~STM32_RTC_ALRMXR_PM;
+ alrmar |= (tm->tm_hour << STM32_RTC_ALRMXR_HOUR_SHIFT) &
+ STM32_RTC_ALRMXR_HOUR;
+ alrmar |= (tm->tm_min << STM32_RTC_ALRMXR_MIN_SHIFT) &
+ STM32_RTC_ALRMXR_MIN;
+ alrmar |= (tm->tm_sec << STM32_RTC_ALRMXR_SEC_SHIFT) &
+ STM32_RTC_ALRMXR_SEC;
+
+ spin_lock_irqsave(&rtc->lock, irqflags);
+
+ stm32_rtc_wpr_unlock(rtc);
+
+ /* Disable Alarm */
+ cr = readl_relaxed(rtc->base + STM32_RTC_CR);
+ cr &= ~STM32_RTC_CR_ALRAE;
+ writel_relaxed(cr, rtc->base + STM32_RTC_CR);
+
+ /*
+ * Poll Alarm write flag to be sure that Alarm update is allowed: it
+ * takes around 2 ck_rtc clock cycles
+ */
+ ret = readl_relaxed_poll_timeout_atomic(rtc->base + STM32_RTC_ISR,
+ isr,
+ (isr & STM32_RTC_ISR_ALRAWF),
+ 10, 100000);
+
+ if (ret) {
+ dev_err(dev, "Alarm update not allowed\n");
+ goto end;
+ }
+
+ /* Write to Alarm register */
+ writel_relaxed(alrmar, rtc->base + STM32_RTC_ALRMAR);
+
+ if (alrm->enabled)
+ stm32_rtc_alarm_irq_enable(dev, 1);
+ else
+ stm32_rtc_alarm_irq_enable(dev, 0);
+
+end:
+ stm32_rtc_wpr_lock(rtc);
+
+ spin_unlock_irqrestore(&rtc->lock, irqflags);
+
+ return ret;
+}
+
+static const struct rtc_class_ops stm32_rtc_ops = {
+ .read_time = stm32_rtc_read_time,
+ .set_time = stm32_rtc_set_time,
+ .read_alarm = stm32_rtc_read_alarm,
+ .set_alarm = stm32_rtc_set_alarm,
+ .alarm_irq_enable = stm32_rtc_alarm_irq_enable,
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id stm32_rtc_of_match[] = {
+ { .compatible = "st,stm32-rtc" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, stm32_rtc_of_match);
+#endif
+
+static int stm32_rtc_init(struct platform_device *pdev,
+ struct stm32_rtc *rtc)
+{
+ unsigned int prer, pred_a, pred_s, pred_a_max, pred_s_max, cr;
+ unsigned int rate;
+ unsigned long irqflags;
+ int ret = 0;
+
+ rate = clk_get_rate(rtc->ck_rtc);
+
+ /* Find prediv_a and prediv_s to obtain the 1Hz calendar clock */
+ pred_a_max = STM32_RTC_PRER_PRED_A >> STM32_RTC_PRER_PRED_A_SHIFT;
+ pred_s_max = STM32_RTC_PRER_PRED_S >> STM32_RTC_PRER_PRED_S_SHIFT;
+
+ for (pred_a = pred_a_max; pred_a >= 0; pred_a--) {
+ pred_s = (rate / (pred_a + 1)) - 1;
+
+ if (((pred_s + 1) * (pred_a + 1)) == rate)
+ break;
+ }
+
+ /*
+ * Can't find a 1Hz, so give priority to RTC power consumption
+ * by choosing the higher possible value for prediv_a
+ */
+ if ((pred_s > pred_s_max) || (pred_a > pred_a_max)) {
+ pred_a = pred_a_max;
+ pred_s = (rate / (pred_a + 1)) - 1;
+
+ dev_warn(&pdev->dev, "ck_rtc is %s\n",
+ (rate - ((pred_a + 1) * (pred_s + 1)) < 0) ?
+ "fast" : "slow");
+ }
+
+ spin_lock_irqsave(&rtc->lock, irqflags);
+
+ stm32_rtc_wpr_unlock(rtc);
+
+ ret = stm32_rtc_enter_init_mode(rtc);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Can't enter in init mode. Prescaler config failed.\n");
+ goto end;
+ }
+
+ prer = (pred_s << STM32_RTC_PRER_PRED_S_SHIFT) & STM32_RTC_PRER_PRED_S;
+ writel_relaxed(prer, rtc->base + STM32_RTC_PRER);
+ prer |= (pred_a << STM32_RTC_PRER_PRED_A_SHIFT) & STM32_RTC_PRER_PRED_A;
+ writel_relaxed(prer, rtc->base + STM32_RTC_PRER);
+
+ /* Force 24h time format */
+ cr = readl_relaxed(rtc->base + STM32_RTC_CR);
+ cr &= ~STM32_RTC_CR_FMT;
+ writel_relaxed(cr, rtc->base + STM32_RTC_CR);
+
+ stm32_rtc_exit_init_mode(rtc);
+
+ ret = stm32_rtc_wait_sync(rtc);
+end:
+ stm32_rtc_wpr_lock(rtc);
+
+ spin_unlock_irqrestore(&rtc->lock, irqflags);
+
+ return ret;
+}
+
+static int stm32_rtc_probe(struct platform_device *pdev)
+{
+ struct stm32_rtc *rtc;
+ struct resource *res;
+ int ret;
+
+ rtc = devm_kzalloc(&pdev->dev, sizeof(*rtc), GFP_KERNEL);
+ if (!rtc)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ rtc->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(rtc->base))
+ return PTR_ERR(rtc->base);
+
+ dbp = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "st,syscfg");
+ if (IS_ERR(dbp)) {
+ dev_err(&pdev->dev, "no st,syscfg\n");
+ return PTR_ERR(dbp);
+ }
+
+ spin_lock_init(&rtc->lock);
+
+ rtc->ck_rtc = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(rtc->ck_rtc)) {
+ dev_err(&pdev->dev, "no ck_rtc clock");
+ return PTR_ERR(rtc->ck_rtc);
+ }
+
+ ret = clk_prepare_enable(rtc->ck_rtc);
+ if (ret)
+ return ret;
+
+ regmap_update_bits(dbp, PWR_CR, PWR_CR_DBP, PWR_CR_DBP);
+
+ /*
+ * After a system reset, RTC_ISR.INITS flag can be read to check if
+ * the calendar has been initalized or not. INITS flag is reset by a
+ * power-on reset (no vbat, no power-supply). It is not reset if
+ * ck_rtc parent clock has changed (so RTC prescalers need to be
+ * changed). That's why we cannot rely on this flag to know if RTC
+ * init has to be done.
+ */
+ ret = stm32_rtc_init(pdev, rtc);
+ if (ret)
+ goto err;
+
+ rtc->irq_alarm = platform_get_irq(pdev, 0);
+ if (rtc->irq_alarm <= 0) {
+ dev_err(&pdev->dev, "no alarm irq\n");
+ ret = rtc->irq_alarm;
+ goto err;
+ }
+
+ platform_set_drvdata(pdev, rtc);
+
+ ret = device_init_wakeup(&pdev->dev, true);
+ if (ret)
+ dev_warn(&pdev->dev,
+ "alarm won't be able to wake up the system");
+
+ rtc->rtc_dev = devm_rtc_device_register(&pdev->dev, pdev->name,
+ &stm32_rtc_ops, THIS_MODULE);
+ if (IS_ERR(rtc->rtc_dev)) {
+ ret = PTR_ERR(rtc->rtc_dev);
+ dev_err(&pdev->dev, "rtc device registration failed, err=%d\n",
+ ret);
+ goto err;
+ }
+
+ /* Handle RTC alarm interrupts */
+ ret = devm_request_threaded_irq(&pdev->dev, rtc->irq_alarm, NULL,
+ stm32_rtc_alarm_irq,
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ pdev->name, rtc);
+ if (ret) {
+ dev_err(&pdev->dev, "IRQ%d (alarm interrupt) already claimed\n",
+ rtc->irq_alarm);
+ goto err;
+ }
+
+ /*
+ * If INITS flag is reset (calendar year field set to 0x00), calendar
+ * must be initialized
+ */
+ if (!(readl_relaxed(rtc->base + STM32_RTC_ISR) & STM32_RTC_ISR_INITS))
+ dev_warn(&pdev->dev, "Date/Time must be initialized\n");
+
+ return 0;
+err:
+ clk_disable_unprepare(rtc->ck_rtc);
+
+ regmap_update_bits(dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
+
+ device_init_wakeup(&pdev->dev, false);
+
+ return ret;
+}
+
+static int __exit stm32_rtc_remove(struct platform_device *pdev)
+{
+ struct stm32_rtc *rtc = platform_get_drvdata(pdev);
+ unsigned int cr;
+
+ /* Disable interrupts */
+ stm32_rtc_wpr_unlock(rtc);
+ cr = readl_relaxed(rtc->base + STM32_RTC_CR);
+ cr &= ~STM32_RTC_CR_ALRAIE;
+ writel_relaxed(cr, rtc->base + STM32_RTC_CR);
+ stm32_rtc_wpr_lock(rtc);
+
+ clk_disable_unprepare(rtc->ck_rtc);
+
+ /* Enable backup domain write protection */
+ regmap_update_bits(dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
+
+ device_init_wakeup(&pdev->dev, false);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int stm32_rtc_suspend(struct device *dev)
+{
+ struct stm32_rtc *rtc = dev_get_drvdata(dev);
+
+ if (device_may_wakeup(dev))
+ return enable_irq_wake(rtc->irq_alarm);
+
+ return 0;
+}
+
+static int stm32_rtc_resume(struct device *dev)
+{
+ struct stm32_rtc *rtc = dev_get_drvdata(dev);
+ int ret = 0;
+
+ ret = stm32_rtc_wait_sync(rtc);
+ if (ret < 0)
+ return ret;
+
+ if (device_may_wakeup(dev))
+ return disable_irq_wake(rtc->irq_alarm);
+
+ return ret;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(stm32_rtc_pm_ops,
+ stm32_rtc_suspend, stm32_rtc_resume);
+
+static struct platform_driver stm32_rtc_driver = {
+ .probe = stm32_rtc_probe,
+ .remove = stm32_rtc_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .pm = &stm32_rtc_pm_ops,
+ .of_match_table = stm32_rtc_of_match,
+ },
+};
+
+module_platform_driver(stm32_rtc_driver);
+
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_AUTHOR("Amelie Delaunay <amelie.delaunay@st.com>");
+MODULE_DESCRIPTION("STMicroelectronics STM32 Real Time Clock driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCHv3 4/8] ARM: dts: stm32: Add RTC support for STM32F429 MCU
From: Amelie Delaunay @ 2017-01-05 13:43 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: devicetree, Amelie Delaunay, rtc-linux, linux-kernel,
Gabriel Fernandez, linux-arm-kernel
In-Reply-To: <1483623809-29937-1-git-send-email-amelie.delaunay@st.com>
This patch adds STM32 RTC bindings for STM32F429.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index d195ccf..d181025 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -125,6 +125,20 @@
status = "disabled";
};
+ rtc: rtc@40002800 {
+ compatible = "st,stm32-rtc";
+ reg = <0x40002800 0x400>;
+ clocks = <&rcc 1 CLK_RTC>;
+ clock-names = "ck_rtc";
+ assigned-clocks = <&rcc 1 CLK_RTC>;
+ assigned-clock-parents = <&rcc 1 CLK_LSE>;
+ interrupt-parent = <&exti>;
+ interrupts = <17 1>;
+ interrupt-names = "alarm";
+ st,syscfg = <&pwrcfg>;
+ status = "disabled";
+ };
+
usart2: serial@40004400 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004400 0x400>;
--
1.9.1
^ permalink raw reply related
* [PATCHv3 5/8] ARM: dts: stm32: enable RTC on stm32f429-disco
From: Amelie Delaunay @ 2017-01-05 13:43 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: devicetree, Amelie Delaunay, rtc-linux, linux-kernel,
Gabriel Fernandez, linux-arm-kernel
In-Reply-To: <1483623809-29937-1-git-send-email-amelie.delaunay@st.com>
This patch enables RTC on stm32f429-disco with LSI as clock source because
X2 crystal for LSE is not fitted by default.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32f429-disco.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
index b6e63d8..49eddf6 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -94,6 +94,12 @@
clock-frequency = <8000000>;
};
+&rtc {
+ assigned-clocks = <&rcc 1 CLK_RTC>;
+ assigned-clock-parents = <&rcc 1 CLK_LSI>;
+ status = "okay";
+};
+
&usart1 {
pinctrl-0 = <&usart1_pins_a>;
pinctrl-names = "default";
--
1.9.1
^ permalink raw reply related
* [PATCHv3 6/8] ARM: dts: stm32: enable RTC on stm32f469-disco
From: Amelie Delaunay @ 2017-01-05 13:43 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: devicetree, Amelie Delaunay, rtc-linux, linux-kernel,
Gabriel Fernandez, linux-arm-kernel
In-Reply-To: <1483623809-29937-1-git-send-email-amelie.delaunay@st.com>
This patch enables RTC on stm32f469-disco with default LSE clock source.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32f469-disco.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index 8a163d7..af57dd5 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -78,6 +78,10 @@
clock-frequency = <8000000>;
};
+&rtc {
+ status = "okay";
+};
+
&usart3 {
status = "okay";
};
--
1.9.1
^ permalink raw reply related
* [PATCHv3 7/8] ARM: dts: stm32: enable RTC on stm32429i-eval
From: Amelie Delaunay @ 2017-01-05 13:43 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: devicetree, Amelie Delaunay, rtc-linux, linux-kernel,
Gabriel Fernandez, linux-arm-kernel
In-Reply-To: <1483623809-29937-1-git-send-email-amelie.delaunay@st.com>
This patch enables RTC on stm32429i-eval with default LSE clock source.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32429i-eval.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index 8b158f9..5007da9 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -134,6 +134,10 @@
};
};
+&rtc {
+ status = "okay";
+};
+
&usart1 {
pinctrl-0 = <&usart1_pins_a>;
pinctrl-names = "default";
--
1.9.1
^ permalink raw reply related
* [PATCHv3 8/8] ARM: configs: stm32: Add RTC support in STM32 defconfig
From: Amelie Delaunay @ 2017-01-05 13:43 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: devicetree, Amelie Delaunay, rtc-linux, linux-kernel,
Gabriel Fernandez, linux-arm-kernel
In-Reply-To: <1483623809-29937-1-git-send-email-amelie.delaunay@st.com>
This patch adds STM32 RTC support in stm32_defconfig file.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/configs/stm32_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index be19e09..0acff9e 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -57,6 +57,8 @@ CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_STM32=y
CONFIG_DMADEVICES=y
CONFIG_STM32_DMA=y
# CONFIG_FILE_LOCKING is not set
--
1.9.1
^ permalink raw reply related
* Re: [PATCHv2 1/5] clk: mvebu: support for 98DX3236 SoC
From: Mark Rutland @ 2017-01-05 13:53 UTC (permalink / raw)
To: Chris Packham
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Michael Turquette, Stephen Boyd, Rob Herring, Gregory CLEMENT,
Thomas Petazzoni, linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170105033641.6212-2-chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
On Thu, Jan 05, 2017 at 04:36:37PM +1300, Chris Packham wrote:
> The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from
> the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz.
>
> The clock gating options are a subset of those on the Armada XP.
>
> The core clock divider is different to the Armada XP also.
>
> Signed-off-by: Chris Packham <chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
> ---
> Changes in v2:
> - Update devicetree binding documentation for new compatible string
>
> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 1 +
> drivers/clk/mvebu/Makefile | 2 +-
> drivers/clk/mvebu/armada-xp.c | 42 +++++
> drivers/clk/mvebu/clk-cpu.c | 33 +++-
> drivers/clk/mvebu/mv98dx3236-corediv.c | 207 +++++++++++++++++++++
> 5 files changed, 281 insertions(+), 4 deletions(-)
> create mode 100644 drivers/clk/mvebu/mv98dx3236-corediv.c
It looks like you also need to update
Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt for the
addition of "marvell,mv98dx3236-corediv-clock".
>
> diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
> index 99c214660bdc..7f28506eaee7 100644
> --- a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
> @@ -3,6 +3,7 @@ Device Tree Clock bindings for cpu clock of Marvell EBU platforms
> Required properties:
> - compatible : shall be one of the following:
> "marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
> + "marvell,mv98dx3236-cpu-clock" - cpu clocks for 98DX3236 SoC
> - reg : Address and length of the clock complex register set, followed
> by address and length of the PMU DFS registers
> - #clock-cells : should be set to 1.
[...]
> +static void __init mv98dx3236_corediv_clk_init(struct device_node *node)
> +{
> + struct clk_init_data init;
> + struct clk_corediv *corediv;
> + struct clk **clks;
> + void __iomem *base;
> + const __be32 *off;
> + const char *parent_name;
> + const char *clk_name;
> + int len;
> + struct device_node *dfx_node;
> +
> + dfx_node = of_parse_phandle(node, "base", 0);
> + if (WARN_ON(!dfx_node))
What's going on here? The existing bingings don't mention a "base"
phandle, and nothing was added to describe it.
> + return;
> +
> + off = of_get_property(node, "reg", &len);
> + if (WARN_ON(!off))
> + return;
Please don't use of_get_property directly; generally you should use the
existing higher-level helpers like of_proeprty_read_u32().
> +
> + base = of_iomap(dfx_node, 0);
> + if (WARN_ON(!base))
> + return;
> +
> + of_node_put(dfx_node);
> +
> + parent_name = of_clk_get_parent_name(node, 0);
> +
> + clk_data.clk_num = 1;
> +
> + /* clks holds the clock array */
> + clks = kcalloc(clk_data.clk_num, sizeof(struct clk *),
> + GFP_KERNEL);
> + if (WARN_ON(!clks))
> + goto err_unmap;
> + /* corediv holds the clock specific array */
> + corediv = kcalloc(clk_data.clk_num, sizeof(struct clk_corediv),
> + GFP_KERNEL);
> + if (WARN_ON(!corediv))
> + goto err_free_clks;
> +
> + spin_lock_init(&corediv->lock);
> +
> + of_property_read_string_index(node, "clock-output-names",
> + 0, &clk_name);
> +
> + init.num_parents = 1;
> + init.parent_names = &parent_name;
> + init.name = clk_name;
> + init.ops = &ops;
> + init.flags = 0;
> +
> + corediv[0].reg = (void *)((int)base + be32_to_cpu(*off));
I don't understand this, but I guess this has something to do with that
base phandle. Is the corediv clock a sub-component of some "base" clock?
I don't think this binding is the best way of describing that.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv2 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs
From: Mark Rutland @ 2017-01-05 13:58 UTC (permalink / raw)
To: Chris Packham
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170105033641.6212-5-chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
On Thu, Jan 05, 2017 at 04:36:40PM +1300, Chris Packham wrote:
> + internal-regs {
> + coreclk: mvebu-sar@18230 {
> + compatible = "marvell,mv98dx3236-core-clock";
> + };
> +
> + cpuclk: clock-complex@18700 {
> + compatible = "marvell,mv98dx3236-cpu-clock";
> + };
> +
> + corediv-clock@18740 {
> + compatible = "marvell,mv98dx3236-corediv-clock";
> + reg = <0xf8268 0xc>;
> + base = <&dfx>;
> + #clock-cells = <1>;
> + clocks = <&mainpll>;
> + clock-output-names = "nand";
> + };
[...]
> + };
> +
> + dfx-registers {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>;
> +
> + dfx: dfx@0 {
> + compatible = "simple-bus";
> + reg = <0 0x100000>;
> + };
> + };
What is this dfx-registers, exactly? It has no children, so why is it a
simple-bus?
>From the above, and the patch adding the corediv driver, it looks like
the corediv-clock actually lives in this block, so I don't understand
why the corediv-clock is sitting in internal-regs with a sideband
reference to dfx.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Will Deacon @ 2017-01-05 14:00 UTC (permalink / raw)
To: Mark Rutland
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Jordan Crouse,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <20170105120857.GB21952@leverpostej>
On Thu, Jan 05, 2017 at 12:08:57PM +0000, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 11:55:29AM +0000, Will Deacon wrote:
> > On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote:
> > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > > index ef465b0..5f405a6 100644
> > > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > > @@ -68,6 +68,9 @@ conditions.
> > > aliases of secure registers have to be used during
> > > SMMU configuration.
> > >
> > > +- arm,smmu-enable-stall : Enable stall mode to stall memory transactions
> > > + and resume after fault is handled
>
> The wording here seems to describe a policy rather than a property.
>
> Can you elaborate on when/why this is required/preferred/valid?
It's not a policy, it's a hardware capability. There are some non-probeable
reasons why stalling mode is unsafe or unusable:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/474530.html
Some of these are specific to the SMMU implementation (e.g. whether or not
the SS bit can remain set without reasserting the IRQ) and some are specific
to the integration (e.g. whether or not stalling an endpoint can deadlock
the SoC). The key point is that, without support from both the
implementation and the integration, stalls are unusable.
> > > static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> > > @@ -824,6 +852,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
> > >
> > > /* SCTLR */
> > > reg = SCTLR_CFIE | SCTLR_CFRE | SCTLR_AFE | SCTLR_TRE | SCTLR_M;
> > > + if (smmu->options & ARM_SMMU_OPT_ENABLE_STALL)
> > > + reg |= SCTLR_CFCFG;
> >
> > I wonder if this should also be predicated on the compatible string, so
> > that the "arm,smmu-enable-stall" property is ignored (with a warning) if
> > the compatible string isn't specific enough to identify an implementation
> > with the required SS behaviour? On the other hand, it feels pretty
> > redundant and a single "stalling works" property is all we need.
>
> Can you elaborate on what "stalling works" entails? Is that just the SS
> bit behaviour? are there integration or endpoint-specific things that we
> need to care about?
See above. The "stalling works" property (arm,smmu-enable-stall) would
indicate that both the implementation *and* the integration are such
that stalling is usable for demand paging. I suspect there are endpoints
that can't deal with stalls (e.g. they might timeout and signal a RAS
event), but in that case their respective device drivers should ensure
that any DMA buffers are pinned and/or register a fault handler to
request termination of the faulting transaction.
Will
^ permalink raw reply
* Re: [PATCHv2 0/5] Support for Marvell switches with integrated CPUs
From: Marcin Wojtas @ 2017-01-05 14:07 UTC (permalink / raw)
To: Andrew Lunn
Cc: Chris Packham, Mark Rutland, Geert Uytterhoeven,
Michael Turquette, Laxman Dewangan, linux-clk@vger.kernel.org,
Florian Fainelli, Juri Lelli, Russell King, Thierry Reding,
Linus Walleij, Sebastian Hesselbarth, devicetree@vger.kernel.org,
Jason Cooper, Arnd Bergmann, Kalyan Kinthada, Rob Herring,
Gregory Clement <gre>
In-Reply-To: <20170105130945.GA18033@lunn.ch>
Hi Andrew,
2017-01-05 14:09 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
>> I'd love to see a switchdev driver but it's a huge task (and no I'm not
>> committing to writing it). As it stands Marvell ship a switch SDK
>> largely executes in userspace with a small kernel module providing some
>> linkage to the underlying hardware.
>
> Is there any similarity to the mv88e6xxx family?
Prestera switches (they are sold as standalone devices and with
integrated CPU's, like ones submitted) are as far from mv88e6xxx as
possible. There are various mix of 1/2.5/10/40G ports, depending on
model.
>
> If it was similar registers, just a different access mechanising, we
> could probably extend the mv88e6xxx to support MMIO as well as MDIO.
>
The difference is huge, nothing existing in the mainline can fit. The
driver, that exposes resources to the userspace SDK (called CPSS, it's
huge and complex piece of code) is existing in Marvell internal
branches (kernel v4.4 is the latest one), but I doubt such solution
(despite it's really small) is upstreamable. I believe it can be
shipped to the customers along with the SDK as a kernel module. Having
the CPU's support in the mainline is IMO sufficient.
Best regards,
Marcin
^ permalink raw reply
* Re: [PATCH v1 0/3] soc: rockchip: power-domain: support RK3328 SoC
From: Heiko Stuebner @ 2017-01-05 14:07 UTC (permalink / raw)
To: Elaine Zhang
Cc: xf-TNX95d0MmH7DzftRWevZcw, wxt-TNX95d0MmH7DzftRWevZcw,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
khilman-rdvid1DuHRBWk0Htik3J/w,
tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
huangtao-TNX95d0MmH7DzftRWevZcw, xxx-TNX95d0MmH7DzftRWevZcw,
cl-TNX95d0MmH7DzftRWevZcw,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1482464872-12954-1-git-send-email-zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Freitag, 23. Dezember 2016, 11:47:49 CET schrieb Elaine Zhang:
> Elaine Zhang (3):
> dt/bindings: power: add RK3328 SoCs header for idle-request
> dt-bindings: add binding for rk3328 power domains
> soc: rockchip: power-domain: Modify power domain driver for rk3328
>
> .../bindings/soc/rockchip/power_domain.txt | 3 ++
> drivers/soc/rockchip/pm_domains.c | 63
> +++++++++++++++++++--- include/dt-bindings/power/rk3328-power.h |
> 18 +++++++
> 3 files changed, 78 insertions(+), 6 deletions(-)
> create mode 100644 include/dt-bindings/power/rk3328-power.h
I've split patch 3 into two parts (hiword support and rk3328 addition) and
applied all for 4.11
Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Mark Rutland @ 2017-01-05 14:07 UTC (permalink / raw)
To: Will Deacon
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Jordan Crouse,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <20170105140005.GJ679-5wv7dgnIgG8@public.gmane.org>
On Thu, Jan 05, 2017 at 02:00:05PM +0000, Will Deacon wrote:
> On Thu, Jan 05, 2017 at 12:08:57PM +0000, Mark Rutland wrote:
> > On Thu, Jan 05, 2017 at 11:55:29AM +0000, Will Deacon wrote:
> > > On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote:
> > > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > > > index ef465b0..5f405a6 100644
> > > > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > > > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > > > @@ -68,6 +68,9 @@ conditions.
> > > > aliases of secure registers have to be used during
> > > > SMMU configuration.
> > > >
> > > > +- arm,smmu-enable-stall : Enable stall mode to stall memory transactions
> > > > + and resume after fault is handled
> >
> > The wording here seems to describe a policy rather than a property.
> >
> > Can you elaborate on when/why this is required/preferred/valid?
>
> It's not a policy, it's a hardware capability. There are some non-probeable
> reasons why stalling mode is unsafe or unusable:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/474530.html
Ok. My point was that the wording above is an imperative -- it tells
the kernel to enable stall mode, not if/why it is safe to do so (i.e. it
is a policy, not a property).
It sounds like that's just a wording issue. Something like
"arm,stalling-is-usable" (along with a descrition of when that
can/should be in the DT) would be vastly better.
> Some of these are specific to the SMMU implementation (e.g. whether or not
> the SS bit can remain set without reasserting the IRQ) and some are specific
> to the integration (e.g. whether or not stalling an endpoint can deadlock
> the SoC). The key point is that, without support from both the
> implementation and the integration, stalls are unusable.
Ok.
> > > > static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> > > > @@ -824,6 +852,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
> > > >
> > > > /* SCTLR */
> > > > reg = SCTLR_CFIE | SCTLR_CFRE | SCTLR_AFE | SCTLR_TRE | SCTLR_M;
> > > > + if (smmu->options & ARM_SMMU_OPT_ENABLE_STALL)
> > > > + reg |= SCTLR_CFCFG;
> > >
> > > I wonder if this should also be predicated on the compatible string, so
> > > that the "arm,smmu-enable-stall" property is ignored (with a warning) if
> > > the compatible string isn't specific enough to identify an implementation
> > > with the required SS behaviour? On the other hand, it feels pretty
> > > redundant and a single "stalling works" property is all we need.
> >
> > Can you elaborate on what "stalling works" entails? Is that just the SS
> > bit behaviour? are there integration or endpoint-specific things that we
> > need to care about?
>
> See above. The "stalling works" property (arm,smmu-enable-stall) would
> indicate that both the implementation *and* the integration are such
> that stalling is usable for demand paging. I suspect there are endpoints
> that can't deal with stalls (e.g. they might timeout and signal a RAS
> event), but in that case their respective device drivers should ensure
> that any DMA buffers are pinned and/or register a fault handler to
> request termination of the faulting transaction.
Ok. It would be good to elaborate on what "stalling is useable" means in
the property description. i.e. what specificallty the implementation and
integration need to ensure.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCHv2 0/5] Support for Marvell switches with integrated CPUs
From: Marcin Wojtas @ 2017-01-05 14:09 UTC (permalink / raw)
To: Chris Packham
Cc: linux-arm-kernel@lists.infradead.org, Mark Rutland, Andrew Lunn,
Geert Uytterhoeven, Michael Turquette, Laxman Dewangan, linux-clk,
Florian Fainelli, Juri Lelli, Russell King, Thierry Reding,
Linus Walleij, Sebastian Hesselbarth, devicetree@vger.kernel.org,
Jason Cooper, Arnd Bergmann, Kalyan Kinthada, Rob Herring
In-Reply-To: <20170105033641.6212-1-chris.packham@alliedtelesis.co.nz>
Hi Chris,
Thanks a lot for your work and v2. Can you please add changelog
between patchset versions in your cover letter?
Best regards,
Marcin
2017-01-05 4:36 GMT+01:00 Chris Packham <chris.packham@alliedtelesis.co.nz>:
> The 98DX3236, 98DX3336 and 98DX4251 are a set of switch ASICs with
> integrated CPUs. They CPU block is common within these product lines and
> (as far as I can tell/have been told) is based on the Armada XP. There
> are a few differences due to the fact they have to squeeze the CPU into
> the same package as the switch.
>
> Chris Packham (4):
> clk: mvebu: support for 98DX3236 SoC
> arm: mvebu: support for SMP on 98DX3336 SoC
> arm: mvebu: Add device tree for 98DX3236 SoCs
> arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards
>
> Kalyan Kinthada (1):
> pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
>
> Documentation/devicetree/bindings/arm/cpus.txt | 1 +
> .../bindings/arm/marvell/98dx3236-resume-ctrl.txt | 18 ++
> .../devicetree/bindings/arm/marvell/98dx3236.txt | 23 ++
> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 1 +
> .../pinctrl/marvell,armada-98dx3236-pinctrl.txt | 46 ++++
> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 247 +++++++++++++++++++++
> arch/arm/boot/dts/armada-xp-98dx3336.dtsi | 78 +++++++
> arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 92 ++++++++
> arch/arm/boot/dts/db-dxbc2.dts | 159 +++++++++++++
> arch/arm/boot/dts/db-xc3-24g4xg.dts | 155 +++++++++++++
> arch/arm/mach-mvebu/Makefile | 1 +
> arch/arm/mach-mvebu/common.h | 1 +
> arch/arm/mach-mvebu/platsmp.c | 43 ++++
> arch/arm/mach-mvebu/pmsu-98dx3236.c | 69 ++++++
> drivers/clk/mvebu/Makefile | 2 +-
> drivers/clk/mvebu/armada-xp.c | 42 ++++
> drivers/clk/mvebu/clk-cpu.c | 33 ++-
> drivers/clk/mvebu/mv98dx3236-corediv.c | 207 +++++++++++++++++
> drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 155 +++++++++++++
> 19 files changed, 1369 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
> create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
> create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx3336.dtsi
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx4251.dtsi
> create mode 100644 arch/arm/boot/dts/db-dxbc2.dts
> create mode 100644 arch/arm/boot/dts/db-xc3-24g4xg.dts
> create mode 100644 arch/arm/mach-mvebu/pmsu-98dx3236.c
> create mode 100644 drivers/clk/mvebu/mv98dx3236-corediv.c
>
> --
> 2.11.0.24.ge6920cf
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND 2/2] arm64: dts: Add dts files for Hisilicon Hi3660 SoC
From: Andy Gross @ 2017-01-05 14:14 UTC (permalink / raw)
To: Chen Feng
Cc: xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
suzhuangluan-C8/M+/jPZTeaMJb+Lgu22Q,
xuyiping-C8/M+/jPZTeaMJb+Lgu22Q
In-Reply-To: <1482744972-56622-2-git-send-email-puck.chen-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
On Mon, Dec 26, 2016 at 05:36:12PM +0800, Chen Feng wrote:
> Add initial dtsi file to support Hisilicon Hi3660 SoC with
> support of Octal core CPUs in two clusters(4 * A53 & 4 * A73).
>
> Also add dts file to support HiKey960 development board which
> based on Hi3660 SoC.
> The output console is earlycon "earlycon=pl011,0xfdf05000".
> And the con_init uart5 with a fixed clock, which already
> configured at bootloader.
>
> When clock is available, the uart5 will be modified.
>
> Tested on HiKey960 Board.
>
> Signed-off-by: Chen Feng <puck.chen-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
> ---
> arch/arm64/boot/dts/hisilicon/Makefile | 1 +
> arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 34 +++++
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 156 ++++++++++++++++++++++
> 3 files changed, 191 insertions(+)
> create mode 100644 arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> create mode 100644 arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>
> diff --git a/arch/arm64/boot/dts/hisilicon/Makefile b/arch/arm64/boot/dts/hisilicon/Makefile
> index d5f43a0..b633b5d 100644
> --- a/arch/arm64/boot/dts/hisilicon/Makefile
> +++ b/arch/arm64/boot/dts/hisilicon/Makefile
> @@ -1,4 +1,5 @@
> dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
> +dtb-$(CONFIG_ARCH_HISI) += hi3660-hikey960.dtb
> dtb-$(CONFIG_ARCH_HISI) += hip05-d02.dtb
> dtb-$(CONFIG_ARCH_HISI) += hip06-d03.dtb
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> new file mode 100644
> index 0000000..3d7aead
> --- /dev/null
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> @@ -0,0 +1,34 @@
> +/*
> + * dts file for Hisilicon HiKey960 Development Board
> + *
> + * Copyright (C) 2016, Hisilicon Ltd.
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "hi3660.dtsi"
> +
> +/ {
> + model = "HiKey960";
> + compatible = "hisilicon,hi3660";
> +
> + aliases {
> + serial5 = &uart5; /* console UART */
> + };
> +
> + chosen {
> + stdout-path = "serial5:115200n8";
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x00400000 0x0 0xBFE00000>;
Use lower case letters for hex numbers. 0xbfe00000.
> + };
> +
> + soc {
> + uart5: uart@fdf05000 {
> + status = "ok";
> + };
> + };
> +};
<snip>
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v4 0/2] Add support for the ethernet switch on the ESPRESSObin
From: Gregory CLEMENT @ 2017-01-05 14:25 UTC (permalink / raw)
To: David Miller
Cc: Andrew Lunn, Romain Perier, Vivien Didelot, Florian Fainelli,
Jason Cooper, Sebastian Hesselbarth,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai
In-Reply-To: <20161221125734.1034-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi David,
On mer., déc. 21 2016, Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> This set of patches adds support for the Marvell ethernet switch 88E6341.
> It also add the devicetree definition of this switch to the DT board.
The forth version of this series had been sent while the net-next merge
window was closed so I think it was missed.
Do you want that we send it again on the netdev mainling list?
Thanks,
Gregory
>
> Romain Perier (2):
> net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >=
> num_of_ports
> net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
>
> drivers/net/dsa/mv88e6xxx/chip.c | 48 ++++++++++++++++++++++++++++++-----
> drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 4 ++-
> 2 files changed, 45 insertions(+), 7 deletions(-)
>
> --
>
> Note: As requested by Gregory, I have removed the patch for the DT (already merged).
>
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] [linux-next] bus:qcom : Fix typo in qcom,ebi2.txt
From: Masanari Iida @ 2017-01-05 14:43 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A
Cc: Masanari Iida
This patch fix 2 spelling typos found in qcom,ebi2.txt
Signed-off-by: Masanari Iida <standby24x7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/devicetree/bindings/bus/qcom,ebi2.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/bus/qcom,ebi2.txt b/Documentation/devicetree/bindings/bus/qcom,ebi2.txt
index 920681f552db..5a7d567f6833 100644
--- a/Documentation/devicetree/bindings/bus/qcom,ebi2.txt
+++ b/Documentation/devicetree/bindings/bus/qcom,ebi2.txt
@@ -51,7 +51,7 @@ Required properties:
- compatible: should be one of:
"qcom,msm8660-ebi2"
"qcom,apq8060-ebi2"
-- #address-cells: shoule be <2>: the first cell is the chipselect,
+- #address-cells: should be <2>: the first cell is the chipselect,
the second cell is the offset inside the memory range
- #size-cells: should be <1>
- ranges: should be set to:
@@ -64,7 +64,7 @@ Required properties:
- reg: two ranges of registers: EBI2 config and XMEM config areas
- reg-names: should be "ebi2", "xmem"
- clocks: two clocks, EBI_2X and EBI
-- clock-names: shoule be "ebi2x", "ebi2"
+- clock-names: should be "ebi2x", "ebi2"
Optional subnodes:
- Nodes inside the EBI2 will be considered device nodes.
@@ -100,7 +100,7 @@ Optional properties arrays for FAST chip selects:
assertion, with respect to the cycle where ADV (address valid) is asserted.
2 means 2 cycles between ADV and OE. Valid values 0, 1, 2 or 3.
- qcom,xmem-read-hold-cycles: the length in cycles of the first segment of a
- read transfer. For a single read trandfer this will be the time from CS
+ read transfer. For a single read transfer this will be the time from CS
assertion to OE assertion. Valid values 0 thru 15.
--
2.11.0.161.g6610af872f64
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Will Deacon @ 2017-01-05 14:47 UTC (permalink / raw)
To: Mark Rutland
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Jordan Crouse,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <20170105140720.GA25868@leverpostej>
On Thu, Jan 05, 2017 at 02:07:31PM +0000, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 02:00:05PM +0000, Will Deacon wrote:
> > On Thu, Jan 05, 2017 at 12:08:57PM +0000, Mark Rutland wrote:
> > > On Thu, Jan 05, 2017 at 11:55:29AM +0000, Will Deacon wrote:
> > > > On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote:
> > > > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > > > > index ef465b0..5f405a6 100644
> > > > > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > > > > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > > > > @@ -68,6 +68,9 @@ conditions.
> > > > > aliases of secure registers have to be used during
> > > > > SMMU configuration.
> > > > >
> > > > > +- arm,smmu-enable-stall : Enable stall mode to stall memory transactions
> > > > > + and resume after fault is handled
> > >
> > > The wording here seems to describe a policy rather than a property.
> > >
> > > Can you elaborate on when/why this is required/preferred/valid?
> >
> > It's not a policy, it's a hardware capability. There are some non-probeable
> > reasons why stalling mode is unsafe or unusable:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/474530.html
>
> Ok. My point was that the wording above is an imperative -- it tells
> the kernel to enable stall mode, not if/why it is safe to do so (i.e. it
> is a policy, not a property).
>
> It sounds like that's just a wording issue. Something like
> "arm,stalling-is-usable" (along with a descrition of when that
> can/should be in the DT) would be vastly better.
Why does it need a vendor prefix? I'm not down on the convention there.
"stalling-safe" or "stalling-supported" are alternative strings.
> > > > > static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> > > > > @@ -824,6 +852,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
> > > > >
> > > > > /* SCTLR */
> > > > > reg = SCTLR_CFIE | SCTLR_CFRE | SCTLR_AFE | SCTLR_TRE | SCTLR_M;
> > > > > + if (smmu->options & ARM_SMMU_OPT_ENABLE_STALL)
> > > > > + reg |= SCTLR_CFCFG;
> > > >
> > > > I wonder if this should also be predicated on the compatible string, so
> > > > that the "arm,smmu-enable-stall" property is ignored (with a warning) if
> > > > the compatible string isn't specific enough to identify an implementation
> > > > with the required SS behaviour? On the other hand, it feels pretty
> > > > redundant and a single "stalling works" property is all we need.
> > >
> > > Can you elaborate on what "stalling works" entails? Is that just the SS
> > > bit behaviour? are there integration or endpoint-specific things that we
> > > need to care about?
> >
> > See above. The "stalling works" property (arm,smmu-enable-stall) would
> > indicate that both the implementation *and* the integration are such
> > that stalling is usable for demand paging. I suspect there are endpoints
> > that can't deal with stalls (e.g. they might timeout and signal a RAS
> > event), but in that case their respective device drivers should ensure
> > that any DMA buffers are pinned and/or register a fault handler to
> > request termination of the faulting transaction.
>
> Ok. It would be good to elaborate on what "stalling is useable" means in
> the property description. i.e. what specificallty the implementation and
> integration need to ensure.
We can describe some of those guarantees in the property description, but
it's difficult to enumerate them exhaustively. For example, you wouldn't
want stalling to lead to data corruption, denial of service, or for the
thing to catch fire, but having those as explicit requirements is a bit
daft. It's also impossible to check that you thought of everything.
Aside from renaming the option, I'm really after an opinion on whether
it's better to have one property or combine it with the compatible
string, because I can see benefits of both and don't much care either
way.
Will
^ 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