* [PATCH v6 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
From: Bartosz Golaszewski @ 2016-12-13 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9d5fa409-bb4f-f62b-2548-0a3b82228e08@ti.com>
2016-12-13 9:46 GMT+01:00 Tomi Valkeinen <tomi.valkeinen@ti.com>:
> Hi,
>
> On 12/12/16 15:05, Bartosz Golaszewski wrote:
>
>> +&lcdc {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&lcd_pins>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + lcdc_out: port at 1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + lcdc_out_vga: endpoint {
>> + reg = <0>;
>> + remote-endpoint = <&vga_bridge_in>;
>> + };
>> + };
>> + };
>> +};
>>
>
> This is not correct. LCDC has just one output, so port at 1 doesn't make
> sense. It's port at 0. But with just one port, you can leave "ports" away.
> And you don't need the port's label for anything, if I'm not mistaken. So:
>
> &lcdc {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&lcd_pins>;
>
> port {
> lcdc_out_vga: endpoint {
> remote-endpoint = <&vga_bridge_in>;
> };
> };
> };
>
> Tomi
>
Right, fixed in v7.
Thanks,
Bartosz
^ permalink raw reply
* [PATCH v7 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.
Specify the max-pixelclock property for the display node for
da850-lcdk.
[1] http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 6b0ef3d..58b1566 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -462,6 +462,7 @@
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
+ max-pixelclock = <37500>;
status = "disabled";
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v7 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
Add the vga-bridge node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 51 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index afcb482..1ae2260 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -51,6 +51,45 @@
system-clock-frequency = <24576000>;
};
};
+
+ vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ ddc-i2c-bus = <&i2c0>;
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
};
&pmx_core {
@@ -236,3 +275,15 @@
&memctrl {
status = "okay";
};
+
+&lcdc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+
+ port {
+ lcdc_out_vga: endpoint {
+ remote-endpoint = <&vga_bridge_in>;
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
THS8135 is a configurable video DAC, but no configuration is actually
necessary to make it work.
For now use the dumb-vga-dac driver to support it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index e570698..86e9f9c 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -237,6 +237,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
static const struct of_device_id dumb_vga_match[] = {
{ .compatible = "dumb-vga-dac" },
+ { .compatible = "ti,ths8135" },
{},
};
MODULE_DEVICE_TABLE(of, dumb_vga_match);
--
2.9.3
^ permalink raw reply related
* [PATCH v7 2/5] drm: bridge: add DT bindings for TI ths8135
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/display/bridge/ti,ths8135.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
new file mode 100644
index 0000000..6ec1a88
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
@@ -0,0 +1,46 @@
+THS8135 Video DAC
+-----------------
+
+This is the binding for Texas Instruments THS8135 Video DAC bridge.
+
+Required properties:
+
+- compatible: Must be "ti,ths8135"
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+Example
+-------
+
+vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v7 1/5] ARM: dts: da850: rename the display node label
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
The label is also 'display', but change it to 'lcdc' to make it clear
what the underlying hardware is.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..6b0ef3d 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -458,7 +458,7 @@
dma-names = "tx", "rx";
};
- display: display at 213000 {
+ lcdc: display at 213000 {
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
--
2.9.3
^ permalink raw reply related
* [PATCH v7 0/5] ARM: dts: da850: tilcdc related DT changes
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
v2 -> v3:
- make the commit message in patch [2/2] more detailed
- move the max-pixelclock property to da850.dtsi as the limit
affects all da850-based boards
v3 -> v4:
- remove the input port from the display node
- move the display ports node to da850-lcdk.dts
- rename the vga_bridge node to vga-bridge
- move the LCDC pins to the LCDC node (from the vga bridge node)
v4 -> v5:
- rename the display label to lcdc
- instead of using the 'dumb-vga-dac' compatible, add bindings for
ti,ths8135 and use it as the vga-bridge node compatible
v5 -> v6:
- drop the endpoint numbers for nodes with single endpoints
- split patch 2/4 from v5 into two separate patches: one adding DT
bindings and one adding actual support for ths8135
v6 -> v7:
- simplified patch 4/5 by removing unnecessary properties from ports
and endpoints nodes
Bartosz Golaszewski (5):
ARM: dts: da850: rename the display node label
drm: bridge: add DT bindings for TI ths8135
drm: bridge: add support for TI ths8135
ARM: dts: da850-lcdk: add the vga-bridge node
ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
.../bindings/display/bridge/ti,ths8135.txt | 46 +++++++++++++++++++
arch/arm/boot/dts/da850-lcdk.dts | 51 ++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 3 +-
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
4 files changed, 100 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
--
2.9.3
^ permalink raw reply
* [PATCH v6 5/5] ARM: configs: stm32: Add I2C support for STM32 defconfig
From: Alexandre Torgue @ 2016-12-13 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481559342-6106-6-git-send-email-cedric.madianga@gmail.com>
Hi Cedric,
On 12/12/2016 05:15 PM, M'boumba Cedric Madianga wrote:
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Can you please add a commit message.
Thx in advance
Alex
> ---
> arch/arm/configs/stm32_defconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
> index e7b56d4..9494eaf 100644
> --- a/arch/arm/configs/stm32_defconfig
> +++ b/arch/arm/configs/stm32_defconfig
> @@ -52,6 +52,9 @@ CONFIG_SERIAL_NONSTANDARD=y
> CONFIG_SERIAL_STM32=y
> CONFIG_SERIAL_STM32_CONSOLE=y
> # CONFIG_HW_RANDOM is not set
> +CONFIG_I2C=y
> +CONFIG_I2C_CHARDEV=y
> +CONFIG_I2C_STM32F4=y
> # CONFIG_HWMON is not set
> # CONFIG_USB_SUPPORT is not set
> CONFIG_NEW_LEDS=y
>
^ permalink raw reply
* [PATCH v6 4/5] ARM: dts: stm32: Add I2C1 support for STM32429 eval board
From: Alexandre Torgue @ 2016-12-13 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481559342-6106-5-git-send-email-cedric.madianga@gmail.com>
Hi Cedric,
On 12/12/2016 05:15 PM, M'boumba Cedric Madianga wrote:
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Can you please add a commit message.
> ---
> arch/arm/boot/dts/stm32429i-eval.dts | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
> index afb90bc..74e0045 100644
> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> @@ -141,3 +141,9 @@
> pinctrl-names = "default";
> status = "okay";
> };
> +
> +&i2c1 {
> + pinctrl-0 = <&i2c1_pins_b>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
>
^ permalink raw reply
* [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM
From: Russell King - ARM Linux @ 2016-12-13 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211131255.3221-1-afzal.mohd.ma@gmail.com>
On Sun, Dec 11, 2016 at 06:42:55PM +0530, Afzal Mohammed wrote:
> Remap exception base address to start of RAM in Kernel in !MMU mode.
>
> Based on existing Kconfig help, Kernel was expecting it to be
> configured by external support. Also earlier it was not possible to
> copy the exception table to start of RAM due to Kconfig dependency,
> which has been fixed by a change prior to this.
>
> Kernel text start at an offset of at least 32K to account for page
> tables in MMU case. On a !MMU build too this space is kept aside, and
> since 2 pages (8K) is the maximum for exception plus stubs, it can be
> placed at the start of RAM.
>
> Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
> ---
>
> i am a bit shaky about this change, though it works here on Cortex-A9,
> this probably would have to be made robust so as to not cause issue on
> other v7-A's upon trying to do !MMU (this won't affect normal MMU boot),
> or specifically where security extensions are not enabled. Also effect
> of hypervisor extension also need to be considered. Please let know if
> any better ways to handle this.
>
>
> arch/arm/Kconfig-nommu | 6 +++---
> arch/arm/kernel/head-nommu.S | 6 ++++++
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu
> index b7576349528c..f57fbe3d5eb0 100644
> --- a/arch/arm/Kconfig-nommu
> +++ b/arch/arm/Kconfig-nommu
> @@ -46,9 +46,9 @@ config REMAP_VECTORS_TO_RAM
> If your CPU provides a remap facility which allows the exception
> vectors to be mapped to writable memory, say 'n' here.
>
> - Otherwise, say 'y' here. In this case, the kernel will require
> - external support to redirect the hardware exception vectors to
> - the writable versions located at DRAM_BASE.
> + Otherwise, say 'y' here. In this case, the kernel will
> + redirect the hardware exception vectors to the writable
> + versions located at DRAM_BASE.
>
> config ARM_MPU
> bool 'Use the ARM v7 PMSA Compliant MPU'
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index 6b4eb27b8758..ac31c9647830 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -158,6 +158,12 @@ __after_proc_init:
> bic r0, r0, #CR_V
> #endif
> mcr p15, 0, r0, c1, c0, 0 @ write control reg
> +
> +#ifdef CONFIG_REMAP_VECTORS_TO_RAM
> + mov r3, #CONFIG_VECTORS_BASE @ read VECTORS_BASE
> + mcr p15, 0, r3, c12, c0, 0 @ write to VBAR
> +#endif
> +
Is there really any need to do this in head.S ? I believe it's
entirely possible to do it later - arch/arm/mm/nommu.c:paging_init().
Also, if the region setup for the vectors was moved as well, it would
then be possible to check the ID registers to determine whether this
is supported, and make the decision where to locate the vectors base
more dynamically.
That leaves one pr_notice() call using the CONFIG_VECTORS_BASE
constant...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v6 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
From: Alexandre Torgue @ 2016-12-13 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481559342-6106-4-git-send-email-cedric.madianga@gmail.com>
Hi Cedric,
On 12/12/2016 05:15 PM, M'boumba Cedric Madianga wrote:
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Please Add a commit message.
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index 7de52ee..cbdece7 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -48,6 +48,7 @@
> #include "skeleton.dtsi"
> #include "armv7-m.dtsi"
> #include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
> +#include <dt-bindings/mfd/stm32f4-rcc.h>
>
> / {
> clocks {
> @@ -337,6 +338,16 @@
> slew-rate = <2>;
> };
> };
> +
> + i2c1_pins_b: i2c1 at 0 {
> + pins1 {
> + pinmux = <STM32F429_PB9_FUNC_I2C1_SDA>;
> + drive-open-drain;
> + };
> + pins2 {
> + pinmux = <STM32F429_PB6_FUNC_I2C1_SCL>;
> + };
> + };
> };
>
> rcc: rcc at 40023810 {
> @@ -409,6 +420,18 @@
> interrupts = <80>;
> clocks = <&rcc 0 38>;
> };
> +
> + i2c1: i2c at 40005400 {
Can you check the order on device node please ? (should follow base@)
> + compatible = "st,stm32f4-i2c";
> + reg = <0x40005400 0x400>;
> + interrupts = <31>,
> + <32>;
> + resets = <&rcc STM32F4_APB1_RESET(I2C1)>;
> + clocks = <&rcc 0 STM32F4_APB1_CLOCK(I2C1)>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> };
> };
>
>
^ permalink raw reply
* Re: EXT: imx-sdma UART series failed for i.MX51
From: Alexander Shiyan @ 2016-12-13 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4f8cf2ee-3cd6-31ce-dc12-8a763f19f8e5@ge.com>
>???????????, 12 ??????? 2016, 16:48 +03:00 ?? "Han, Nandor (GE Healthcare)" <nandor.han@ge.com>:
>
>Hi Alexander,
>????Thanks for info. I have already posted a patch that probably will
>fix this issue.
>
>https://lkml.org/lkml/2016/10/11/319
>
>It was already tested on imx6 and imx53. Let me know how it works.
>
>Reference:
>http://lists-archives.com/linux-kernel/28679793-ext-pre-4-9-rc-dma-regression-imx6-sound-etc.html
Yes, it helps me, thanks!
---
^ permalink raw reply
* [PATCH 1/2] ARM: dts: dra7-evm: Remove pinmux configurations for erratum i869
From: Sekhar Nori @ 2016-12-13 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b80e3cbc8a377abdb40ab11de78ce0b3fb67596f.1480411308.git.nsekhar@ti.com>
On Tuesday 29 November 2016 02:54 PM, Sekhar Nori wrote:
> A side-effect of this patch is that NAND support is removed. NAND
> pins clash with VOUT3 on DRA7-EVM. U-Boot selects VOUT3 over NAND
> as per TI EVM application needs.
I claimed this ..
> &gpmc {
> status = "okay";
> - pinctrl-names = "default";
> - pinctrl-0 = <&nand_flash_x16>;
> ranges = <0 0 0x08000000 0x01000000>; /* minimum GPMC partition = 16MB */
> nand at 0,0 {
> compatible = "ti,omap2-nand";
.. but forgot to keep the gpmc node disabled. I will fix this and send a
v2. dra72-evm-common.dtsi needs a similar patch. Will include that in v2
as well.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v1 2/3] clk: rockchip: add clock controller for rk3328
From: Shawn Lin @ 2016-12-13 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481618869-1239-3-git-send-email-zhangqing@rock-chips.com>
Hi, Elaine,
I always only keep an eye for mmc stuff here. :)
On 2016/12/13 16:47, Elaine Zhang wrote:
> Add the clock tree definition for the new rk3328 SoC.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
----8<--------------
> +
> + /* PD_MMC */
> + MMC(SCLK_SDMMC_DRV, "sdmmc_drv", "sclk_sdmmc",
> + RK3328_SDMMC_CON0, 1),
> + MMC(SCLK_SDMMC_SAMPLE, "sdmmc_sample", "sclk_sdmmc",
> + RK3328_SDMMC_CON1, 0),
> +
All of offset for these *_sample are wrong, and they should be 1
, the same as *_drv. You could refer to P565 of TRM instead the
section of CRU for these details.
> + MMC(SCLK_SDIO_DRV, "sdio_drv", "sclk_sdio",
> + RK3328_SDIO_CON0, 1),
> + MMC(SCLK_SDIO_SAMPLE, "sdio_sample", "sclk_sdio",
> + RK3328_SDIO_CON1, 0),
> +
> + MMC(SCLK_EMMC_DRV, "emmc_drv", "sclk_emmc",
> + RK3328_EMMC_CON0, 1),
> + MMC(SCLK_EMMC_SAMPLE, "emmc_sample", "sclk_emmc",
> + RK3328_EMMC_CON1, 0),
> +
> + MMC(SCLK_SDMMC_EXT_DRV, "sdmmc_ext_drv", "sclk_sdmmc_ext",
> + RK3328_SDMMC_EXT_CON0, 1),
> + MMC(SCLK_SDMMC_EXT_SAMPLE, "sdmmc_ext_sample", "sclk_sdmmc_ext",
> + RK3328_SDMMC_EXT_CON1, 0),
> +};
> +
----8<--------
> +#define RK3328_SDMMC_CON0 0x380
> +#define RK3328_SDMMC_CON1 0x384
> +#define RK3328_SDIO_CON0 0x388
> +#define RK3328_SDIO_CON1 0x38c
> +#define RK3328_EMMC_CON0 0x390
> +#define RK3328_EMMC_CON1 0x394
> +#define RK3328_SDMMC_EXT_CON0 0x398
> +#define RK3328_SDMMC_EXT_CON1 0x39C
Just wondering is it worth, but this uppercase 'C' isn't
consistent with the former lowercase
> +
> #define RK3368_PLL_CON(x) RK2928_PLL_CON(x)
> #define RK3368_CLKSEL_CON(x) ((x) * 0x4 + 0x100)
> #define RK3368_CLKGATE_CON(x) ((x) * 0x4 + 0x200)
> @@ -130,6 +152,7 @@
> enum rockchip_pll_type {
> pll_rk3036,
> pll_rk3066,
> + pll_rk3328,
> pll_rk3399,
> };
>
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM
From: Vladimir Murzin @ 2016-12-13 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211131255.3221-1-afzal.mohd.ma@gmail.com>
On 11/12/16 13:12, Afzal Mohammed wrote:
> Remap exception base address to start of RAM in Kernel in !MMU mode.
>
> Based on existing Kconfig help, Kernel was expecting it to be
> configured by external support. Also earlier it was not possible to
> copy the exception table to start of RAM due to Kconfig dependency,
> which has been fixed by a change prior to this.
>
> Kernel text start at an offset of at least 32K to account for page
> tables in MMU case. On a !MMU build too this space is kept aside, and
> since 2 pages (8K) is the maximum for exception plus stubs, it can be
> placed at the start of RAM.
>
> Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
> ---
>
> i am a bit shaky about this change, though it works here on Cortex-A9,
> this probably would have to be made robust so as to not cause issue on
> other v7-A's upon trying to do !MMU (this won't affect normal MMU boot),
> or specifically where security extensions are not enabled. Also effect
> of hypervisor extension also need to be considered. Please let know if
> any better ways to handle this.
You might need to check ID_PFR1 for that.
>
>
> arch/arm/Kconfig-nommu | 6 +++---
> arch/arm/kernel/head-nommu.S | 6 ++++++
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu
> index b7576349528c..f57fbe3d5eb0 100644
> --- a/arch/arm/Kconfig-nommu
> +++ b/arch/arm/Kconfig-nommu
> @@ -46,9 +46,9 @@ config REMAP_VECTORS_TO_RAM
> If your CPU provides a remap facility which allows the exception
> vectors to be mapped to writable memory, say 'n' here.
>
> - Otherwise, say 'y' here. In this case, the kernel will require
> - external support to redirect the hardware exception vectors to
> - the writable versions located at DRAM_BASE.
> + Otherwise, say 'y' here. In this case, the kernel will
> + redirect the hardware exception vectors to the writable
> + versions located at DRAM_BASE.
>
> config ARM_MPU
> bool 'Use the ARM v7 PMSA Compliant MPU'
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index 6b4eb27b8758..ac31c9647830 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -158,6 +158,12 @@ __after_proc_init:
> bic r0, r0, #CR_V
> #endif
> mcr p15, 0, r0, c1, c0, 0 @ write control reg
> +
> +#ifdef CONFIG_REMAP_VECTORS_TO_RAM
> + mov r3, #CONFIG_VECTORS_BASE @ read VECTORS_BASE
ldr r3,=CONFIG_VECTORS_BASE
would be more robust. I hit this in [1]
[1] https://www.spinics.net/lists/arm-kernel/msg546825.html
Cheers
Vladimir
> + mcr p15, 0, r3, c12, c0, 0 @ write to VBAR
> +#endif
> +
> #elif defined (CONFIG_CPU_V7M)
> /* For V7M systems we want to modify the CCR similarly to the SCTLR */
> #ifdef CONFIG_CPU_DCACHE_DISABLE
>
^ permalink raw reply
* [PATCH v6 7/8] ARM: dts: stm32: add Timers driver for stm32f429 MCU
From: Benjamin Gaignard @ 2016-12-13 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212185943.ph7njaqb2lxtgdn4@rob-hp-laptop>
2016-12-12 19:59 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Fri, Dec 09, 2016 at 03:15:18PM +0100, Benjamin Gaignard wrote:
>> Add Timers and it sub-nodes into DT for stm32f429 family.
>>
>> version 6:
>> - split patch in two: one for SoC family and one for stm32f469
>> discovery board.
>>
>> version 5:
>> - rename gptimer node to timers
>> - re-order timers node par addresses
>>
>> version 4:
>> - remove unwanted indexing in pwm@ and timer@ node name
>> - use "reg" instead of additional parameters to set timer
>> configuration
>>
>> version 3:
>> - use "st,stm32-timer-trigger" in DT
>>
>> version 2:
>> - use parameters to describe hardware capabilities
>> - do not use references for pwm and iio timer subnodes
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> arch/arm/boot/dts/stm32f429.dtsi | 275 +++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 275 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
>> index bca491d..d0fb9cc 100644
>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> @@ -355,6 +355,21 @@
>> slew-rate = <2>;
>> };
>> };
>> +
>> + pwm1_pins: pwm at 1 {
>
> No reg prop, so should not have a unit-address. Given the names in the
> define below, seems like "timer1" would be appropriate.
>
Here pins muxing is only targeting PWM part of the the MFD , that why I have
labeled it with "pwm".
>> + pins {
>> + pinmux = <STM32F429_PA8_FUNC_TIM1_CH1>,
>> + <STM32F429_PB13_FUNC_TIM1_CH1N>,
>> + <STM32F429_PB12_FUNC_TIM1_BKIN>;
>> + };
>> + };
>> +
>> + pwm3_pins: pwm at 3 {
>> + pins {
>> + pinmux = <STM32F429_PB4_FUNC_TIM3_CH1>,
>> + <STM32F429_PB5_FUNC_TIM3_CH2>;
>> + };
>> + };
>> };
>>
>> rcc: rcc at 40023810 {
>> @@ -426,6 +441,266 @@
>> interrupts = <80>;
>> clocks = <&rcc 0 38>;
>> };
>> +
>> + timers2: timers at 40000000 {
>
> timer at ...
>
> It may be more than just a timer, there's not a better generic name.
"timer" is already used in DT for clocksource driver.
"timers" cover "advanced-control", "generic" and "basic" hardware timers IPs,
which share the same registers mapping (only the level of feature are different)
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40000000 0x400>;
>> + clocks = <&rcc 0 128>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <1>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers3: timers at 40000400 {
>
> ditto
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40000400 0x400>;
>> + clocks = <&rcc 0 129>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <2>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers4: timers at 40000800 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40000800 0x400>;
>> + clocks = <&rcc 0 130>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <3>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers5: timers at 40000C00 {
>
> timer at ...
>
> And use lowercase hex.
ok
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40000C00 0x400>;
>
> ditto
>
>> + clocks = <&rcc 0 131>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <4>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers6: timers at 40001000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40001000 0x400>;
>> + clocks = <&rcc 0 132>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <5>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers7: timers at 40001400 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40001400 0x400>;
>> + clocks = <&rcc 0 133>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <6>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers12: timers at 40001800 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40001800 0x400>;
>> + clocks = <&rcc 0 134>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <9>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers13: timers at 40001C00 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40001C00 0x400>;
>> + clocks = <&rcc 0 135>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers14: timers at 40002000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40002000 0x400>;
>> + clocks = <&rcc 0 136>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers1: timers at 40010000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40010000 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <0>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers8: timers at 40010400 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40010400 0x400>;
>> + clocks = <&rcc 0 161>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <7>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers9: timers at 40014000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40014000 0x400>;
>> + clocks = <&rcc 0 176>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <8>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers10: timers at 40014400 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40014400 0x400>;
>> + clocks = <&rcc 0 177>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers11: timers at 40014800 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40014800 0x400>;
>> + clocks = <&rcc 0 178>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> + };
>> };
>> };
>>
>> --
>> 1.9.1
>>
^ permalink raw reply
* [PATCH v6 1/8] MFD: add bindings for STM32 Timers driver
From: Benjamin Gaignard @ 2016-12-13 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212185149.rt3xqpn3mbaavb4l@rob-hp-laptop>
2016-12-12 19:51 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Fri, Dec 09, 2016 at 03:15:12PM +0100, Benjamin Gaignard wrote:
>> Add bindings information for STM32 Timers
>>
>> version 6:
>> - rename stm32-gtimer to stm32-timers
>> - change compatible
>> - add description about the IPs
>>
>> version 2:
>> - rename stm32-mfd-timer to stm32-gptimer
>> - only keep one compatible string
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++++++++++++++++++++++
>> 1 file changed, 46 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
>> new file mode 100644
>> index 0000000..b30868e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
>> @@ -0,0 +1,46 @@
>> +STM32 Timers driver bindings
>> +
>> +This IP provides 3 types of timer along with PWM functionality:
>> +- advanced-control timers consist of a 16-bit auto-reload counter driven by a programmable
>> + prescaler, break input feature, PWM outputs and complementary PWM ouputs channels.
>> +- general-purpose timers consist of a 16-bit or 32-bit auto-reload counter driven by a
>> + programmable prescaler and PWM outputs.
>> +- basic timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.
>> +
>> +Required parameters:
>> +- compatible: must be "st,stm32-timers"
>> +
>> +- reg: Physical base address and length of the controller's
>> + registers.
>> +- clock-names: Set to "clk_int".
>
> 'clk' is redundant. Also, you don't really need -names when there is
> only one of them.
I use devm_regmap_init_mmio_clk() which get the clock by it name so
I have to define it in DT.
>> +- clocks: Phandle to the clock used by the timer module.
>> + For Clk properties, please refer to ../clock/clock-bindings.txt
>> +
>> +Optional parameters:
>> +- resets: Phandle to the parent reset controller.
>> + See ../reset/st,stm32-rcc.txt
>> +
>> +Optional subnodes:
>> +- pwm: See ../pwm/pwm-stm32.txt
>> +- timer: See ../iio/timer/stm32-timer-trigger.txt
>> +
>> +Example:
>> + timers at 40010000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40010000 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + pinctrl-0 = <&pwm1_pins>;
>> + pinctrl-names = "default";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <0>;
>
> You don't need reg here as there is only one. In turn, you don't need
> #address-cells or #size-cells.
I use "reg" to set each timer configuration.
>From hardware point of view they are all the same except for which hardware
signals they could consume and/or send.
"reg" is used as index of the two tables in driver code.
>
>> + };
>> + };
>> --
>> 1.9.1
>>
^ permalink raw reply
* [PATCH v6 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2016-12-13 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481559342-6106-3-git-send-email-cedric.madianga@gmail.com>
Hello,
On Mon, Dec 12, 2016 at 05:15:39PM +0100, M'boumba Cedric Madianga wrote:
> This patch adds support for the STM32F4 I2C controller.
>
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
> ---
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-stm32f4.c | 849 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 860 insertions(+)
> create mode 100644 drivers/i2c/busses/i2c-stm32f4.c
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 0cdc844..2719208 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -886,6 +886,16 @@ config I2C_ST
> This driver can also be built as module. If so, the module
> will be called i2c-st.
>
> +config I2C_STM32F4
> + tristate "STMicroelectronics STM32F4 I2C support"
> + depends on ARCH_STM32 || COMPILE_TEST
> + help
> + Enable this option to add support for STM32 I2C controller embedded
> + in STM32F4 SoCs.
> +
> + This driver can also be built as module. If so, the module
> + will be called i2c-stm32f4.
> +
> config I2C_STU300
> tristate "ST Microelectronics DDC I2C interface"
> depends on MACH_U300
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 1c1bac8..a2c6ff5 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -85,6 +85,7 @@ obj-$(CONFIG_I2C_SH_MOBILE) += i2c-sh_mobile.o
> obj-$(CONFIG_I2C_SIMTEC) += i2c-simtec.o
> obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o
> obj-$(CONFIG_I2C_ST) += i2c-st.o
> +obj-$(CONFIG_I2C_STM32F4) += i2c-stm32f4.o
> obj-$(CONFIG_I2C_STU300) += i2c-stu300.o
> obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o
> obj-$(CONFIG_I2C_TEGRA) += i2c-tegra.o
> diff --git a/drivers/i2c/busses/i2c-stm32f4.c b/drivers/i2c/busses/i2c-stm32f4.c
> new file mode 100644
> index 0000000..89ad579
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-stm32f4.c
> @@ -0,0 +1,849 @@
> +/*
> + * Driver for STMicroelectronics STM32 I2C controller
> + *
> + * Copyright (C) M'boumba Cedric Madianga 2015
> + * Author: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
> + *
> + * This driver is based on i2c-st.c
> + *
> + * License terms: GNU General Public License (GPL), version 2
> + */
If there is a public description available for the device, a link here
would be great.
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset.h>
> +
> +/* STM32F4 I2C offset registers */
> +#define STM32F4_I2C_CR1 0x00
> +#define STM32F4_I2C_CR2 0x04
> +#define STM32F4_I2C_DR 0x10
> +#define STM32F4_I2C_SR1 0x14
> +#define STM32F4_I2C_SR2 0x18
> +#define STM32F4_I2C_CCR 0x1C
> +#define STM32F4_I2C_TRISE 0x20
> +#define STM32F4_I2C_FLTR 0x24
> +
> +/* STM32F4 I2C control 1*/
> +#define STM32F4_I2C_CR1_SWRST BIT(15)
> +#define STM32F4_I2C_CR1_POS BIT(11)
> +#define STM32F4_I2C_CR1_ACK BIT(10)
> +#define STM32F4_I2C_CR1_STOP BIT(9)
> +#define STM32F4_I2C_CR1_START BIT(8)
> +#define STM32F4_I2C_CR1_PE BIT(0)
> +
> +/* STM32F4 I2C control 2 */
> +#define STM32F4_I2C_CR2_FREQ_MASK GENMASK(5, 0)
> +#define STM32F4_I2C_CR2_FREQ(n) ((n & STM32F4_I2C_CR2_FREQ_MASK))
This should better be ((n) & STM32F4_I2C_CR2_FREQ_MASK). There a few
more constants that need the same fix.
> +#define STM32F4_I2C_CR2_ITBUFEN BIT(10)
> +#define STM32F4_I2C_CR2_ITEVTEN BIT(9)
> +#define STM32F4_I2C_CR2_ITERREN BIT(8)
> +#define STM32F4_I2C_CR2_IRQ_MASK (STM32F4_I2C_CR2_ITBUFEN \
> + | STM32F4_I2C_CR2_ITEVTEN \
> + | STM32F4_I2C_CR2_ITERREN)
I'd layout this like:
#define STM32F4_I2C_CR2_IRQ_MASK (STM32F4_I2C_CR2_ITBUFEN | \
STM32F4_I2C_CR2_ITEVTEN | \
STM32F4_I2C_CR2_ITERREN)
which is more usual I think.
> +/* STM32F4 I2C Status 1 */
> +#define STM32F4_I2C_SR1_AF BIT(10)
> +#define STM32F4_I2C_SR1_ARLO BIT(9)
> +#define STM32F4_I2C_SR1_BERR BIT(8)
> +#define STM32F4_I2C_SR1_TXE BIT(7)
> +#define STM32F4_I2C_SR1_RXNE BIT(6)
> +#define STM32F4_I2C_SR1_BTF BIT(2)
> +#define STM32F4_I2C_SR1_ADDR BIT(1)
> +#define STM32F4_I2C_SR1_SB BIT(0)
> +#define STM32F4_I2C_SR1_ITEVTEN_MASK (STM32F4_I2C_SR1_BTF \
> + | STM32F4_I2C_SR1_ADDR \
> + | STM32F4_I2C_SR1_SB)
> +#define STM32F4_I2C_SR1_ITBUFEN_MASK (STM32F4_I2C_SR1_TXE \
> + | STM32F4_I2C_SR1_RXNE)
> +#define STM32F4_I2C_SR1_ITERREN_MASK (STM32F4_I2C_SR1_AF \
> + | STM32F4_I2C_SR1_ARLO \
> + | STM32F4_I2C_SR1_BERR)
> +
> +/* STM32F4 I2C Status 2 */
> +#define STM32F4_I2C_SR2_BUSY BIT(1)
> +
> +/* STM32F4 I2C Control Clock */
> +#define STM32F4_I2C_CCR_CCR_MASK GENMASK(11, 0)
> +#define STM32F4_I2C_CCR_CCR(n) ((n & STM32F4_I2C_CCR_CCR_MASK))
> +#define STM32F4_I2C_CCR_FS BIT(15)
> +#define STM32F4_I2C_CCR_DUTY BIT(14)
> +
> +/* STM32F4 I2C Trise */
> +#define STM32F4_I2C_TRISE_VALUE_MASK GENMASK(5, 0)
> +#define STM32F4_I2C_TRISE_VALUE(n) ((n & STM32F4_I2C_TRISE_VALUE_MASK))
> +
> +/* STM32F4 I2C Filter */
> +#define STM32F4_I2C_FLTR_DNF_MASK GENMASK(3, 0)
> +#define STM32F4_I2C_FLTR_DNF(n) ((n & STM32F4_I2C_FLTR_DNF_MASK))
> +#define STM32F4_I2C_FLTR_ANOFF BIT(4)
> +
> +#define STM32F4_I2C_MIN_FREQ 2U
> +#define STM32F4_I2C_MAX_FREQ 42U
> +#define FAST_MODE_MAX_RISE_TIME 1000
> +#define STD_MODE_MAX_RISE_TIME 300
Are these supposed to be the values "rise time of both SDA and SCL
signals" from the i2c specification? If so, you got it wrong, fast mode
has the smaller value.
Maybe these constants could get a home in a more central place?
Also I'd add /* ns */ to the definition.
> +#define MHZ_TO_HZ 1000000
> +
> +enum stm32f4_i2c_speed {
> + STM32F4_I2C_SPEED_STANDARD, /* 100 kHz */
> + STM32F4_I2C_SPEED_FAST, /* 400 kHz */
> + STM32F4_I2C_SPEED_END,
> +};
> +
> +/**
> + * struct stm32f4_i2c_timings - per-Mode tuning parameters
> + * @duty: Fast mode duty cycle
> + * @mul_ccr: Value to be multiplied to CCR to reach 100Khz/400Khz SCL frequency
> + * @min_ccr: Minimum clock ctrl reg value to reach 100Khz/400Khz SCL frequency
> + */
> +struct stm32f4_i2c_timings {
> + u32 rate;
rate is undocumented and unused.
> + u32 duty;
> + u32 mul_ccr;
> + u32 min_ccr;
> +};
> +
> +/**
> + * struct stm32f4_i2c_msg - client specific data
> + * @addr: 8-bit slave addr, including r/w bit
> + * @count: number of bytes to be transferred
> + * @buf: data buffer
> + * @result: result of the transfer
> + * @stop: last I2C msg to be sent, i.e. STOP to be generated
> + */
> +struct stm32f4_i2c_msg {
> + u8 addr;
> + u32 count;
> + u8 *buf;
> + int result;
> + bool stop;
> +};
> +
> +/**
> + * struct stm32f4_i2c_dev - private data of the controller
> + * @adap: I2C adapter for this controller
> + * @dev: device for this controller
> + * @base: virtual memory area
> + * @complete: completion of I2C message
> + * @irq_event: interrupt event line for the controller
> + * @irq_error: interrupt error line for the controller
> + * @clk: hw i2c clock
> + * speed: I2C clock frequency of the controller. Standard or Fast only supported
> + * @msg: I2C transfer information
> + */
> +struct stm32f4_i2c_dev {
> + struct i2c_adapter adap;
> + struct device *dev;
> + void __iomem *base;
> + struct completion complete;
> + int irq_event;
> + int irq_error;
You only use irq_event in the probe function. So there is no need to
remember this one and you could use a local variable instead.
> + struct clk *clk;
> + int speed;
> + struct stm32f4_i2c_msg msg;
> +};
> +
> +static struct stm32f4_i2c_timings i2c_timings[] = {
> + [STM32F4_I2C_SPEED_STANDARD] = {
> + .mul_ccr = 1,
> + .min_ccr = 4,
> + .duty = 0,
> + },
> + [STM32F4_I2C_SPEED_FAST] = {
> + .mul_ccr = 16,
> + .min_ccr = 1,
> + .duty = 1,
> + },
Are these values from the datasheet?
> +};
> +
> +static inline void stm32f4_i2c_set_bits(void __iomem *reg, u32 mask)
> +{
> + writel_relaxed(readl_relaxed(reg) | mask, reg);
> +}
> +
> +static inline void stm32f4_i2c_clr_bits(void __iomem *reg, u32 mask)
> +{
> + writel_relaxed(readl_relaxed(reg) & ~mask, reg);
> +}
> +
> +static void stm32f4_i2c_soft_reset(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR1;
> +
> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_SWRST);
> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_SWRST);
Not very critical, but you're doing an unneeded register access here
because the register is read twice.
Also I think readability would improve if you dropped
stm32f4_i2c_{set,clr}_bits and do their logic explicitly in the callers.
stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_SWRST);
stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_SWRST);
vs
val = readl_relaxed(reg);
writel_relaxed(val | STM32F4_I2C_CR1_SWRST, reg);
writel_relaxed(val, reg);
> +}
> +
> +static void stm32f4_i2c_disable_it(struct stm32f4_i2c_dev *i2c_dev)
What is "it"? If it stands for "interrupt" the more usual abbrev is
"irq".
> +{
> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
> +
> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR2_IRQ_MASK);
> +}
> +
> +static void stm32f4_i2c_set_periph_clk_freq(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + u32 clk_rate, cr2, freq;
> +
> + cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
> + cr2 &= ~STM32F4_I2C_CR2_FREQ_MASK;
> + clk_rate = clk_get_rate(i2c_dev->clk);
> + freq = clk_rate / MHZ_TO_HZ;
> + freq = clamp(freq, STM32F4_I2C_MIN_FREQ, STM32F4_I2C_MAX_FREQ);
> + cr2 |= STM32F4_I2C_CR2_FREQ(freq);
> + writel_relaxed(cr2, i2c_dev->base + STM32F4_I2C_CR2);
Can you quote the data sheet enough in a comment here to make it obvious
that your calculation is right?
Would it be more sensible to error out if clk_rate / MHZ_TO_HZ isn't in
the interval [STM32F4_I2C_MIN_FREQ, STM32F4_I2C_MAX_FREQ]?
Usually I would expect that you need to use
DIV_ROUND_UP(clk_rate, MHZ_TO_HZ) instead of a plain division.
> +}
> +
> +static void stm32f4_i2c_set_rise_time(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + u32 trise, freq, cr2, val;
> +
> + cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
> + freq = cr2 & STM32F4_I2C_CR2_FREQ_MASK;
> +
> + trise = readl_relaxed(i2c_dev->base + STM32F4_I2C_TRISE);
> + trise &= ~STM32F4_I2C_TRISE_VALUE_MASK;
Are you required to use rmw for STM32F4_I2C_TRISE? I'd prefer
writel_relaxed(STM32F4_I2C_TRISE_VALUE(..), i2c_dev->base + STM32F4_I2C_TRISE);
unless the datasheet requires rmw.
> + /* Maximum rise time computation */
> + if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD) {
> + trise |= STM32F4_I2C_TRISE_VALUE((freq + 1));
A single pair of parenthesis is enough when you fix
STM32F4_I2C_TRISE_VALUE as suggested above.
> + } else {
> + val = freq * FAST_MODE_MAX_RISE_TIME / STD_MODE_MAX_RISE_TIME;
> + trise |= STM32F4_I2C_TRISE_VALUE((val + 1));
val could be local to this branch.
Or make it shorter using:
freq = cr2 & STM32F4_I2C_CR2_FREQ_MASK;
if (i2c_dev->speed == STM32F4_I2C_SPEED_FAST)
freq = freq * FAST_MODE_MAX_RISE_TIME / STD_MODE_MAX_RISE_TIME;
writel_relaxed(STM32F4_I2C_TRISE_VALUE(freq + 1), ...);
A quote from the data sheet about the algorithm would be good here, too.
> + }
> +
> + writel_relaxed(trise, i2c_dev->base + STM32F4_I2C_TRISE);
> +}
> +
> +static void stm32f4_i2c_set_speed_mode(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + struct stm32f4_i2c_timings *t = &i2c_timings[i2c_dev->speed];
> + u32 ccr, clk_rate;
> + int val;
> +
> + ccr = readl_relaxed(i2c_dev->base + STM32F4_I2C_CCR);
> + ccr &= ~(STM32F4_I2C_CCR_FS | STM32F4_I2C_CCR_DUTY |
> + STM32F4_I2C_CCR_CCR_MASK);
> +
> + clk_rate = clk_get_rate(i2c_dev->clk);
> + val = clk_rate / MHZ_TO_HZ * t->mul_ccr;
Is the rounding done right? Again please describe the hardware in a
comment.
> + if (val < t->min_ccr)
> + val = t->min_ccr;
> + ccr |= STM32F4_I2C_CCR_CCR(val);
> +
> + if (t->duty)
> + ccr |= STM32F4_I2C_CCR_FS | STM32F4_I2C_CCR_DUTY;
> +
> + writel_relaxed(ccr, i2c_dev->base + STM32F4_I2C_CCR);
> +}
> +[...]
> +
> +static int stm32f4_i2c_wait_free_bus(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + u32 status;
> + int ret;
> +
> + ret = readl_relaxed_poll_timeout(i2c_dev->base + STM32F4_I2C_SR2,
> + status,
> + !(status & STM32F4_I2C_SR2_BUSY),
> + 10, 1000);
> + if (ret) {
> + dev_err(i2c_dev->dev, "bus not free\n");
> + ret = -EBUSY;
I'm not sure if "bus not free" deserves an error message. Wolfram?
> + }
> +
> + return ret;
> +}
> +
> +[...]
> +static void stm32f4_i2c_read_msg(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> + u32 rbuf;
> +
> + rbuf = readl_relaxed(i2c_dev->base + STM32F4_I2C_DR);
> + *msg->buf++ = (u8)rbuf & 0xff;
unneeded cast (or unneeded & 0xff).
> + msg->count--;
> +}
> +
> +[...]
> +/**
> + * stm32f4_i2c_handle_read() - Handle FIFO empty interrupt in case of read
> + * @i2c_dev: Controller's private data
> + */
> +static void stm32f4_i2c_handle_read(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
> +
> + switch (msg->count) {
> + case 1:
> + stm32f4_i2c_disable_it(i2c_dev);
> + stm32f4_i2c_read_msg(i2c_dev);
> + complete(&i2c_dev->complete);
> + break;
> + case 2:
> + case 3:
> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR2_ITBUFEN);
> + break;
> + default:
> + stm32f4_i2c_read_msg(i2c_dev);
> + }
It looks wrong that you don't call stm32f4_i2c_read_msg if msg->count is
2 or 3. I guess that's because these cases are handled in
stm32f4_i2c_handle_rx_btf? Maybe you can simplify the logic a bit?
> +}
> +
> +/**
> + * stm32f4_i2c_handle_rx_btf() - Handle byte transfer finished interrupt
> + * in case of read
> + * @i2c_dev: Controller's private data
> + */
> +static void stm32f4_i2c_handle_rx_btf(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> + void __iomem *reg;
> + u32 mask;
> + int i;
> +
> + switch (msg->count) {
I don't understand why the handling depends on the number of messages.
> + case 2:
> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> + /* Generate STOP or REPSTART */
I stumbled about "REPSTART" and would spell it out as "repeated Start".
> + if (msg->stop)
> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
> + else
> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
> +
> + /* Read two last data bytes */
> + for (i = 2; i > 0; i--)
> + stm32f4_i2c_read_msg(i2c_dev);
> +
> + /* Disable EVT and ERR interrupt */
> + reg = i2c_dev->base + STM32F4_I2C_CR2;
> + mask = STM32F4_I2C_CR2_ITEVTEN | STM32F4_I2C_CR2_ITERREN;
> + stm32f4_i2c_clr_bits(reg, mask);
> +
> + complete(&i2c_dev->complete);
> + break;
> + case 3:
> + /* Enable ACK and read data */
> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
> + stm32f4_i2c_read_msg(i2c_dev);
> + break;
> + default:
> + stm32f4_i2c_read_msg(i2c_dev);
> + }
> +}
> +
> +/**
> + * stm32f4_i2c_handle_rx_addr() - Handle address matched interrupt in case of
> + * master receiver
> + * @i2c_dev: Controller's private data
> + */
> +static void stm32f4_i2c_handle_rx_addr(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
> + void __iomem *reg;
> +
> + switch (msg->count) {
> + case 0:
> + stm32f4_i2c_terminate_xfer(i2c_dev);
> + /* Clear ADDR flag */
> + readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
> + break;
> + case 1:
> + /*
> + * Single byte reception:
> + * Enable NACK, clear ADDR flag and generate STOP or RepSTART
> + */
> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
> + if (msg->stop)
> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
> + else
> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
> + break;
> + case 2:
> + /*
> + * 2-byte reception:
> + * Enable NACK and PEC Position Ack and clear ADDR flag
What is PEC?
> + */
> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_POS);
> + readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
> + break;
> +
> + default:
> + /* N-byte reception: Enable ACK and clear ADDR flag */
> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_ACK);
> + readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
> + break;
> + }
> +}
> +
> +/**
> + * stm32f4_i2c_isr_event() - Interrupt routine for I2C bus event
> + * @irq: interrupt number
> + * @data: Controller's private data
> + */
> +static irqreturn_t stm32f4_i2c_isr_event(int irq, void *data)
> +{
> +[...]
> + real_status = readl_relaxed(i2c_dev->base + STM32F4_I2C_SR1);
s/real_status/status/ ?
> +
> + if (!(real_status & possible_status)) {
> + dev_dbg(i2c_dev->dev,
> + "spurious evt it (status=0x%08x, ien=0x%08x)\n",
> + real_status, ien);
s/it/irq/
> + return IRQ_NONE;
> + }
> +
> + /* Use __fls() to check error bits first */
> + flag = __fls(real_status & possible_status);
If you get several events reported you only handle a single one. Is this
effective?
> + switch (1 << flag) {
> + case STM32F4_I2C_SR1_SB:
> + stm32f4_i2c_write_byte(i2c_dev, msg->addr);
> + break;
> +
> + case STM32F4_I2C_SR1_ADDR:
> + if (msg->addr & I2C_M_RD)
> + stm32f4_i2c_handle_rx_addr(i2c_dev);
> + else
> + readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
> +
> + /* Enable ITBUF interrupts */
What is ITBUF?
> + reg = i2c_dev->base + STM32F4_I2C_CR2;
> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR2_ITBUFEN);
> + break;
> +
> + case STM32F4_I2C_SR1_BTF:
> + if (msg->addr & I2C_M_RD)
> + stm32f4_i2c_handle_rx_btf(i2c_dev);
> + else
> + stm32f4_i2c_handle_write(i2c_dev);
> + break;
> +
> + case STM32F4_I2C_SR1_TXE:
> + stm32f4_i2c_handle_write(i2c_dev);
> + break;
> +
> + case STM32F4_I2C_SR1_RXNE:
> + stm32f4_i2c_handle_read(i2c_dev);
> + break;
> +
> + default:
> + dev_err(i2c_dev->dev,
> + "evt it unhandled: status=0x%08x)\n", real_status);
s/it/irq/
> + return IRQ_NONE;
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +[...]
> +static int stm32f4_i2c_xfer_msg(struct stm32f4_i2c_dev *i2c_dev,
> + struct i2c_msg *msg, bool is_first,
> + bool is_last)
> +{
> +[...]
> + /* Enable ITEVT and ITERR interrupts */
This comment isn't helpful. Mentioning their meaning would be great
instead.
> +[...]
> +static int stm32f4_i2c_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg msgs[],
> + int num)
> +{
> + struct stm32f4_i2c_dev *i2c_dev = i2c_get_adapdata(i2c_adap);
> + int ret, i;
> +
> + ret = clk_enable(i2c_dev->clk);
> + if (ret) {
> + dev_err(i2c_dev->dev, "Failed to enable clock\n");
> + return ret;
> + }
> +
> + stm32f4_i2c_hw_config(i2c_dev);
> +
> + for (i = 0; i < num && !ret; i++)
> + ret = stm32f4_i2c_xfer_msg(i2c_dev, &msgs[i], i == 0,
> + i == num - 1);
> +
> + clk_disable(i2c_dev->clk);
> +
> + return (ret < 0) ? ret : i;
using num instead of i would be a bit more obvious.
> +static int stm32f4_i2c_probe(struct platform_device *pdev)
> +{
> +[...]
> + i2c_dev->speed = STM32F4_I2C_SPEED_STANDARD;
> + ret = of_property_read_u32(np, "clock-frequency", &clk_rate);
> + if ((!ret) && (clk_rate == 400000))
> + i2c_dev->speed = STM32F4_I2C_SPEED_FAST;
I'd use
if (!ret && clk_rate >= 400000)
i2c_dev->speed = STM32F4_I2C_SPEED_FAST;
. That's less parenthesis and a more robust selection of the bus
frequency.
> +
> + i2c_dev->dev = &pdev->dev;
> +
> + ret = devm_request_threaded_irq(&pdev->dev, i2c_dev->irq_event,
> + NULL, stm32f4_i2c_isr_event,
> + IRQF_ONESHOT, pdev->name, i2c_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to request irq %i\n",
> + i2c_dev->irq_error);
That's wrong. Requesting irq_event failed.
> + goto clk_free;
> + }
> +
> + ret = devm_request_threaded_irq(&pdev->dev, i2c_dev->irq_error,
> + NULL, stm32f4_i2c_isr_error,
> + IRQF_ONESHOT, pdev->name, i2c_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to request irq %i\n",
> + i2c_dev->irq_error);
> + goto clk_free;
It would also be nice to know for which type of irq this failed. I.e.
please point out if this is the error irq or the event irq in the
message. Ditto for checking the return type of irq_of_parse_and_map.
> + }
> +
> + adap = &i2c_dev->adap;
> + i2c_set_adapdata(adap, i2c_dev);
> + snprintf(adap->name, sizeof(adap->name), "STM32 I2C(%pa)", &res->start);
> + adap->owner = THIS_MODULE;
> + adap->timeout = 2 * HZ;
> + adap->retries = 0;
> + adap->algo = &stm32f4_i2c_algo;
> + adap->dev.parent = &pdev->dev;
> + adap->dev.of_node = pdev->dev.of_node;
> +
> + init_completion(&i2c_dev->complete);
> +
> + ret = i2c_add_adapter(adap);
> + if (ret)
> + goto clk_free;
> +
> + platform_set_drvdata(pdev, i2c_dev);
> +
> + dev_info(i2c_dev->dev, "STM32F4 I2C driver initialized\n");
This is wrong. The driver is bound now to a device, not initialized.
> +static const struct of_device_id stm32f4_i2c_match[] = {
> + { .compatible = "st,stm32f4-i2c", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, stm32f4_i2c_match);
> +
> +static struct platform_driver stm32f4_i2c_driver = {
> + .driver = {
> + .name = "stm32f4-i2c",
> + .of_match_table = stm32f4_i2c_match,
Is this needed?
> + },
> + .probe = stm32f4_i2c_probe,
> + .remove = stm32f4_i2c_remove,
> +};
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 1/2] ARM: nommu: allow enabling REMAP_VECTORS_TO_RAM
From: Vladimir Murzin @ 2016-12-13 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211131158.3120-1-afzal.mohd.ma@gmail.com>
On 11/12/16 13:11, Afzal Mohammed wrote:
> REMAP_VECTORS_TO_RAM depends on DRAM_BASE, but since DRAM_BASE is a
> hex, REMAP_VECTORS_TO_RAM could never get enabled. Also depending on
> DRAM_BASE is redundant as whenever REMAP_VECTORS_TO_RAM makes itself
> available to Kconfig, DRAM_BASE also is available as the Kconfig gets
> sourced on !MMU.
>
> Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
> ---
> arch/arm/Kconfig-nommu | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu
> index aed66d5df7f1..b7576349528c 100644
> --- a/arch/arm/Kconfig-nommu
> +++ b/arch/arm/Kconfig-nommu
> @@ -34,8 +34,7 @@ config PROCESSOR_ID
> used instead of the auto-probing which utilizes the register.
>
> config REMAP_VECTORS_TO_RAM
> - bool 'Install vectors to the beginning of RAM' if DRAM_BASE
> - depends on DRAM_BASE
> + bool 'Install vectors to the beginning of RAM'
> help
> The kernel needs to change the hardware exception vectors.
> In nommu mode, the hardware exception vectors are normally
>
I have similar change in my local tree, so FWIW:
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
^ permalink raw reply
* [PATCH v6 7/8] ARM: dts: stm32: add Timers driver for stm32f429 MCU
From: Benjamin Gaignard @ 2016-12-13 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212185943.ph7njaqb2lxtgdn4@rob-hp-laptop>
2016-12-12 19:59 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Fri, Dec 09, 2016 at 03:15:18PM +0100, Benjamin Gaignard wrote:
>> Add Timers and it sub-nodes into DT for stm32f429 family.
>>
>> version 6:
>> - split patch in two: one for SoC family and one for stm32f469
>> discovery board.
>>
>> version 5:
>> - rename gptimer node to timers
>> - re-order timers node par addresses
>>
>> version 4:
>> - remove unwanted indexing in pwm@ and timer@ node name
>> - use "reg" instead of additional parameters to set timer
>> configuration
>>
>> version 3:
>> - use "st,stm32-timer-trigger" in DT
>>
>> version 2:
>> - use parameters to describe hardware capabilities
>> - do not use references for pwm and iio timer subnodes
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> arch/arm/boot/dts/stm32f429.dtsi | 275 +++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 275 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
>> index bca491d..d0fb9cc 100644
>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> @@ -355,6 +355,21 @@
>> slew-rate = <2>;
>> };
>> };
>> +
>> + pwm1_pins: pwm at 1 {
>
> No reg prop, so should not have a unit-address. Given the names in the
> define below, seems like "timer1" would be appropriate.
>
>> + pins {
>> + pinmux = <STM32F429_PA8_FUNC_TIM1_CH1>,
>> + <STM32F429_PB13_FUNC_TIM1_CH1N>,
>> + <STM32F429_PB12_FUNC_TIM1_BKIN>;
>> + };
>> + };
>> +
>> + pwm3_pins: pwm at 3 {
>> + pins {
>> + pinmux = <STM32F429_PB4_FUNC_TIM3_CH1>,
>> + <STM32F429_PB5_FUNC_TIM3_CH2>;
>> + };
>> + };
>> };
>>
>> rcc: rcc at 40023810 {
>> @@ -426,6 +441,266 @@
>> interrupts = <80>;
>> clocks = <&rcc 0 38>;
>> };
>> +
>> + timers2: timers at 40000000 {
>
> timer at ...
>
> It may be more than just a timer, there's not a better generic name.
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40000000 0x400>;
>> + clocks = <&rcc 0 128>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <1>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers3: timers at 40000400 {
>
> ditto
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40000400 0x400>;
>> + clocks = <&rcc 0 129>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <2>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers4: timers at 40000800 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40000800 0x400>;
>> + clocks = <&rcc 0 130>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <3>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers5: timers at 40000C00 {
>
> timer at ...
>
> And use lowercase hex.
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40000C00 0x400>;
>
> ditto
>
>> + clocks = <&rcc 0 131>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <4>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers6: timers at 40001000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40001000 0x400>;
>> + clocks = <&rcc 0 132>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <5>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers7: timers at 40001400 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40001400 0x400>;
>> + clocks = <&rcc 0 133>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <6>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers12: timers at 40001800 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40001800 0x400>;
>> + clocks = <&rcc 0 134>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <9>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers13: timers at 40001C00 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40001C00 0x400>;
>> + clocks = <&rcc 0 135>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers14: timers at 40002000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40002000 0x400>;
>> + clocks = <&rcc 0 136>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers1: timers at 40010000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40010000 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <0>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers8: timers at 40010400 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40010400 0x400>;
>> + clocks = <&rcc 0 161>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <7>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers9: timers at 40014000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40014000 0x400>;
>> + clocks = <&rcc 0 176>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <8>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers10: timers at 40014400 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40014400 0x400>;
>> + clocks = <&rcc 0 177>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers11: timers at 40014800 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40014800 0x400>;
>> + clocks = <&rcc 0 178>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> + };
>> };
>> };
>>
>> --
>> 1.9.1
>>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2] PCI: Add information about describing PCI in ACPI
From: Jon Masters @ 2016-12-13 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129213955.15663.21173.stgit@bhelgaas-glaptop.roam.corp.google.com>
On 11/29/2016 04:39 PM, Bjorn Helgaas wrote:
> +New architectures should be able to use "Consumer" Extended Address Space
> +descriptors in the PNP0A03 device for bridge registers, including ECAM,
> +although a strict interpretation of [6] might prohibit this. Old x86 and
> +ia64 kernels assume all address space descriptors, including "Consumer"
> +Extended Address Space ones, are windows, so it would not be safe to
> +describe bridge registers this way on those architectures.
<snip>
> +[6] PCI Firmware 3.0, sec 4.1.2:
<snip>
Thanks for the revised writeup, Bjorn. It's great. I'm trying to get the
above clarified explicitly in terms of the spec, and in terms of what
other Operating Systems would like to see as general preference.
To your point about second generation ARM (server) systems: we're actually
on generation 3+ now and finally getting to the point where people are
listening. A great many times over the past few years, people have had
to be sat on until they did what was needed. Fortunately, we are going
to finally have upstream kernels (and distros based upon them) that
boot out of the box on compliant hardware and will be able to point
people at the usual "upstream first" messaging we've been pushing.
I had originally fallen for the SoC koolaid that PCIe was not essential,
and was convinced fairly early that this was nonsense. But it has taken
a few years for everyone else to get onto that bandwagon. First you give
them exactly what they know and love (a 1-2 socket Xeon class machine
with lots of PCIe lanes), then you go and fix the design to give them
what they actually need (which logically enumerates as PCIe but isn't) ;)
Jon.
^ permalink raw reply
* [RFC PATCH 3/3] ARM: dma-mapping: remove traces of NOMMU code
From: Vladimir Murzin @ 2016-12-13 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481619741-35627-1-git-send-email-vladimir.murzin@arm.com>
DMA operations for NOMMU case have been just factored out into
separate compilation unit, so don't keep dead code.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/mm/dma-mapping.c | 26 ++------------------------
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ab77100..d8a755b 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -344,8 +344,6 @@ static void __dma_free_buffer(struct page *page, size_t size)
}
}
-#ifdef CONFIG_MMU
-
static void *__alloc_from_contiguous(struct device *dev, size_t size,
pgprot_t prot, struct page **ret_page,
const void *caller, bool want_vaddr,
@@ -646,22 +644,6 @@ static inline pgprot_t __get_dma_pgprot(unsigned long attrs, pgprot_t prot)
return prot;
}
-#define nommu() 0
-
-#else /* !CONFIG_MMU */
-
-#define nommu() 1
-
-#define __get_dma_pgprot(attrs, prot) __pgprot(0)
-#define __alloc_remap_buffer(dev, size, gfp, prot, ret, c, wv) NULL
-#define __alloc_from_pool(size, ret_page) NULL
-#define __alloc_from_contiguous(dev, size, prot, ret, c, wv, coherent_flag) NULL
-#define __free_from_pool(cpu_addr, size) do { } while (0)
-#define __free_from_contiguous(dev, page, cpu_addr, size, wv) do { } while (0)
-#define __dma_free_remap(cpu_addr, size) do { } while (0)
-
-#endif /* CONFIG_MMU */
-
static void *__alloc_simple_buffer(struct device *dev, size_t size, gfp_t gfp,
struct page **ret_page)
{
@@ -803,7 +785,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
if (cma)
buf->allocator = &cma_allocator;
- else if (nommu() || is_coherent)
+ else if (is_coherent)
buf->allocator = &simple_allocator;
else if (allowblock)
buf->allocator = &remap_allocator;
@@ -852,8 +834,7 @@ static int __arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
- int ret = -ENXIO;
-#ifdef CONFIG_MMU
+ int ret;
unsigned long nr_vma_pages = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
unsigned long pfn = dma_to_pfn(dev, dma_addr);
@@ -868,7 +849,6 @@ static int __arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
vma->vm_end - vma->vm_start,
vma->vm_page_prot);
}
-#endif /* CONFIG_MMU */
return ret;
}
@@ -887,9 +867,7 @@ int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
-#ifdef CONFIG_MMU
vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
-#endif /* CONFIG_MMU */
return __arm_dma_mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
}
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 2/3] ARM: NOMMU: set ARM_DMA_MEM_BUFFERABLE for M-class cpus
From: Vladimir Murzin @ 2016-12-13 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481619741-35627-1-git-send-email-vladimir.murzin@arm.com>
Now, we have dedicated non-cacheable region for consistent DMA
operations. However, that region can still be marked as bufferable by
MPU, so it'd be safer to have barriers by default.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/mm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 6dffbe4..7f0000d 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -1023,7 +1023,7 @@ config ARM_L1_CACHE_SHIFT
config ARM_DMA_MEM_BUFFERABLE
bool "Use non-cacheable memory for DMA" if (CPU_V6 || CPU_V6K) && !CPU_V7
- default y if CPU_V6 || CPU_V6K || CPU_V7
+ default y if CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7M
help
Historically, the kernel has used strongly ordered mappings to
provide DMA coherent memory. With the advent of ARMv7, mapping
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 1/3] ARM: NOMMU: introduce dma operations for noMMU
From: Vladimir Murzin @ 2016-12-13 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481619741-35627-1-git-send-email-vladimir.murzin@arm.com>
R/M classes of cpus can have momory covered by MPU which in turn might
configure RAM as Normal i.e. bufferable and cacheable. It breaks
dma_alloc_coherent() and friends, since data can stuck in caches now
or be buffered.
This patch introduces the way to specify region of memory (via
"memdma=size at start" command line option) suitable for consistent DMA
operations. It is supposed that such region is marked by MPU as
non-cacheable.
For configuration without cache support (like Cortex-M3/M4) dma
operations are forced to be coherent and wired with dma-noop. Such
decision is made based on cacheid global variable. In case cpu
supports caches and no coherent memory region is given - dma is
disallowed.
Reported-by: Alexandre Torgue <alexandre.torgue@st.com>
Reported-by: Andras Szemzo <sza@esh.hu>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/dma-mapping.h | 3 +-
arch/arm/mm/Makefile | 5 +-
arch/arm/mm/dma-mapping-nommu.c | 262 ++++++++++++++++++++++++++++++++++++
arch/arm/mm/mm.h | 3 +
arch/arm/mm/nommu.c | 8 ++
5 files changed, 277 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/mm/dma-mapping-nommu.c
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index bf02dbd..559faad 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -20,7 +20,8 @@ static inline struct dma_map_ops *__generic_dma_ops(struct device *dev)
{
if (dev && dev->archdata.dma_ops)
return dev->archdata.dma_ops;
- return &arm_dma_ops;
+
+ return IS_ENABLED(CONFIG_MMU) ? &arm_dma_ops : &dma_noop_ops;
}
static inline struct dma_map_ops *get_dma_ops(struct device *dev)
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 2ac7988..5796357 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -2,9 +2,8 @@
# Makefile for the linux arm-specific parts of the memory manager.
#
-obj-y := dma-mapping.o extable.o fault.o init.o \
- iomap.o
-
+obj-y := extable.o fault.o init.o iomap.o
+obj-y += dma-mapping$(MMUEXT).o
obj-$(CONFIG_MMU) += fault-armv.o flush.o idmap.o ioremap.o \
mmap.o pgd.o mmu.o pageattr.o
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
new file mode 100644
index 0000000..b24228e
--- /dev/null
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -0,0 +1,262 @@
+/*
+ * Based on linux/arch/arm/mm/dma-mapping.c
+ *
+ * Copyright (C) 2000-2004 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * DMA uncached mapping support.
+ */
+
+#include <linux/export.h>
+#include <linux/mm.h>
+#include <linux/dma-mapping.h>
+#include <linux/scatterlist.h>
+#include <linux/genalloc.h>
+
+#include <asm/cachetype.h>
+#include <asm/cacheflush.h>
+#include <asm/outercache.h>
+
+#include "dma.h"
+
+unsigned long dma_start __initdata;
+unsigned long dma_size __initdata;
+
+static struct gen_pool *dma_pool;
+
+static void *arm_nommu_dma_alloc(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp,
+ unsigned long attrs)
+{
+ void *ptr;
+
+ if (!dma_pool)
+ return NULL;
+
+ ptr = (void *)gen_pool_alloc(dma_pool, size);
+ if (ptr) {
+ *dma_handle = __pa(ptr);
+ dmac_flush_range(ptr, ptr + size);
+ outer_flush_range(__pa(ptr), __pa(ptr) + size);
+ }
+
+ return ptr;
+}
+
+static void arm_nommu_dma_free(struct device *dev, size_t size,
+ void *cpu_addr, dma_addr_t dma_addr,
+ unsigned long attrs)
+{
+ gen_pool_free(dma_pool, (unsigned long)cpu_addr, size);
+}
+
+static void __dma_page_cpu_to_dev(dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
+{
+ dmac_unmap_area(__va(handle), size, dir);
+
+ if (dir == DMA_FROM_DEVICE)
+ outer_inv_range(handle, handle + size);
+ else
+ outer_clean_range(handle, handle + size);
+}
+
+static void __dma_page_dev_to_cpu(dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
+{
+ if (dir != DMA_TO_DEVICE) {
+ outer_inv_range(handle, handle + size);
+ dmac_unmap_area(__va(handle), size, dir);
+ }
+}
+
+static dma_addr_t arm_nommu_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ dma_addr_t handle = page_to_phys(page) + offset;
+
+ __dma_page_cpu_to_dev(handle, size, dir);
+
+ return handle;
+}
+
+static void arm_nommu_dma_unmap_page(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ __dma_page_dev_to_cpu(handle, size, dir);
+}
+
+
+static int arm_nommu_dma_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ int i;
+ struct scatterlist *sg;
+
+ for_each_sg(sgl, sg, nents, i) {
+ sg_dma_address(sg) = sg_phys(sg);
+ sg_dma_len(sg) = sg->length;
+ __dma_page_cpu_to_dev(sg_dma_address(sg), sg_dma_len(sg), dir);
+ }
+
+ return nents;
+}
+
+static void arm_nommu_dma_unmap_sg(struct device *dev, struct scatterlist *sgl, int nents,
+ enum dma_data_direction dir, unsigned long attrs)
+{
+ struct scatterlist *sg;
+ int i;
+
+ for_each_sg(sgl, sg, nents, i)
+ __dma_page_dev_to_cpu(sg_dma_address(sg), sg_dma_len(sg), dir);
+}
+
+static void arm_nommu_dma_sync_single_for_device(struct device *dev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+ __dma_page_cpu_to_dev(handle, size, dir);
+}
+
+static void arm_nommu_dma_sync_single_for_cpu(struct device *dev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+ __dma_page_cpu_to_dev(handle, size, dir);
+}
+
+static void arm_nommu_dma_sync_sg_for_device(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir)
+{
+ struct scatterlist *sg;
+ int i;
+
+ for_each_sg(sgl, sg, nents, i)
+ __dma_page_cpu_to_dev(sg_dma_address(sg), sg_dma_len(sg), dir);
+}
+
+static void arm_nommu_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir)
+{
+ struct scatterlist *sg;
+ int i;
+
+ for_each_sg(sgl, sg, nents, i)
+ __dma_page_dev_to_cpu(sg_dma_address(sg), sg_dma_len(sg), dir);
+}
+
+struct dma_map_ops arm_nommu_dma_ops = {
+ .alloc = arm_nommu_dma_alloc,
+ .free = arm_nommu_dma_free,
+ .map_page = arm_nommu_dma_map_page,
+ .unmap_page = arm_nommu_dma_unmap_page,
+ .map_sg = arm_nommu_dma_map_sg,
+ .unmap_sg = arm_nommu_dma_unmap_sg,
+ .sync_single_for_device = arm_nommu_dma_sync_single_for_device,
+ .sync_single_for_cpu = arm_nommu_dma_sync_single_for_cpu,
+ .sync_sg_for_device = arm_nommu_dma_sync_sg_for_device,
+ .sync_sg_for_cpu = arm_nommu_dma_sync_sg_for_cpu,
+};
+EXPORT_SYMBOL(arm_nommu_dma_ops);
+
+static struct dma_map_ops *arm_nommu_get_dma_map_ops(bool coherent)
+{
+ return coherent ? &dma_noop_ops : &arm_nommu_dma_ops;
+}
+
+void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
+ const struct iommu_ops *iommu, bool coherent)
+{
+ struct dma_map_ops *dma_ops;
+
+ /*
+ * Cahe support for v7m is optional, so can be treated as
+ * coherent if no cache has been detected.
+ */
+ dev->archdata.dma_coherent = (cacheid) ? coherent : true;
+
+ dma_ops = arm_nommu_get_dma_map_ops(dev->archdata.dma_coherent);
+
+ set_dma_ops(dev, dma_ops);
+}
+
+void arch_teardown_dma_ops(struct device *dev)
+{
+}
+
+int dma_supported(struct device *dev, u64 mask)
+{
+ if (cacheid && !dma_pool)
+ return 0;
+
+ return 1;
+}
+
+EXPORT_SYMBOL(dma_supported);
+
+#define PREALLOC_DMA_DEBUG_ENTRIES 4096
+
+static int __init dma_debug_do_init(void)
+{
+ dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
+ return 0;
+}
+core_initcall(dma_debug_do_init);
+
+/*
+ * Initialise the coherent pool for DMA allocations.
+ */
+static int __init dma_pool_init(void)
+{
+ int ret;
+
+ if (cacheid && !dma_size) {
+ pr_warn("DMA: coherent memory region has not been given.\n");
+ return 0;
+ }
+
+ dma_pool = gen_pool_create(PAGE_SHIFT, -1);
+
+ if (!dma_pool)
+ goto out;
+
+ ret = gen_pool_add_virt(dma_pool, (unsigned long)dma_start, (unsigned long)dma_start,
+ dma_size, -1);
+ if (ret)
+ goto destroy_genpool;
+
+ gen_pool_set_algo(dma_pool, gen_pool_first_fit_order_align, NULL);
+
+ pr_info("DMA: coherent memory region 0x%lx - 0x%lx (%lu KiB)\n",
+ dma_start, dma_start + dma_size, dma_size >> 10);
+
+ return 0;
+
+destroy_genpool:
+ gen_pool_destroy(dma_pool);
+ dma_pool = NULL;
+out:
+ pr_err("DMA: failed to allocate coherent memory region\n");
+ return -ENOMEM;
+}
+
+postcore_initcall(dma_pool_init);
+
+/* "memdma=<size>@<address>" parsing. */
+static int __init early_memdma(char *p)
+{
+ if (!p)
+ return -EINVAL;
+
+ dma_size = memparse(p, &p);
+ if (*p == '@')
+ dma_start = memparse(p + 1, &p);
+
+ return 0;
+}
+early_param("memdma", early_memdma);
diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
index ce727d4..18eb869 100644
--- a/arch/arm/mm/mm.h
+++ b/arch/arm/mm/mm.h
@@ -97,3 +97,6 @@ struct static_vm {
void dma_contiguous_remap(void);
unsigned long __clear_cr(unsigned long mask);
+
+extern unsigned long dma_start __initdata;
+extern unsigned long dma_size __initdata;
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 681cec8..15487bb 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -294,15 +294,23 @@ void __init arm_mm_memblock_reserve(void)
* reserved here.
*/
#endif
+
}
void __init sanity_check_meminfo(void)
{
phys_addr_t end;
+
sanity_check_meminfo_mpu();
end = memblock_end_of_DRAM();
high_memory = __va(end - 1) + 1;
memblock_set_current_limit(end);
+
+ if (dma_size &&
+ memblock_overlaps_region(&memblock.memory, dma_start, dma_size)) {
+ pr_crit("DMA: coherent memory region overlaps with main memory.\n");
+ dma_size = 0;
+ }
}
/*
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 0/3] Fix dma_alloc_coherent() and friends for NOMMU
From: Vladimir Murzin @ 2016-12-13 9:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
It seem that addition of cache support for M-class cpus uncovered
latent bug in DMA usage. NOMMU memory model has been treated as being
always consistent; however, for R/M classes of cpu memory can be
covered by MPU which in turn might configure RAM as Normal
i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
friends, since data can stuck in caches now or be buffered.
This patch set is trying to address the issue by providing region of
memory suitable for consistent DMA operations. It is supposed that such
region is marked by MPU as non-cacheable. Since we have MPU support in
Linux for R-class only and M-class setting MPU in bootloader, proposed
interface to advertise such memory is via "memdma=size at start" command
line option, to avoid clashing with normal memory (which usually comes
from dts) it'd be safer to use it together with "mem=" command line
option. Meanwhile, I'm open to suggestions for the better way telling
Linux of such memory.
For configuration without cache support (like Cortex-M3/M4) dma
operations are forced to be coherent and wired with dma-noop. Such
decision is made based on cacheid global variable. In case cpu
supports caches and no coherent memory region is given - dma is
disallowed. Probably, some other important checks are missing, so I'll
all my ears :)
To make life easier NOMMU dma operations are kept in separate
compilation unit.
Thanks!
Vladimir Murzin (3):
ARM: NOMMU: introduce dma operations for noMMU
ARM: NOMMU: set ARM_DMA_MEM_BUFFERABLE for M-class cpus
ARM: dma-mapping: remove traces of NOMMU code
arch/arm/include/asm/dma-mapping.h | 3 +-
arch/arm/mm/Kconfig | 2 +-
arch/arm/mm/Makefile | 5 +-
arch/arm/mm/dma-mapping-nommu.c | 262 ++++++++++++++++++++++++++++++++++++
arch/arm/mm/dma-mapping.c | 26 +---
arch/arm/mm/mm.h | 3 +
arch/arm/mm/nommu.c | 8 ++
7 files changed, 280 insertions(+), 29 deletions(-)
create mode 100644 arch/arm/mm/dma-mapping-nommu.c
--
1.7.9.5
^ 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