Re: [PATCH 1/2] dt-bindings: Document the STM32 MDMA bindings

2017-03-29 Thread M'boumba Cedric Madianga
Hi Rob,

> stm32 is not a specific SoC. Compatible strings should be specific to
> an SoC (with fallback strings to whatever they are compatible with) so
> you can handle SoC specific differences or errata.

Ok I see. I will add a more specific SoC description in my compatible.
Thanks.


> I still don't understand. Is the difference in DMA addresses vs. CPU
> addresses? If so, you should dma-ranges to translate these.

Not really.
In fact, the MDMA controller provides a master AXI interface for
memories like DDR/SRAM and peripheral registers access (system access
port).
It also provides a master AHB interface only for Cortex-M7 TCM memory
access (TCM access port).
So the goal of this st,ahb-addr-masks property is to list all TCM
addresses avalaible in the SoC, in order to correctly configure the
MDMA as an AHB master in that particular case.
For all other cases (other memories or peripheral registers access),
the MDMA will act as AXI master.

Hope it helps to understand.

BR,
Cedric


Re: [PATCH 1/2] dt-bindings: Document the STM32 MDMA bindings

2017-03-27 Thread M'boumba Cedric Madianga
Hi Rob,

2017-03-20 22:52 GMT+01:00 Rob Herring :
> On Mon, Mar 13, 2017 at 04:06:38PM +0100, M'boumba Cedric Madianga wrote:
>> This patch adds documentation of device tree bindings for the STM32 MDMA
>> controller.
>>
>> Signed-off-by: M'boumba Cedric Madianga 
>> Reviewed-by: Ludovic BARRE 
>> ---
>>  .../devicetree/bindings/dma/stm32-mdma.txt | 94 
>> ++
>>  1 file changed, 94 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/dma/stm32-mdma.txt
>>
>> diff --git a/Documentation/devicetree/bindings/dma/stm32-mdma.txt 
>> b/Documentation/devicetree/bindings/dma/stm32-mdma.txt
>> new file mode 100644
>> index 000..26a930c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/stm32-mdma.txt
>> @@ -0,0 +1,94 @@
>> +* STMicroelectronics STM32 MDMA controller
>> +
>> +The STM32 MDMA is a general-purpose direct memory access controller capable 
>> of
>> +supporting 64 independent DMA channels with 256 HW requests.
>> +
>> +Required properties:
>> +- compatible: Should be "st,stm32-mdma"
>
> Should be more specific.

The compatible string is not specific enough ? I don't see how to specific more.

>
>> +- reg: Should contain MDMA registers location and length. This should 
>> include
>> +  all of the per-channel registers.
>> +- interrupts: Should contain the MDMA interrupt.
>> +- clocks: Should contain the input clock of the DMA instance.
>> +- resets: Reference to a reset controller asserting the DMA controller.
>> +- #dma-cells : Must be <5>. See DMA client paragraph for more details.
>> +
>> +Optional properties:
>> +- dma-channels: Number of DMA channels supported by the controller.
>> +- dma-requests: Number of DMA request signals supported by the controller.
>> +- st,ahb-addr-masks: Array of u32 mask to list memory devices addressed via
>> +  AHB bus.
>
> I don't understand what this is.

The MDMA is able to address memories and devices from AHB bus or AXI bus.
The MDMA has a little different way of working to address AHB
device/memory and AXI device/memory.
In STM32H7 platform, almost all devices are addressed by AXI bus.
But we have some memories adress by AHB bus.
So, we add these parameter to be able to handle this.

>
>> +
>> +Example:
>
> Put the 2 examples together.

OK

>
>> +
>> + mdma1: dma@5200 {
>> + compatible = "st,stm32-mdma";
>> + reg = <0x5200 0x1000>;
>> + interrupts = <122>;
>> + clocks = <&clk_dummy>;
>> + resets = <&rcc 992>;
>> + #dma-cells = <5>;
>> + dma-channels = <16>;
>> + dma-requests = <32>;
>> + st,ahb-addr-masks = <0x2000>, <0x>;
>> + };
>> +
>> +* DMA client
>> +
>> +DMA clients connected to the STM32 MDMA controller must use the format
>> +described in the dma.txt file, using a six-cell specifier for each channel:
>> +a phandle to the MDMA controller plus the following five integer cells:
>> +
>> +1. The request line number
>> +2. The priority level
>> + 0x00: Low
>> + 0x01: Medium
>> + 0x10: High
>> + 0x11: Very high
>> +3. A 32bit mask specifying the DMA channel configuration
>> + -bit 0-1: Source increment mode
>> + 0x00: Source address pointer is fixed
>> + 0x10: Source address pointer is incremented after each data transfer
>> + 0x11: Source address pointer is decremented after each data transfer
>> + -bit 2-3: Destination increment mode
>> + 0x00: Destination address pointer is fixed
>> + 0x10: Destination address pointer is incremented after each data
>> + transfer
>> + 0x11: Destination address pointer is decremented after each data
>> + transfer
>> + -bit 8-9: Source increment offset size
>> + 0x00: byte (8bit)
>> + 0x01: half-word (16bit)
>> + 0x10: word (32bit)
>> + 0x11: double-word (64bit)
>> + -bit 10-11: Destination increment offset size
>> + 0x00: byte (8bit)
>> + 0x01: half-word (16bit)
>> + 0x10: word (32bit)
>> + 0x11: double-word (64bit)
>> +-bit 25-18: The number of bytes to be transferred in a single transfer
>> + (min = 1 byte, max = 128 bytes)
>> +-bit 29:28: Trigger Mode
>> + 0x00: Each MDMA request triggers a buffer transfer (max 128 bytes)
>> + 0x01: Each MDMA request triggers 

Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver

2017-03-23 Thread M'boumba Cedric Madianga
Hi Wolfram,

Yes the STM32F7 has a new I2C IP core compared to STM32F4.
The engine, the machine state are very different.
I tried few months ago to write a common driver but it was very very
difficilcut as the 2 IP are not so much things in common.

BR,
Cedric

2017-03-23 21:17 GMT+01:00 Wolfram Sang :
> On Fri, Mar 17, 2017 at 10:58:56AM +0100, M'boumba Cedric Madianga wrote:
>> This patch adds initial support for the STM32F7 I2C controller.
>>
>> Signed-off-by: M'boumba Cedric Madianga 
>
> So, the STM32F7 has a new I2C IP core compared to STM32F4?
>


Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver

2017-03-17 Thread M'boumba Cedric Madianga
Hi Neil,

>> As, I2C rise/fall time have some impacts in I2C timings value, the
>> question is: it is very relevant to let customer control these
>> parameters ?
>
> Actually, you could specify a different rise time in DT if it's relevant for
> a specific design, this is why you have the following DT attributes :
> - i2c-scl-falling-time-ns
> - i2c-scl-internal-delay-ns
> - i2c-scl-rising-time-ns
> - i2c-sda-falling-time-ns
>
>> If the answer is NO, I agree with you, it is better to use your
>> formula and remove this property from DT.
>> If the answer is YES, I think we should keep ST tool.
>
> Note that the ST tool calculations are tied to the clock source frequency, so 
> either
> you provide a table for all the possible clock source frequencies or 
> calculate dynamically.
> Having a single parameter for a single frequency is, from my point of view, 
> not acceptable.
>
> And, I don't think it's a military secret to have (at least) a simplified 
> algorithm from ST...
> since you have very detailed explanations in the public manuals !

OK. I will do some trials with your algorithm and push it in the V2.
Thanks

>
> OK, but I think the I2C and DT maintainers are also involved in these kind of 
> decisions.
> They should also give their advice.

I already upstream an I2C driver with this approach: "i2c-stm32f4".
I don't think that Wolfram or Rob will change the philosophy for this driver.
Then, I also don't think that the machine code for F0/F1/L0/L4 will be
pushed in the mainline as it will be completely useless to port a
linux kernel for this kind of chip.

BR,
Cedric


Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver

2017-03-17 Thread M'boumba Cedric Madianga
> Sorry I don't understand.
> The value you use from the DT and the one calculated from the 
> setup/hold/high/low value
> with the algorithm I developed will set the same values.

With the ST tool, I could set the following values:
I2C speed mode (Master, Fast Mode, Fast Mode Plus)
I2C speed frequency
I2C clock source frequency
I2C rise time
I2C fall time

The values set in the DT in this patchset is 0x40202537 for the
following input values:
I2C speed mode  = Master mode
I2C speed frequency= 100 kHz
I2C clock source frequency = 48 MHz
I2C rise time = 25 ns
I2C fall time = 10 ns

If I keep all the above values and just change I2C rise time with 100
ns, I will have TIMINGR value at 0x10805E89

>
> The main difference is that you won't need the ST tool to calculate these, 
> and even better
> you can provide generic binding for whatever APB frequency the I2C peripheral 
> is running
> on.

As, I2C rise/fall time have some impacts in I2C timings value, the
question is: it is very relevant to let customer control these
parameters ?
If the answer is NO, I agree with you, it is better to use your
formula and remove this property from DT.
If the answer is YES, I think we should keep ST tool.

> Having the STM32L4 running mainline won't be hard, maybe useless, but not 
> hard.
> My point is that you can somehow consider the STM32F0/F1/F4 I2C IP to be "v1" 
> or "gen1",
> and the L0/L4/F6 (and H7 ?) to be "v2" or "gen2" then prepend a generic 
> compatible to
> have something like :
> compatible = "st,stm32-i2c-v2", "st,stm32f7-i2c"

This is not the strategy chosen by the company.
They decided to push all driver with ip_name-stm32.c if the driver is
common for all Soc.
If it not the case, the suffix to be used is the name of the first
supported SoC that introduced the IP in the mainline kernel.

BR,
Cedric


Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver

2017-03-17 Thread M'boumba Cedric Madianga
Hi,


>> +static int stm32f7_i2c_hw_config(struct stm32f7_i2c_dev *i2c_dev)
>> +{
>> + struct device_node *of_node = i2c_dev->dev->of_node;
>> + u32 timing;
>> + int ret;
>> +
>> + ret = of_property_read_u32(of_node, "st,i2c-timing", &timing);
>> + if (ret) {
>> + dev_err(i2c_dev->dev, "Error: missing i2c timing property\n");
>> + return ret;
>> + }
>> +
>> + /* Timing settings */
>> + writel_relaxed(timing, i2c_dev->base + STM32F7_I2C_TIMINGR);
>
> Hi,
>
> Using a register value in DT is quite ugly since the requirement to calculate 
> the timings
> is quite easy, and well documented.
>
> I wrote it for Zephyr, you can find it here :
> https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/i2c/i2c_stm32lx.c#L31

Thanks for this code. It is very interesting.
With our formula, I just notice that we don't use any i2c rise time or
fall time but they have some impacts in i2c timing computation.
So, the user could not be able to select these values for him use case. Right ?


>
> Another point, maybe you should find a better name for the driver, since this 
> I2C IP is share
> with the STM32Lx also and is not tied to STM32F7.

As far as I know, we don't have any STM32Lx SoC integrated in the
linux kernel mainline.
I choose i2c-stm32f7 name as it is the first Soc integrated in the
linux kernel mainline where this IP could be used.

BR,
Cedric


[PATCH 0/5] Add support for the STM32F7 I2C

2017-03-17 Thread M'boumba Cedric Madianga
This patchset adds support for the I2C controller embedded in STM32F7xx SoC.
It enables I2C transfer in interrupt mode with Standard-mode, Fast-mode and
Fast-mode+ bus speed.

M'boumba Cedric Madianga (5):
  dt-bindings: i2c-stm32: Document the STM32F7 I2C bindings
  i2c: i2c-stm32f4: use generic definition of speed enum
  i2c: i2c-stm32f7: add driver
  ARM: dts: stm32: Add I2C1 support for STM32F746 SoC
  ARM: dts: stm32: Add I2C1 support for STM32F746 eval board

 .../devicetree/bindings/i2c/i2c-stm32.txt  |  22 +-
 arch/arm/boot/dts/stm32746g-eval.dts   |   6 +
 arch/arm/boot/dts/stm32f746.dtsi   |  23 +
 drivers/i2c/busses/Kconfig |  10 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-stm32.h |  20 +
 drivers/i2c/busses/i2c-stm32f4.c   |  18 +-
 drivers/i2c/busses/i2c-stm32f7.c   | 562 +
 8 files changed, 648 insertions(+), 14 deletions(-)
 create mode 100644 drivers/i2c/busses/i2c-stm32.h
 create mode 100644 drivers/i2c/busses/i2c-stm32f7.c

-- 
1.9.1



[PATCH 3/5] i2c: i2c-stm32f7: add driver

2017-03-17 Thread M'boumba Cedric Madianga
This patch adds initial support for the STM32F7 I2C controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/i2c/busses/Kconfig   |  10 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-stm32f7.c | 562 +++
 3 files changed, 573 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-stm32f7.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 8adc0f1..ab0caec 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -897,6 +897,16 @@ config I2C_STM32F4
  This driver can also be built as module. If so, the module
  will be called i2c-stm32f4.
 
+config I2C_STM32F7
+   tristate "STMicroelectronics STM32F7 I2C support"
+   depends on ARCH_STM32 || COMPILE_TEST
+   help
+ Enable this option to add support for STM32 I2C controller embedded
+ in STM32F7 SoCs.
+
+ This driver can also be built as module. If so, the module
+ will be called i2c-stm32f7.
+
 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 30b6085..5449ece 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -86,6 +86,7 @@ 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_STM32F7)  += i2c-stm32f7.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-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
new file mode 100644
index 000..844a98b
--- /dev/null
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -0,0 +1,562 @@
+/*
+ * Driver for STMicroelectronics STM32F7 I2C controller
+ *
+ * This I2C controller is described in the STM32F75xxx and STM32F74xxx Soc
+ * reference manual.
+ * Please see below a link to the documentation:
+ * http://www.st.com/resource/en/reference_manual/dm00124865.pdf
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2017
+ * Author: M'boumba Cedric Madianga 
+ *
+ * This driver is based on i2c-stm32f4.c
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "i2c-stm32.h"
+
+/* STM32F7 I2C registers */
+#define STM32F7_I2C_CR10x00
+#define STM32F7_I2C_CR20x04
+#define STM32F7_I2C_TIMINGR0x10
+#define STM32F7_I2C_ISR0x18
+#define STM32F7_I2C_ICR0x1C
+#define STM32F7_I2C_RXDR   0x24
+#define STM32F7_I2C_TXDR   0x28
+
+/* STM32F7 I2C control 1 */
+#define STM32F7_I2C_CR1_ERRIE  BIT(7)
+#define STM32F7_I2C_CR1_TCIE   BIT(6)
+#define STM32F7_I2C_CR1_STOPIE BIT(5)
+#define STM32F7_I2C_CR1_NACKIE BIT(4)
+#define STM32F7_I2C_CR1_ADDRIE BIT(3)
+#define STM32F7_I2C_CR1_RXIE   BIT(2)
+#define STM32F7_I2C_CR1_TXIE   BIT(1)
+#define STM32F7_I2C_CR1_PE BIT(0)
+#define STM32F7_I2C_ALL_IRQ_MASK   (STM32F7_I2C_CR1_ERRIE \
+   | STM32F7_I2C_CR1_TCIE \
+   | STM32F7_I2C_CR1_STOPIE \
+   | STM32F7_I2C_CR1_NACKIE \
+   | STM32F7_I2C_CR1_RXIE \
+   | STM32F7_I2C_CR1_TXIE)
+
+/* STM32F7 I2C control 2 */
+#define STM32F7_I2C_CR2_RELOAD BIT(24)
+#define STM32F7_I2C_CR2_NBYTES_MASKGENMASK(23, 16)
+#define STM32F7_I2C_CR2_NBYTES(n)  (((n) & 0xff) << 16)
+#define STM32F7_I2C_CR2_NACK   BIT(15)
+#define STM32F7_I2C_CR2_STOP   BIT(14)
+#define STM32F7_I2C_CR2_START  BIT(13)
+#define STM32F7_I2C_CR2_RD_WRN BIT(10)
+#define STM32F7_I2C_CR2_SADD7_MASK GENMASK(7, 1)
+#define STM32F7_I2C_CR2_SADD7(n)   (((n) & 0x7f) << 1)
+
+/* STM32F7 I2C Interrupt Status */
+#define STM32F7_I2C_ISR_BUSY   BIT(15)
+#define STM32F7_I2C_ISR_ARLO   BIT(9)
+#define STM32F7_I2C_ISR_BERR   BIT(8)
+#define STM32F7_I2C_ISR_TCRBIT(7)
+#define STM32F7_I2C_ISR_TC BIT(6)
+#define STM32F7_I2C_ISR_STOPF  BIT(5)
+#define STM32F7_I2C_ISR_NACKF  BIT(4)
+#define STM32F7_I2

[PATCH 1/5] dt-bindings: i2c-stm32: Document the STM32F7 I2C bindings

2017-03-17 Thread M'boumba Cedric Madianga
This patch adds the documentation of device tree bindings for STM32F7 I2C

Signed-off-by: M'boumba Cedric Madianga 
---
 .../devicetree/bindings/i2c/i2c-stm32.txt  | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt 
b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
index 78eaf7b..8288724 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
@@ -1,7 +1,9 @@
 * I2C controller embedded in STMicroelectronics STM32 I2C platform
 
 Required properties :
-- compatible : Must be "st,stm32f4-i2c"
+- compatible : Must be one of the following
+  - "st,stm32f4-i2c"
+  - "st,stm32f7-i2c"
 - reg : Offset and length of the register set for the device
 - interrupts : Must contain the interrupt id for I2C event and then the
   interrupt id for I2C error.
@@ -14,8 +16,22 @@ Required properties :
 
 Optional properties :
 - clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
-  the default 100 kHz frequency will be used. As only Normal and Fast modes
-  are supported, possible values are 10 and 40.
+  the default 100 kHz frequency will be used.
+  For STM32F4 SoC Standard-mode and Fast-mode are supported, possible values 
are
+  10 and 40.
+  For STM32F7 SoC, Standard-mode, Fast-mode and Fast-mode Plus are supported,
+  possible values are 10, 40 and 100.
+- st,i2c-timing : A 32-bit I2C timing refister value.
+  This value is only required for "st,stm32f7-i2c".
+  A specific external tool delivered by ST is used to compute the value to be
+  set here according to i2C speed frequency, i2c clock source frequency,
+  i2c rise time and i2c fall time inputs.
+  - bit 31:28: PRESC[3:0]: Timing prescaler
+  - bit 27:24: Reserved
+  - bit 23:20: SCLDEL[3:0]: Data setup time
+  - bit 19:16: SDADEL[3:0]: Data hold time
+  - bit 15:8:  SCLH[7:0]: SCL high period
+  - bit 7:0:   SCLL[7:0]: SCL low period
 
 Example :
 
-- 
1.9.1



[PATCH 4/5] ARM: dts: stm32: Add I2C1 support for STM32F746 SoC

2017-03-17 Thread M'boumba Cedric Madianga
This patch adds I2C1 support for STM32F746 SoC.

Signed-off-by: M'boumba Cedric Madianga 
---
 arch/arm/boot/dts/stm32f746.dtsi | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index f321ffe..89d3897 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -287,6 +287,29 @@
bias-disable;
};
};
+
+   i2c1_pins_b: i2c1@0 {
+   pins {
+   pinmux = ,
+;
+   bias-disable;
+   drive-open-drain;
+   slew-rate = <3>;
+   };
+   };
+   };
+
+   i2c1: i2c@40005400 {
+   compatible = "st,stm32f7-i2c";
+   reg = <0x40005400 0x400>;
+   interrupts = <31>,
+<32>;
+   resets = <&rcc 149>;
+   clocks = <&rcc 0 405>;
+   st,i2c-timing = <0x40202537>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
};
 
rcc: rcc@40023800 {
-- 
1.9.1



[PATCH 2/5] i2c: i2c-stm32f4: use generic definition of speed enum

2017-03-17 Thread M'boumba Cedric Madianga
This patch uses a more generic definition of speed enum for i2c-stm32f4
driver.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
---
 drivers/i2c/busses/i2c-stm32.h   | 20 
 drivers/i2c/busses/i2c-stm32f4.c | 18 +++---
 2 files changed, 27 insertions(+), 11 deletions(-)
 create mode 100644 drivers/i2c/busses/i2c-stm32.h

diff --git a/drivers/i2c/busses/i2c-stm32.h b/drivers/i2c/busses/i2c-stm32.h
new file mode 100644
index 000..dab5176
--- /dev/null
+++ b/drivers/i2c/busses/i2c-stm32.h
@@ -0,0 +1,20 @@
+/*
+ * i2c-stm32.h
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2017
+ * Author: M'boumba Cedric Madianga 
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#ifndef _I2C_STM32_H
+#define _I2C_STM32_H
+
+enum stm32_i2c_speed {
+   STM32_I2C_SPEED_STANDARD, /* 100 kHz */
+   STM32_I2C_SPEED_FAST, /* 400 kHz */
+   STM32_I2C_SPEED_FAST_PLUS, /* 1 MHz */
+   STM32_I2C_SPEED_END,
+};
+
+#endif /* _I2C_STM32_H */
diff --git a/drivers/i2c/busses/i2c-stm32f4.c b/drivers/i2c/busses/i2c-stm32f4.c
index f9dd7e8..b81557d 100644
--- a/drivers/i2c/busses/i2c-stm32f4.c
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 
+#include "i2c-stm32.h"
+
 /* STM32F4 I2C offset registers */
 #define STM32F4_I2C_CR10x00
 #define STM32F4_I2C_CR20x04
@@ -90,12 +92,6 @@
 #define STM32F4_I2C_MAX_FREQ   46U
 #define HZ_TO_MHZ  100
 
-enum stm32f4_i2c_speed {
-   STM32F4_I2C_SPEED_STANDARD, /* 100 kHz */
-   STM32F4_I2C_SPEED_FAST, /* 400 kHz */
-   STM32F4_I2C_SPEED_END,
-};
-
 /**
  * struct stm32f4_i2c_msg - client specific data
  * @addr: 8-bit slave addr, including r/w bit
@@ -159,7 +155,7 @@ static int stm32f4_i2c_set_periph_clk_freq(struct 
stm32f4_i2c_dev *i2c_dev)
i2c_dev->parent_rate = clk_get_rate(i2c_dev->clk);
freq = DIV_ROUND_UP(i2c_dev->parent_rate, HZ_TO_MHZ);
 
-   if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD) {
+   if (i2c_dev->speed == STM32_I2C_SPEED_STANDARD) {
/*
 * To reach 100 kHz, the parent clk frequency should be between
 * a minimum value of 2 MHz and a maximum value of 46 MHz due
@@ -216,7 +212,7 @@ static void stm32f4_i2c_set_rise_time(struct 
stm32f4_i2c_dev *i2c_dev)
 * is not higher than 46 MHz . As a result trise is at most 4 bits wide
 * and so fits into the TRISE bits [5:0].
 */
-   if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD)
+   if (i2c_dev->speed == STM32_I2C_SPEED_STANDARD)
trise = freq + 1;
else
trise = freq * 3 / 10 + 1;
@@ -230,7 +226,7 @@ static void stm32f4_i2c_set_speed_mode(struct 
stm32f4_i2c_dev *i2c_dev)
u32 val;
u32 ccr = 0;
 
-   if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD) {
+   if (i2c_dev->speed == STM32_I2C_SPEED_STANDARD) {
/*
 * In standard mode:
 * t_scl_high = t_scl_low = CCR * I2C parent clk period
@@ -808,10 +804,10 @@ static int stm32f4_i2c_probe(struct platform_device *pdev)
udelay(2);
reset_control_deassert(rst);
 
-   i2c_dev->speed = STM32F4_I2C_SPEED_STANDARD;
+   i2c_dev->speed = STM32_I2C_SPEED_STANDARD;
ret = of_property_read_u32(np, "clock-frequency", &clk_rate);
if (!ret && clk_rate >= 40)
-   i2c_dev->speed = STM32F4_I2C_SPEED_FAST;
+   i2c_dev->speed = STM32_I2C_SPEED_FAST;
 
i2c_dev->dev = &pdev->dev;
 
-- 
1.9.1



[PATCH 5/5] ARM: dts: stm32: Add I2C1 support for STM32F746 eval board

2017-03-17 Thread M'boumba Cedric Madianga
This patch adds I2C1 support for STM32F746 eval board

Signed-off-by: M'boumba Cedric Madianga 
---
 arch/arm/boot/dts/stm32746g-eval.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/stm32746g-eval.dts 
b/arch/arm/boot/dts/stm32746g-eval.dts
index aa03fac..19cb82d 100644
--- a/arch/arm/boot/dts/stm32746g-eval.dts
+++ b/arch/arm/boot/dts/stm32746g-eval.dts
@@ -94,3 +94,9 @@
pinctrl-names = "default";
status = "okay";
 };
+
+&i2c1 {
+   pinctrl-0 = <&i2c1_pins_b>;
+   pinctrl-names = "default";
+   status = "okay";
+};
-- 
1.9.1



[PATCH 2/2] dmaengine: Add STM32 MDMA driver

2017-03-13 Thread M'boumba Cedric Madianga
This patch adds the driver for the STM32 MDMA controller.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
---
 drivers/dma/Kconfig  |   12 +
 drivers/dma/Makefile |1 +
 drivers/dma/stm32-mdma.c | 1570 ++
 3 files changed, 1583 insertions(+)
 create mode 100644 drivers/dma/stm32-mdma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6ab80c9..beae8b0 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -470,6 +470,18 @@ config STM32_DMAMUX
  If you have a board based on such a MCU and wish to use DMAMUX say Y
  here.
 
+config STM32_MDMA
+   bool "STMicroelectronics STM32 master dma support"
+   depends on ARCH_STM32  || COMPILE_TEST
+   select DMA_ENGINE
+   select DMA_OF
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Enable support for the on-chip MDMA controller on STMicroelectronics
+ STM32 platforms.
+ If you have a board based on STM32 SoC and wish to use the master DMA
+ say Y here.
+
 config S3C24XX_DMAC
bool "Samsung S3C24XX DMA support"
depends on ARCH_S3C24XX || COMPILE_TEST
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 449c7a3..003b515 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
 obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
 obj-$(CONFIG_STM32_DMA) += stm32-dma.o
 obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o
+obj-$(CONFIG_STM32_MDMA) += stm32-mdma.o
 obj-$(CONFIG_S3C24XX_DMAC) += s3c24xx-dma.o
 obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
 obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
diff --git a/drivers/dma/stm32-mdma.c b/drivers/dma/stm32-mdma.c
new file mode 100644
index 000..23d267c
--- /dev/null
+++ b/drivers/dma/stm32-mdma.c
@@ -0,0 +1,1570 @@
+/*
+ * Driver for STM32 MDMA controller
+ *
+ * Inspired by stm32-dma.c and dma-jz4780.c
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2017
+ * Author: M'boumba Cedric Madianga 
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "virt-dma.h"
+
+#define STM32_MDMA_GISR0   0x /* MDMA Int Status Reg 1 */
+#define STM32_MDMA_GISR1   0x0004 /* MDMA Int Status Reg 2 */
+
+/* MDMA Channel x interrupt/status register */
+#define STM32_MDMA_CISR(x) (0x40 + 0x40 * (x)) /* x = 0..62 */
+#define STM32_MDMA_CISR_CRQA   BIT(16)
+#define STM32_MDMA_CISR_TCIF   BIT(4)
+#define STM32_MDMA_CISR_BTIF   BIT(3)
+#define STM32_MDMA_CISR_BRTIF  BIT(2)
+#define STM32_MDMA_CISR_CTCIF  BIT(1)
+#define STM32_MDMA_CISR_TEIF   BIT(0)
+
+/* MDMA Channel x interrupt flag clear register */
+#define STM32_MDMA_CIFCR(x)(0x44 + 0x40 * (x))
+#define STM32_MDMA_CIFCR_CLTCIFBIT(4)
+#define STM32_MDMA_CIFCR_CBTIF BIT(3)
+#define STM32_MDMA_CIFCR_CBRTIFBIT(2)
+#define STM32_MDMA_CIFCR_CCTCIFBIT(1)
+#define STM32_MDMA_CIFCR_CTEIF BIT(0)
+#define STM32_MDMA_CIFCR_CLEAR_ALL (STM32_MDMA_CIFCR_CLTCIF \
+   | STM32_MDMA_CIFCR_CBTIF \
+   | STM32_MDMA_CIFCR_CBRTIF \
+   | STM32_MDMA_CIFCR_CCTCIF \
+   | STM32_MDMA_CIFCR_CTEIF)
+
+/* MDMA Channel x error status register */
+#define STM32_MDMA_CESR(x) (0x48 + 0x40 * (x))
+#define STM32_MDMA_CESR_BSEBIT(11)
+#define STM32_MDMA_CESR_ASRBIT(10)
+#define STM32_MDMA_CESR_TEMD   BIT(9)
+#define STM32_MDMA_CESR_TELD   BIT(8)
+#define STM32_MDMA_CESR_TEDBIT(7)
+#define STM32_MDMA_CESR_TEA_MASK   GENMASK(6, 0)
+
+/* MDMA Channel x control register */
+#define STM32_MDMA_CCR(x)  (0x4C + 0x40 * (x))
+#define STM32_MDMA_CCR_SWRQBIT(16)
+#define STM32_MDMA_CCR_WEX BIT(14)
+#define STM32_MDMA_CCR_HEX BIT(13)
+#define STM32_MDMA_CCR_BEX BIT(12)
+#define STM32_MDMA_CCR_PL_MASK GENMASK(7, 6)
+#define STM32_MDMA_CCR_PL(n)   (((n) & 0x3) << 6)
+#define STM32_MDMA_CCR_TCIEBIT(5)
+#define STM32_MDMA_CCR_BTIEBIT(4)
+#define STM32_MDMA_CCR_BRTIE   BIT(3)
+#define STM32_MDMA_CCR_CTCIE   BIT(2)
+#define STM32_MDMA_CCR_TEIEBIT(1)
+#define STM32_MDMA_CCR_EN  BIT(0)
+#define STM32_MDMA_CCR_IRQ_MASK(STM32_MDMA_CCR_TCIE \
+   | STM32_MDMA_CCR_BTIE \
+   | STM32_MDMA_CCR_BRTIE \
+  

[PATCH 1/2] dt-bindings: Document the STM32 MDMA bindings

2017-03-13 Thread M'boumba Cedric Madianga
This patch adds documentation of device tree bindings for the STM32 MDMA
controller.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
---
 .../devicetree/bindings/dma/stm32-mdma.txt | 94 ++
 1 file changed, 94 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/stm32-mdma.txt

diff --git a/Documentation/devicetree/bindings/dma/stm32-mdma.txt 
b/Documentation/devicetree/bindings/dma/stm32-mdma.txt
new file mode 100644
index 000..26a930c
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/stm32-mdma.txt
@@ -0,0 +1,94 @@
+* STMicroelectronics STM32 MDMA controller
+
+The STM32 MDMA is a general-purpose direct memory access controller capable of
+supporting 64 independent DMA channels with 256 HW requests.
+
+Required properties:
+- compatible: Should be "st,stm32-mdma"
+- reg: Should contain MDMA registers location and length. This should include
+  all of the per-channel registers.
+- interrupts: Should contain the MDMA interrupt.
+- clocks: Should contain the input clock of the DMA instance.
+- resets: Reference to a reset controller asserting the DMA controller.
+- #dma-cells : Must be <5>. See DMA client paragraph for more details.
+
+Optional properties:
+- dma-channels: Number of DMA channels supported by the controller.
+- dma-requests: Number of DMA request signals supported by the controller.
+- st,ahb-addr-masks: Array of u32 mask to list memory devices addressed via
+  AHB bus.
+
+Example:
+
+   mdma1: dma@5200 {
+   compatible = "st,stm32-mdma";
+   reg = <0x5200 0x1000>;
+   interrupts = <122>;
+   clocks = <&clk_dummy>;
+   resets = <&rcc 992>;
+   #dma-cells = <5>;
+   dma-channels = <16>;
+   dma-requests = <32>;
+   st,ahb-addr-masks = <0x2000>, <0x>;
+   };
+
+* DMA client
+
+DMA clients connected to the STM32 MDMA controller must use the format
+described in the dma.txt file, using a six-cell specifier for each channel:
+a phandle to the MDMA controller plus the following five integer cells:
+
+1. The request line number
+2. The priority level
+   0x00: Low
+   0x01: Medium
+   0x10: High
+   0x11: Very high
+3. A 32bit mask specifying the DMA channel configuration
+ -bit 0-1: Source increment mode
+   0x00: Source address pointer is fixed
+   0x10: Source address pointer is incremented after each data transfer
+   0x11: Source address pointer is decremented after each data transfer
+ -bit 2-3: Destination increment mode
+   0x00: Destination address pointer is fixed
+   0x10: Destination address pointer is incremented after each data
+   transfer
+   0x11: Destination address pointer is decremented after each data
+   transfer
+ -bit 8-9: Source increment offset size
+   0x00: byte (8bit)
+   0x01: half-word (16bit)
+   0x10: word (32bit)
+   0x11: double-word (64bit)
+ -bit 10-11: Destination increment offset size
+   0x00: byte (8bit)
+   0x01: half-word (16bit)
+   0x10: word (32bit)
+   0x11: double-word (64bit)
+-bit 25-18: The number of bytes to be transferred in a single transfer
+   (min = 1 byte, max = 128 bytes)
+-bit 29:28: Trigger Mode
+   0x00: Each MDMA request triggers a buffer transfer (max 128 bytes)
+   0x01: Each MDMA request triggers a block transfer (max 64K bytes)
+   0x10: Each MDMA request triggers a repeated block transfer
+   0x11: Each MDMA request triggers a linked list transfer
+4. A 32bit value specifying the register to be used to acknowledge the request
+   if no HW ack signal is used by the MDMA client
+5. A 32bit mask specifying the value to be written to acknowledge the request
+   if no HW ack signal is used by the MDMA client
+
+Example:
+
+   i2c4: i2c@5c002000 {
+   compatible = "st,stm32f7-i2c";
+   reg = <0x5c002000 0x400>;
+   interrupts = ,
+;
+   clocks = <&clk_hsi>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   dmas = <&mdma1 36 0x0 0x40008 0x0 0x0>,
+  <&mdma1 37 0x0 0x40002 0x0 0x0>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
-- 
1.9.1



[PATCH 0/2] Add STM32 MDMA driver

2017-03-13 Thread M'boumba Cedric Madianga
This patchset adds support for the STM32 MDMA controller.
The Master Direct memory access (MDMA) provides high-speed data transfer
between memory and memory or between peripherals and memory.
Contrary to STM32 DMA, the STM32 MDMA controller supports hardware LLI and
uses a larger integrated FIFO (128 vs 16 bytes)

M'boumba Cedric Madianga (2):
  dt-bindings: Document the STM32 MDMA bindings
  dmaengine: Add STM32 MDMA driver

 .../devicetree/bindings/dma/stm32-mdma.txt |   94 ++
 drivers/dma/Kconfig|   12 +
 drivers/dma/Makefile   |1 +
 drivers/dma/stm32-mdma.c   | 1570 
 4 files changed, 1677 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/stm32-mdma.txt
 create mode 100644 drivers/dma/stm32-mdma.c

-- 
1.9.1



[PATCH 3/5] dt-bindings: stm32-dma: Add property to handle STM32 DMAMUX

2017-03-13 Thread M'boumba Cedric Madianga
This patch adds an optional property needed for STM32 DMA controller
addressed via STM32 DMAMUX.

Signed-off-by: M'boumba Cedric Madianga 
---
 Documentation/devicetree/bindings/dma/stm32-dma.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/stm32-dma.txt 
b/Documentation/devicetree/bindings/dma/stm32-dma.txt
index 4408af6..7b5e91a 100644
--- a/Documentation/devicetree/bindings/dma/stm32-dma.txt
+++ b/Documentation/devicetree/bindings/dma/stm32-dma.txt
@@ -16,6 +16,9 @@ Optional properties:
 - resets: Reference to a reset controller asserting the DMA controller
 - st,mem2mem: boolean; if defined, it indicates that the controller supports
   memory-to-memory transfer
+- st,dmamux: boolean; if defined, it indicates that the controller is behind a
+  DMA multiplexer. In that case, using dma instances doesn't work for DMA
+  clients. They have to use dma-router instances.
 
 Example:
 
-- 
1.9.1



[PATCH 4/5] dmaengine: stm32-dma: Add support for STM32 DMAMUX

2017-03-13 Thread M'boumba Cedric Madianga
This patch adds support for STM32 DMAMUX.
When the STM32 DMA controller is behind a STM32 DMAMUX the request line
number has not to be handled by DMA but DMAMUX.

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/dma/stm32-dma.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 786fc8f..3bf2893 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -179,6 +179,7 @@ struct stm32_dma_device {
struct clk *clk;
struct reset_control *rst;
bool mem2mem;
+   bool dmamux;
struct stm32_dma_chan chan[STM32_DMA_MAX_CHANNELS];
 };
 
@@ -968,10 +969,14 @@ static void stm32_dma_desc_free(struct virt_dma_desc 
*vdesc)
 static void stm32_dma_set_config(struct stm32_dma_chan *chan,
  struct stm32_dma_cfg *cfg)
 {
+   struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
+
stm32_dma_clear_reg(&chan->chan_reg);
 
chan->chan_reg.dma_scr = cfg->stream_config & STM32_DMA_SCR_CFG_MASK;
-   chan->chan_reg.dma_scr |= STM32_DMA_SCR_REQ(cfg->request_line);
+
+   if (!dmadev->dmamux)
+   chan->chan_reg.dma_scr |= STM32_DMA_SCR_REQ(cfg->request_line);
 
/* Enable Interrupts  */
chan->chan_reg.dma_scr |= STM32_DMA_SCR_TEIE | STM32_DMA_SCR_TCIE;
@@ -998,8 +1003,8 @@ static struct dma_chan *stm32_dma_of_xlate(struct 
of_phandle_args *dma_spec,
cfg.stream_config = dma_spec->args[2];
cfg.threshold = dma_spec->args[3];
 
-   if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) ||
-   (cfg.request_line >= STM32_DMA_MAX_REQUEST_ID)) {
+   if ((!dmadev->dmamux && cfg.request_line >= STM32_DMA_MAX_REQUEST_ID) ||
+   (cfg.channel_id >= STM32_DMA_MAX_CHANNELS)) {
dev_err(dev, "Bad channel and/or request id\n");
return NULL;
}
@@ -1058,6 +1063,8 @@ static int stm32_dma_probe(struct platform_device *pdev)
dmadev->mem2mem = of_property_read_bool(pdev->dev.of_node,
"st,mem2mem");
 
+   dmadev->dmamux = of_property_read_bool(pdev->dev.of_node, "st,dmamux");
+
dmadev->rst = devm_reset_control_get(&pdev->dev, NULL);
if (!IS_ERR(dmadev->rst)) {
reset_control_assert(dmadev->rst);
-- 
1.9.1



[PATCH 1/5] dt-bindings: Document the STM32 DMAMUX bindings

2017-03-13 Thread M'boumba Cedric Madianga
This patch adds the documentation of device tree bindings for the STM32
DMAMUX.

Signed-off-by: M'boumba Cedric Madianga 
---
 .../devicetree/bindings/dma/stm32-dmamux.txt   | 57 ++
 1 file changed, 57 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/stm32-dmamux.txt

diff --git a/Documentation/devicetree/bindings/dma/stm32-dmamux.txt 
b/Documentation/devicetree/bindings/dma/stm32-dmamux.txt
new file mode 100644
index 000..1039420
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/stm32-dmamux.txt
@@ -0,0 +1,57 @@
+STM32 DMA MUX (DMA request router)
+
+Required properties:
+- compatible:  "st,stm32-dmamux"
+- reg: Memory map for accessing module
+- #dma-cells:  Should be set to <4>.
+   For more details about the four cells, please see stm32-dma.txt
+   documentation binding file
+- dma-masters: Phandle pointing to the DMA controller
+- clocks: Input clock of the DMAMUX instance.
+
+Optional properties:
+- dma-channels : Number of DMA channels supported.
+- dma-requests : Number of DMA requests supported.
+- resets: Reference to a reset controller asserting the DMA controller
+
+Example:
+
+/* DMA controller */
+dma2: dma-controller@40026400 {
+   compatible = "st,stm32-dma";
+   reg = <0x40026400 0x400>;
+   interrupts = <56>,
+<57>,
+<58>,
+<59>,
+<60>,
+<68>,
+<69>,
+<70>;
+   clocks = <&clk_hclk>;
+   #dma-cells = <4>;
+   st,mem2mem;
+   resets = <&rcc 150>;
+   st,dmamux;
+   dma-channels = <8>;
+};
+
+/* DMA mux */
+dmamux2: dma-router@40020820 {
+   compatible = "st,stm32-dmamux";
+   reg = <0x40020800 0x1c>;
+   #dma-cells = <4>;
+   dma-requests = <128>;
+   dma-masters = <&dma2>;
+};
+
+/* DMA client */
+usart1: serial@40011000 {
+   compatible = "st,stm32-usart", "st,stm32-uart";
+   reg = <0x40011000 0x400>;
+   interrupts = <37>;
+   clocks = <&clk_pclk2>;
+   dmas = <&dmamux2 0 41 0x400 0x00>,
+  <&dmamux2 1 42 0x400 0x00>;
+   dma-names = "rx", "tx";
+};
-- 
1.9.1



[PATCH 5/5] ARM: configs: stm32: Add DMAMUX support in STM32 defconfig

2017-03-13 Thread M'boumba Cedric Madianga
This patch adds DMAMUX support in STM32 defconfig file

Signed-off-by: M'boumba Cedric Madianga 
---
 arch/arm/configs/stm32_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index a9d8e3c..afb6832 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -60,6 +60,7 @@ CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_STM32=y
 CONFIG_DMADEVICES=y
 CONFIG_STM32_DMA=y
+CONFIG_STM32_DMAMUX=y
 CONFIG_IIO=y
 CONFIG_STM32_ADC_CORE=y
 CONFIG_STM32_ADC=y
-- 
1.9.1



[PATCH 0/5] Add STM32 DMAMUX support

2017-03-13 Thread M'boumba Cedric Madianga
This patchset adds support for the STM32 DMA multiplexer.
It allows to map any peripheral DMA request to any channel of the product
DMAs.
This IP has been introduced with STM32H7 SoC.

M'boumba Cedric Madianga (5):
  dt-bindings: Document the STM32 DMAMUX bindings
  dmaengine: Add STM32 DMAMUX driver
  dt-bindings: stm32-dma: Add property to handle STM32 DMAMUX
  dmaengine: stm32-dma: Add support for STM32 DMAMUX
  ARM: configs: stm32: Add DMAMUX support in STM32 defconfig

 .../devicetree/bindings/dma/stm32-dma.txt  |   3 +
 .../devicetree/bindings/dma/stm32-dmamux.txt   |  57 +
 arch/arm/configs/stm32_defconfig   |   1 +
 drivers/dma/Kconfig|   9 +
 drivers/dma/Makefile   |   1 +
 drivers/dma/stm32-dma.c|  13 +-
 drivers/dma/stm32-dmamux.c | 231 +
 7 files changed, 312 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/stm32-dmamux.txt
 create mode 100644 drivers/dma/stm32-dmamux.c

-- 
1.9.1



[PATCH 2/5] dmaengine: Add STM32 DMAMUX driver

2017-03-13 Thread M'boumba Cedric Madianga
This patch implements the STM32 DMAMUX driver

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/dma/Kconfig|   9 ++
 drivers/dma/Makefile   |   1 +
 drivers/dma/stm32-dmamux.c | 231 +
 3 files changed, 241 insertions(+)
 create mode 100644 drivers/dma/stm32-dmamux.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index fc3435c..6ab80c9 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -461,6 +461,15 @@ config STM32_DMA
  If you have a board based on such a MCU and wish to use DMA say Y
  here.
 
+config STM32_DMAMUX
+   bool "STMicroelectronics STM32 dma multiplexer support"
+   depends on STM32_DMA
+   help
+ Enable support for the on-chip DMA multiplexer on STMicroelectronics
+ STM32 MCUs.
+ If you have a board based on such a MCU and wish to use DMAMUX say Y
+ here.
+
 config S3C24XX_DMAC
bool "Samsung S3C24XX DMA support"
depends on ARCH_S3C24XX || COMPILE_TEST
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 0b723e9..449c7a3 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_RENESAS_DMA) += sh/
 obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
 obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
 obj-$(CONFIG_STM32_DMA) += stm32-dma.o
+obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o
 obj-$(CONFIG_S3C24XX_DMAC) += s3c24xx-dma.o
 obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
 obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
diff --git a/drivers/dma/stm32-dmamux.c b/drivers/dma/stm32-dmamux.c
new file mode 100644
index 000..3003546
--- /dev/null
+++ b/drivers/dma/stm32-dmamux.c
@@ -0,0 +1,231 @@
+/*
+ * DMA Router driver for STM32 DMA MUX
+ *
+ * Copyright (C) 2015 M'Boumba Cedric Madianga 
+ *
+ * Based on LPC18xx/43xx DMA MUX and TI DMA XBAR
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define STM32_DMAMUX_CCR(x)(0x4 * (x))
+#define STM32_DMAMUX_MAX_CHANNELS  32
+#define STM32_DMAMUX_MAX_REQUESTS  255
+
+struct stm32_dmamux {
+   u32 chan_id;
+   u32 request;
+   bool busy;
+};
+
+struct stm32_dmamux_data {
+   struct dma_router dmarouter;
+   struct stm32_dmamux *muxes;
+   struct clk *clk;
+   void __iomem *iomem;
+   u32 dmamux_requests; /* number of DMA requests connected to DMAMUX */
+   u32 dmamux_channels; /* Number of DMA channels supported */
+};
+
+static inline u32 stm32_dmamux_read(void __iomem *iomem, u32 reg)
+{
+   return readl_relaxed(iomem + reg);
+}
+
+static inline void stm32_dmamux_write(void __iomem *iomem, u32 reg, u32 val)
+{
+   writel_relaxed(val, iomem + reg);
+}
+
+static void stm32_dmamux_free(struct device *dev, void *route_data)
+{
+   struct stm32_dmamux_data *dmamux = dev_get_drvdata(dev);
+   struct stm32_dmamux *mux = route_data;
+
+   /* Clear dma request for the right channel */
+   stm32_dmamux_write(dmamux->iomem, STM32_DMAMUX_CCR(mux->chan_id), 0);
+   clk_disable(dmamux->clk);
+   mux->busy = false;
+
+   dev_dbg(dev, "Unmapping dma-router%dchan%d (was routed to request%d)\n",
+   dev->id, mux->chan_id, mux->request);
+}
+
+static void *stm32_dmamux_route_allocate(struct of_phandle_args *dma_spec,
+struct of_dma *ofdma)
+{
+   struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
+   struct stm32_dmamux_data *dmamux = platform_get_drvdata(pdev);
+   struct stm32_dmamux *mux;
+   u32 chan_id;
+   int ret;
+
+   if (dma_spec->args_count != 4) {
+   dev_err(&pdev->dev, "invalid number of dma mux args\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   if (dma_spec->args[0] >= dmamux->dmamux_channels) {
+   dev_err(&pdev->dev, "invalid channel id: %d\n",
+   dma_spec->args[0]);
+   return ERR_PTR(-EINVAL);
+   }
+
+   if (dma_spec->args[1] > dmamux->dmamux_requests) {
+   dev_err(&pdev->dev, "invalid mux request number: %d\n",
+   dma_spec->args[1]);
+   return ERR_PTR(-EINVAL);
+   }
+
+   /* The of_node_put() will be done in of_dma_router_xlate function */
+   dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", 0);
+   if (!dma_spec->np) {
+   dev_err(&pdev->dev, "can't get dma master\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   chan_id = dma_spec->args[0];
+   mux = &dmam

Re: [PATCH v10 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC

2017-01-25 Thread M'boumba Cedric Madianga
2017-01-25 21:25 GMT+01:00 Wolfram Sang :
> On Thu, Jan 19, 2017 at 02:25:14PM +0100, M'boumba Cedric Madianga wrote:
>> This patch adds I2C1 support for STM32F429 SoC
>>
>> Signed-off-by: Patrice Chotard 
>> Signed-off-by: M'boumba Cedric Madianga 
>
> Note that patches 3-5 should go via stm-tree or arm-soc. Rather not i2c.

Ok fine.
These patches will be applied in STM32 git tree.

Thanks


[PATCH v10 0/5] Add support for the STM32F4 I2C

2017-01-19 Thread M'boumba Cedric Madianga
not supported in stm32_dma_get_width()
- add FIFO configuration management inside the driver except for threshold
- add interrupt configuration management inside the driver
- rework stm32_dma_chan_irq() to handle error interrupt in one way
- rework stm32_dma_set_xfer_param() to be easier to read
- update stm32_dma_tx_status() to always return status from dma_cookie_status()
- disable clk if we don't manage to stop the DMA channel during channel
  resources allocation
- set driver as built-in as DMA will be required by other built-in driver

Changes since v1:
- use compatible st,stm32f4-i2c instead of st,i2c-stm32f4 (Rob)
- fix typo s/enmpty/empty (Maxime)
- use one function to handle TX fifo empty and byte xfer finished IT (Maxime)
- set duty cycle in timing struct in Fast mode
- Rework clock management (call prepare/unprepare at probe and remove, call
  clk_enable/clk_disable for each I2C transfer)

M'boumba Cedric Madianga (5):
  dt-bindings: Document the STM32 I2C bindings
  i2c: Add STM32F4 I2C driver
  ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
  ARM: dts: stm32: Add I2C1 support for STM32429 eval board
  ARM: configs: stm32: Add I2C support for STM32 defconfig

 .../devicetree/bindings/i2c/i2c-stm32.txt  |  33 +
 arch/arm/boot/dts/stm32429i-eval.dts   |   6 +
 arch/arm/boot/dts/stm32f429.dtsi   |  23 +
 arch/arm/configs/stm32_defconfig   |   3 +
 drivers/i2c/busses/Kconfig |  10 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-stm32f4.c   | 897 +
 7 files changed, 973 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
 create mode 100644 drivers/i2c/busses/i2c-stm32f4.c

-- 
1.9.1



[PATCH v10 5/5] ARM: configs: stm32: Add I2C support for STM32 defconfig

2017-01-19 Thread M'boumba Cedric Madianga
This patch adds I2C support for STM32 default configuration

Signed-off-by: M'boumba Cedric Madianga 
---
 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 5a72d69..323d2a3 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -47,6 +47,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
-- 
1.9.1



[PATCH v10 1/5] dt-bindings: Document the STM32 I2C bindings

2017-01-19 Thread M'boumba Cedric Madianga
This patch adds documentation of device tree bindings for the STM32 I2C
controller.

Signed-off-by: M'boumba Cedric Madianga 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/i2c/i2c-stm32.txt  | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt 
b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
new file mode 100644
index 000..78eaf7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
@@ -0,0 +1,33 @@
+* I2C controller embedded in STMicroelectronics STM32 I2C platform
+
+Required properties :
+- compatible : Must be "st,stm32f4-i2c"
+- reg : Offset and length of the register set for the device
+- interrupts : Must contain the interrupt id for I2C event and then the
+  interrupt id for I2C error.
+- resets: Must contain the phandle to the reset controller.
+- clocks: Must contain the input clock of the I2C instance.
+- A pinctrl state named "default" must be defined to set pins in mode of
+  operation for I2C transfer
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+  the default 100 kHz frequency will be used. As only Normal and Fast modes
+  are supported, possible values are 10 and 40.
+
+Example :
+
+   i2c@40005400 {
+   compatible = "st,stm32f4-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x40005400 0x400>;
+   interrupts = <31>,
+<32>;
+   resets = <&rcc 277>;
+   clocks = <&rcc 0 149>;
+   pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
+   pinctrl-names = "default";
+   };
-- 
1.9.1



[PATCH v10 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC

2017-01-19 Thread M'boumba Cedric Madianga
This patch adds I2C1 support for STM32F429 SoC

Signed-off-by: Patrice Chotard 
Signed-off-by: M'boumba Cedric Madianga 
---
 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 e4dae0e..5b063e9 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 
+#include 
 
 / {
clocks {
@@ -153,6 +154,18 @@
status = "disabled";
};
 
+   i2c1: i2c@40005400 {
+   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";
+   };
+
usart7: serial@40007800 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40007800 0x400>;
@@ -355,6 +368,16 @@
slew-rate = <2>;
};
};
+
+   i2c1_pins_b: i2c1@0 {
+   pins {
+   pinmux = ,
+;
+   bias-disable;
+   drive-open-drain;
+   slew-rate = <3>;
+   };
+   };
};
 
rcc: rcc@40023810 {
-- 
1.9.1



[PATCH v10 4/5] ARM: dts: stm32: Add I2C1 support for STM32429 eval board

2017-01-19 Thread M'boumba Cedric Madianga
This patch adds I2C1 instance support for STM32x9I-Eval board.

Signed-off-by: M'boumba Cedric Madianga 
---
 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 76f7206..c943539 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -146,3 +146,9 @@
pinctrl-names = "default";
status = "okay";
 };
+
+&i2c1 {
+   pinctrl-0 = <&i2c1_pins_b>;
+   pinctrl-names = "default";
+   status = "okay";
+};
-- 
1.9.1



[PATCH v10 2/5] i2c: Add STM32F4 I2C driver

2017-01-19 Thread M'boumba Cedric Madianga
This patch adds support for the STM32F4 I2C controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/i2c/busses/Kconfig   |  10 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-stm32f4.c | 897 +++
 3 files changed, 908 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 000..f9dd7e8
--- /dev/null
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -0,0 +1,897 @@
+/*
+ * Driver for STMicroelectronics STM32 I2C controller
+ *
+ * This I2C controller is described in the STM32F429/439 Soc reference manual.
+ * Please see below a link to the documentation:
+ * http://www.st.com/resource/en/reference_manual/DM00031020.pdf
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2016
+ * Author: M'boumba Cedric Madianga 
+ *
+ * This driver is based on i2c-st.c
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* STM32F4 I2C offset registers */
+#define STM32F4_I2C_CR10x00
+#define STM32F4_I2C_CR20x04
+#define STM32F4_I2C_DR 0x10
+#define STM32F4_I2C_SR10x14
+#define STM32F4_I2C_SR20x18
+#define STM32F4_I2C_CCR0x1C
+#define STM32F4_I2C_TRISE  0x20
+#define STM32F4_I2C_FLTR   0x24
+
+/* STM32F4 I2C control 1*/
+#define STM32F4_I2C_CR1_POSBIT(11)
+#define STM32F4_I2C_CR1_ACKBIT(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)
+#define STM32F4_I2C_CR2_ITBUFENBIT(10)
+#define STM32F4_I2C_CR2_ITEVTENBIT(9)
+#define STM32F4_I2C_CR2_ITERRENBIT(8)
+#define STM32F4_I2C_CR2_IRQ_MASK   (STM32F4_I2C_CR2_ITBUFEN | \
+STM32F4_I2C_CR2_ITEVTEN | \
+STM32F4_I2C_CR2_ITERREN)
+
+/* 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_TXEBIT(7)
+#define STM32F4_I2C_SR1_RXNE   BIT(6)
+#define STM32F4_I2C_SR1_BTFBIT(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)
+#d

Re: [PATCH v9 2/5] i2c: Add STM32F4 I2C driver

2017-01-19 Thread M'boumba Cedric Madianga
ok fine

2017-01-19 9:02 GMT+01:00 Uwe Kleine-König :
> Hello Cedric,
>
> On Wed, Jan 18, 2017 at 09:55:39PM +0100, M'boumba Cedric Madianga wrote:
>> 2017-01-18 19:42 GMT+01:00 Uwe Kleine-König :
>> > Hello Cedric,
>> >
>> > On Wed, Jan 18, 2017 at 04:21:17PM +0100, M'boumba Cedric Madianga wrote:
>> >> >> +  * In standard mode, the maximum allowed SCL rise time is 1000 
>> >> >> ns.
>> >> >> +  * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is 
>> >> >> equal to
>> >> >> +  * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
>> >> >> +  * programmed with 09h.(1000 ns / 125 ns = 8 + 1)
>> >> >
>> >> > * programmed with 0x9.
>> >> > (1000 ns / 125 ns = 8)
>> >> >
>> >> >> +  * So, for I2C standard mode TRISE = FREQ[5:0] + 1
>> >> >> +  *
>> >> >> +  * In fast mode, the maximum allowed SCL rise time is 300 ns.
>> >> >> +  * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is 
>> >> >> equal to
>> >> >> +  * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
>> >> >> +  * programmed with 03h.(300 ns / 125 ns = 2 + 1)
>> >> >
>> >> > as above s/03h/0x3/;
>> >>
>> >> ok
>> >>
>> >> > s/.(/. (/;
>> >> ok
>> >>
>> >> > s/+ 1//;
>> >> This formula is use to understand how we find the result 0x3
>> >> So, 0x3 => 300 ns / 125ns = 2 + 1
>> >
>> > Yeah, I understood that, but writing 300 ns / 125ns = 2 + 1 is
>> > irritating at best.
>>
>> Ok. I will write 0x3 (300 ns / 125 ns + 1) and 0x9 (1000 ns / 125 ns + 1)
>>
>> >> > [...]
>> >> > If DUTY = 1: (to reach 400 kHz)
>> >> >
>> >> > Strange.
>> >> >
>> >> >> + val = DIV_ROUND_UP(i2c_dev->parent_rate, 40 * 3);
>> >> >
>> >> > the manual reads:
>> >> >
>> >> > The minimum allowed value is 0x04, except in FAST DUTY mode
>> >> > where the minimum allowed value is 0x01
>> >> >
>> >> > You don't check for that, right?
>> >>
>> >> As the minimum freq value is 6 Mhz in fast mode the minimum CCR is 5
>> >> as described in the comment.
>> >> So I don't need to check that again as it is already done by checking
>> >> parent frequency.
>> >
>> > That would then go into a comment.
>>
>> Is it really needed ?
>> Adding some comments to explain implementation choices or  hardware
>> way of working is clearly useful.
>> But for this kind of thing, I am really surprised...
>
> TL;DR: It's not needed, but it probably helps.
>
> Consider someone sees a breakage in your driver in five years. By then
> you either have other interests or at least forgot 95 % of the thoughts
> you had when implementing the driver.
>
> So when I see:
>
> val = DIV_ROUND_UP(i2c_dev->parent_rate, 40 * 3);
> ccr |= STM32F4_I2C_CCR_CCR(val);
> writel_relaxed(ccr, i2c_dev->base + STM32F4_I2C_CCR);
>
> after seeing that the bus freq is wrong the obvious thoughts are:
>
>  - Does this use the right algorithm?
>  - Does this calculation result in values that are usable by the
>hardware?
>
> That you thought about this today doesn't mean it's still right in five
> years. During that time a new hardware variant is available with a
> higher parent freq. Or there is a new errata available for the SoC.
>
> So to help answer the questions above it helps if you add today the
> formulas from the manual and a quick reason for why val fits into the
> respective bits in the CCR register. That comment might be wrong until
> then, too, but that only means you should make it easy to verify.
> Something like:
>
> /*
>  * Function bla_blub made sure that parent_rate is not higher
>  * than 23 * pi MHz. As a result val is at most 13.2 bits wide
>  * and so fits into the CCR bits.
>  */
>
> This gives you in five years time the opportunity to quickly check
> bla_blub if this is still true, add a printk for parent_rate to check
> this, or quickly identify the bug in the code or the mismatch to the
> manual.
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.   | Uwe Kleine-König|
> Industrial Linux Solutions | http://www.pengutronix.de/  |


Re: [PATCH v9 2/5] i2c: Add STM32F4 I2C driver

2017-01-18 Thread M'boumba Cedric Madianga
2017-01-18 19:42 GMT+01:00 Uwe Kleine-König :
> Hello Cedric,
>
> On Wed, Jan 18, 2017 at 04:21:17PM +0100, M'boumba Cedric Madianga wrote:
>> >> +  * In standard mode, the maximum allowed SCL rise time is 1000 ns.
>> >> +  * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is 
>> >> equal to
>> >> +  * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
>> >> +  * programmed with 09h.(1000 ns / 125 ns = 8 + 1)
>> >
>> > * programmed with 0x9.
>> > (1000 ns / 125 ns = 8)
>> >
>> >> +  * So, for I2C standard mode TRISE = FREQ[5:0] + 1
>> >> +  *
>> >> +  * In fast mode, the maximum allowed SCL rise time is 300 ns.
>> >> +  * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is 
>> >> equal to
>> >> +  * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
>> >> +  * programmed with 03h.(300 ns / 125 ns = 2 + 1)
>> >
>> > as above s/03h/0x3/;
>>
>> ok
>>
>> > s/.(/. (/;
>> ok
>>
>> > s/+ 1//;
>> This formula is use to understand how we find the result 0x3
>> So, 0x3 => 300 ns / 125ns = 2 + 1
>
> Yeah, I understood that, but writing 300 ns / 125ns = 2 + 1 is
> irritating at best.

Ok. I will write 0x3 (300 ns / 125 ns + 1) and 0x9 (1000 ns / 125 ns + 1)

>> > [...]
>> > If DUTY = 1: (to reach 400 kHz)
>> >
>> > Strange.
>> >
>> >> + val = DIV_ROUND_UP(i2c_dev->parent_rate, 40 * 3);
>> >
>> > the manual reads:
>> >
>> > The minimum allowed value is 0x04, except in FAST DUTY mode
>> > where the minimum allowed value is 0x01
>> >
>> > You don't check for that, right?
>>
>> As the minimum freq value is 6 Mhz in fast mode the minimum CCR is 5
>> as described in the comment.
>> So I don't need to check that again as it is already done by checking
>> parent frequency.
>
> That would then go into a comment.

Is it really needed ?
Adding some comments to explain implementation choices or  hardware
way of working is clearly useful.
But for this kind of thing, I am really surprised...

>
>> > CCR is 11 bits wide. A comment confirming that this cannot overflow
>> > would be nice.
>>
>> Again there is no chance of overflow thanks to parent frequency check
>
> Right, this time I saw this myself, so I requested a comment stating
> this fact.

ditto

Best regards,
Cedric


Re: [PATCH v9 2/5] i2c: Add STM32F4 I2C driver

2017-01-18 Thread M'boumba Cedric Madianga
Hello Uwe,

2017-01-17 20:37 GMT+01:00 Uwe Kleine-König :
> Hello,
>
> On Tue, Jan 17, 2017 at 04:26:58PM +0100, M'boumba Cedric Madianga wrote:
>> +static void stm32f4_i2c_set_rise_time(struct stm32f4_i2c_dev *i2c_dev)
>> +{
>> + u32 freq = DIV_ROUND_UP(i2c_dev->parent_rate, HZ_TO_MHZ);
>> + u32 trise;
>> +
>> + /*
>> +  * These bits must be programmed with the maximum SCL rise time given 
>> in
>> +  * the I2C bus specification, incremented by 1.
>> +  *
>> +  * In standard mode, the maximum allowed SCL rise time is 1000 ns.
>> +  * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
>> +  * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
>> +  * programmed with 09h.(1000 ns / 125 ns = 8 + 1)
>
> * programmed with 0x9.
> (1000 ns / 125 ns = 8)
>
>> +  * So, for I2C standard mode TRISE = FREQ[5:0] + 1
>> +  *
>> +  * In fast mode, the maximum allowed SCL rise time is 300 ns.
>> +  * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
>> +  * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
>> +  * programmed with 03h.(300 ns / 125 ns = 2 + 1)
>
> as above s/03h/0x3/;

ok

> s/.(/. (/;
ok

> s/+ 1//;
This formula is use to understand how we find the result 0x3
So, 0x3 => 300 ns / 125ns = 2 + 1

>
>> +  * So, for I2C fast mode TRISE = FREQ[5:0] * 300 / 1000 + 1
>> +  */
>> + if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD)
>> + trise = freq + 1;
>> + else
>> + trise = freq * 300 / 1000 + 1;
>
> I'd use
>
> * 3 / 10
>
> without downside and lesser chance to overflow.

There is no chance of overflow as the max freq value allowed is 46

>
>> +
>> + writel_relaxed(STM32F4_I2C_TRISE_VALUE(trise),
>> +i2c_dev->base + STM32F4_I2C_TRISE);
>> +}
>> +
>> +static void stm32f4_i2c_set_speed_mode(struct stm32f4_i2c_dev *i2c_dev)
>> +{
>> + u32 val;
>> + u32 ccr = 0;
>> +
>> + if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD) {
>> + /*
>> +  * In standard mode:
>> +  * t_scl_high = t_scl_low = CCR * I2C parent clk period
>> +  * So to reach 100 kHz, we have:
>> +  * CCR = I2C parent rate / 100 kHz >> 1
>> +  *
>> +  * For example with parent rate = 2 MHz:
>> +  * CCR = 200 / (10 << 1) = 10
>> +  * t_scl_high = t_scl_low = 10 * (1 / 200) = 5000 ns
>> +  * t_scl_high + t_scl_low = 1 ns so 100 kHz is reached
>> +  */
>> + val = i2c_dev->parent_rate / (10 << 1);
>> + } else {
>> + /*
>> +  * In fast mode, we compute CCR with duty = 0 as with low
>> +  * frequencies we are not able to reach 400 kHz.
>> +  * In that case:
>> +  * t_scl_high = CCR * I2C parent clk period
>> +  * t_scl_low = 2 * CCR * I2C parent clk period
>> +  * So, CCR = I2C parent rate / (400 kHz * 3)
>> +  *
>> +  * For example with parent rate = 6 MHz:
>> +  * CCR = 600 / (40 * 3) = 5
>> +  * t_scl_high = 5 * (1 / 600) = 833 ns > 600 ns
>> +  * t_scl_low = 2 * 5 * (1 / 600) = 1667 ns > 1300 ns
>> +  * t_scl_high + t_scl_low = 2500 ns so 400 kHz is reached
>> +  */
>
> Huh, that's surprising. So you don't use DUTY any more. I found two
> hints in the manual that contradict here:

Yes with the above formula we could use duty = 0 by default

>
> f_{PCLK1} must be at least 2 MHz to achieve Sm mode I2C frequencies

STM32F4_I2C_MIN_STANDARD_FREQ = 2

> It must be at least 4 MHz to achieve Fm mode I2C frequencies.

STM32F4_I2C_MIN_FAST_FREQ = 6

> It must be a multiple of 10MHz to reach the 400 kHz maximum I2C Fm mode clock.

If we use this rule only 3 values are allowed 10 Mhz, 20 Mhz, 30 Mhz and 40 Mhz.
It is very restrictive.
So I don't take it into account in order to have more frequencies even
if 400 Khz is not reached.
Indeed, in many cases we are very close to 400 Khz.
For example, the default I2C parent clock in my board is 45 Mhz
I reach 395 kHz in theory and 390 kHz by testing.
I am in Fast mode but not with the max freq but very close.

>
> and
>
> [...]
> If DUTY = 1: (to reach 400 kHz)
>
> Strange.
>
>> + 

[PATCH v9 0/5] Add support for the STM32F4 I2C

2017-01-17 Thread M'boumba Cedric Madianga
This patchset adds support for the I2C controller embedded in STM32F4xx SoC.
It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus
speed.

Changes since v8:
- Rework I2C Clock Control Register computation (Uwe)
- Save register accesses as often as possible (Uwe)
- Don't use mask before saving rx buffer (Uwe)
- Add more comments to explain hardware way of working (Uwe)
- Rename stm32f4_i2c_handle_rx_btf function by stm32f4_i2c_handle_rx_done (Uwe)
- Set/Clear Ack position bit during address match phase

M'boumba Cedric Madianga (5):
  dt-bindings: Document the STM32 I2C bindings
  i2c: Add STM32F4 I2C driver
  ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
  ARM: dts: stm32: Add I2C1 support for STM32429 eval board
  ARM: configs: stm32: Add I2C support for STM32 defconfig

 .../devicetree/bindings/i2c/i2c-stm32.txt  |  33 +
 arch/arm/boot/dts/stm32429i-eval.dts   |   6 +
 arch/arm/boot/dts/stm32f429.dtsi   |  23 +
 arch/arm/configs/stm32_defconfig   |   3 +
 drivers/i2c/busses/Kconfig |  10 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-stm32f4.c   | 883 +
 7 files changed, 959 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
 create mode 100644 drivers/i2c/busses/i2c-stm32f4.c

-- 
1.9.1



[PATCH v9 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC

2017-01-17 Thread M'boumba Cedric Madianga
This patch adds I2C1 support for STM32F429 SoC

Signed-off-by: Patrice Chotard 
Signed-off-by: M'boumba Cedric Madianga 
---
 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 e4dae0e..5b063e9 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 
+#include 
 
 / {
clocks {
@@ -153,6 +154,18 @@
status = "disabled";
};
 
+   i2c1: i2c@40005400 {
+   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";
+   };
+
usart7: serial@40007800 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40007800 0x400>;
@@ -355,6 +368,16 @@
slew-rate = <2>;
};
};
+
+   i2c1_pins_b: i2c1@0 {
+   pins {
+   pinmux = ,
+;
+   bias-disable;
+   drive-open-drain;
+   slew-rate = <3>;
+   };
+   };
};
 
rcc: rcc@40023810 {
-- 
1.9.1



[PATCH v9 5/5] ARM: configs: stm32: Add I2C support for STM32 defconfig

2017-01-17 Thread M'boumba Cedric Madianga
This patch adds I2C support for STM32 default configuration

Signed-off-by: M'boumba Cedric Madianga 
---
 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 5a72d69..323d2a3 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -47,6 +47,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
-- 
1.9.1



[PATCH v9 4/5] ARM: dts: stm32: Add I2C1 support for STM32429 eval board

2017-01-17 Thread M'boumba Cedric Madianga
This patch adds I2C1 instance support for STM32x9I-Eval board.

Signed-off-by: M'boumba Cedric Madianga 
---
 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 76f7206..c943539 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -146,3 +146,9 @@
pinctrl-names = "default";
status = "okay";
 };
+
+&i2c1 {
+   pinctrl-0 = <&i2c1_pins_b>;
+   pinctrl-names = "default";
+   status = "okay";
+};
-- 
1.9.1



[PATCH v9 1/5] dt-bindings: Document the STM32 I2C bindings

2017-01-17 Thread M'boumba Cedric Madianga
This patch adds documentation of device tree bindings for the STM32 I2C
controller.

Signed-off-by: M'boumba Cedric Madianga 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/i2c/i2c-stm32.txt  | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt 
b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
new file mode 100644
index 000..78eaf7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
@@ -0,0 +1,33 @@
+* I2C controller embedded in STMicroelectronics STM32 I2C platform
+
+Required properties :
+- compatible : Must be "st,stm32f4-i2c"
+- reg : Offset and length of the register set for the device
+- interrupts : Must contain the interrupt id for I2C event and then the
+  interrupt id for I2C error.
+- resets: Must contain the phandle to the reset controller.
+- clocks: Must contain the input clock of the I2C instance.
+- A pinctrl state named "default" must be defined to set pins in mode of
+  operation for I2C transfer
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+  the default 100 kHz frequency will be used. As only Normal and Fast modes
+  are supported, possible values are 10 and 40.
+
+Example :
+
+   i2c@40005400 {
+   compatible = "st,stm32f4-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x40005400 0x400>;
+   interrupts = <31>,
+<32>;
+   resets = <&rcc 277>;
+   clocks = <&rcc 0 149>;
+   pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
+   pinctrl-names = "default";
+   };
-- 
1.9.1



[PATCH v9 2/5] i2c: Add STM32F4 I2C driver

2017-01-17 Thread M'boumba Cedric Madianga
This patch adds support for the STM32F4 I2C controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/i2c/busses/Kconfig   |  10 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-stm32f4.c | 883 +++
 3 files changed, 894 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 000..7733a96
--- /dev/null
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -0,0 +1,883 @@
+/*
+ * Driver for STMicroelectronics STM32 I2C controller
+ *
+ * This I2C controller is described in the STM32F429/439 Soc reference manual.
+ * Please see below a link to the documentation:
+ * http://www.st.com/resource/en/reference_manual/DM00031020.pdf
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2016
+ * Author: M'boumba Cedric Madianga 
+ *
+ * This driver is based on i2c-st.c
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* STM32F4 I2C offset registers */
+#define STM32F4_I2C_CR10x00
+#define STM32F4_I2C_CR20x04
+#define STM32F4_I2C_DR 0x10
+#define STM32F4_I2C_SR10x14
+#define STM32F4_I2C_SR20x18
+#define STM32F4_I2C_CCR0x1C
+#define STM32F4_I2C_TRISE  0x20
+#define STM32F4_I2C_FLTR   0x24
+
+/* STM32F4 I2C control 1*/
+#define STM32F4_I2C_CR1_POSBIT(11)
+#define STM32F4_I2C_CR1_ACKBIT(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)
+#define STM32F4_I2C_CR2_ITBUFENBIT(10)
+#define STM32F4_I2C_CR2_ITEVTENBIT(9)
+#define STM32F4_I2C_CR2_ITERRENBIT(8)
+#define STM32F4_I2C_CR2_IRQ_MASK   (STM32F4_I2C_CR2_ITBUFEN | \
+STM32F4_I2C_CR2_ITEVTEN | \
+STM32F4_I2C_CR2_ITERREN)
+
+/* 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_TXEBIT(7)
+#define STM32F4_I2C_SR1_RXNE   BIT(6)
+#define STM32F4_I2C_SR1_BTFBIT(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)
+#d

Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

2017-01-13 Thread M'boumba Cedric Madianga
Ok so I am going to send the v9 asap.
Thanks

2017-01-13 9:45 GMT+01:00 Uwe Kleine-König :
> On Fri, Jan 13, 2017 at 09:29:03AM +0100, Wolfram Sang wrote:
>>
>> > (But note that this is irrelevant for the patch as the driver doesn't
>> > claim to support this kind of transfer.)
>>
>> Yes, I wanted to mention that, too.
>>
>> I'd think the series is good to go in?
>
> AFAICT there are some unaddressed comments that Cedrics claimed to fix
> before our discussion was dominated by block transfers.
>
> Best regards
> Uwe
>
>
>
> --
> Pengutronix e.K.   | Uwe Kleine-König|
> Industrial Linux Solutions | http://www.pengutronix.de/  |


Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

2017-01-12 Thread M'boumba Cedric Madianga
2017-01-12 22:10 GMT+01:00 Uwe Kleine-König :
> On Thu, Jan 12, 2017 at 09:58:23PM +0100, M'boumba Cedric Madianga wrote:
>> 2017-01-12 18:49 GMT+01:00 Uwe Kleine-König :
>> > On Thu, Jan 12, 2017 at 02:47:42PM +0100, M'boumba Cedric Madianga wrote:
>> >> 2017-01-12 13:03 GMT+01:00 Uwe Kleine-König 
>> >> :
>> >> > Hello Cedric,
>> >> >
>> >> > On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga 
>> >> > wrote:
>> >> >> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-König 
>> >> >> :
>> >> >> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga 
>> >> >> > wrote:
>> >> >> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-König 
>> >> >> >> :
>> >> >> >> > This is surprising. I didn't recheck the manual, but that looks 
>> >> >> >> > very
>> >> >> >> > uncomfortable.
>> >> >> >>
>> >> >> >> I agree but this exactly the hardware way of working described in 
>> >> >> >> the
>> >> >> >> reference manual.
>> >> >> >
>> >> >> > IMHO that's a hw bug. This makes it for example impossible to 
>> >> >> > implement
>> >> >> > SMBus block transfers (I think).
>> >> >>
>> >> >> This is not correct.
>> >> >> Setting STOP/START bit does not mean the the pulse will be sent right 
>> >> >> now.
>> >> >> Here we have just to prepare the hardware for the 2 next pulse but the
>> >> >> STOP/START/ACK pulse will be generated at the right time as required
>> >> >> by I2C specification.
>> >> >> So SMBus block transfer will be possible.
>> >> >
>> >> > A block transfer consists of a byte that specifies the count of bytes
>> >> > yet to come. So the device sends for example:
>> >> >
>> >> > 0x01 0xab
>> >> >
>> >> > So when you read the 1 in the first byte it's already too late to set
>> >> > STOP to get it after the 2nd byte.
>> >> >
>> >> > Not sure I got all the required details right, though.
>> >>
>> >> Ok I understand your use case but I always think that the harware manages 
>> >> it.
>> >> If I take the above example, the I2C SMBus block read transaction will
>> >> be as below:
>> >> S Addr Wr [A] Comm [A]
>> >>S Addr Rd [A] [Count] A [Data1] A [Data2] NA P
>> >>
>> >> The first message is a single byte-transmission so there is no problem.
>> >>
>> >> The second message is a N-byte reception with N = 3
>> >>
>> >> When the I2C controller has finished to send the device address (S
>> >> Addr Rd), the ADDR flag is set and an interrupt is raised.
>> >> In the routine that handles ADDR event, we set ACK bit in order to
>> >> generate ACK pulse as soon as a data byte is received in the shift
>> >> register and then we clear the ADDR flag.
>> >> Please note that the SCL line is stretched low until ADDR flag is cleared.
>> >> So, as far I understand, the device could not sent any data as long as
>> >> the SCL line is stretched low. Right ?
>> >>
>> >> Then, as soon as the SCL line is high, the device could send the first
>> >> data byte (Count).
>> >> When this byte is received in the shift register, an ACK is
>> >> automatically generated as defined during adress match phase and the
>> >> data byte is pushed in DR (data register).
>> >> Then, an interrupt is raised as RXNE (RX not empty) flag is set.
>> >> In the routine that handles RXNE event, as N=3, we just clear all
>> >> buffer interrupts in order to avoid another system preemption due to
>> >> RXNE event but we does not read the data in DR.
>> >
>> > In my example I want to receive a block of length 1, so only two bytes
>> > are read, a 1 (the length) and the data byte (0xab in my example). I
>> > think that as soon as you read the 1 it's already to late to schedule
>> > the NA after the next byte?
>>
>> Not really. This 2-byte reception is also correctly managed.
>> Indeed, in this case, when the controller has sent the device address,
>> the ADDR flag is set and an interrupt is raised.
>> So, as long as the ADDR flag is not cleared, the SCL line is stretched
>> low and the device could not send any data.
>> During this address match phase, for a 2-byte reception, we enable
>> NACK and set POS bit (ACK/NACK position).
>> As POS=1, the NACK will be sent for the next byte which will be
>> received in the shift register instead of the current one.
>> So in this example, the next byte will be the last one.
>> After that, we clear the ADDR flag and the device is allowed to send data.
>
> I didn't follow, but if you are convinced it works that's good. I wonder
> if it simplifies the driver if POS=1 is used and so ACK/NACK can be
> setup later?

Please see below a quote from datasheet that clearly described how to handle
For 2-byte reception:
● Wait until ADDR = 1 (SCL stretched low until the ADDR flag is cleared)
● Set ACK low, set POS high
● Clear ADDR flag
● Wait until BTF = 1 (Data 1 in DR, Data2 in shift register, SCL
stretched low until a data1 is read)
● Set STOP high
● Read data 1 and 2

So we cannot set POS=1 and setup ACK/NACK later as you suggest.

Best regards,

Cedric


Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

2017-01-12 Thread M'boumba Cedric Madianga
2017-01-12 18:49 GMT+01:00 Uwe Kleine-König :
> On Thu, Jan 12, 2017 at 02:47:42PM +0100, M'boumba Cedric Madianga wrote:
>> 2017-01-12 13:03 GMT+01:00 Uwe Kleine-König :
>> > Hello Cedric,
>> >
>> > On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga wrote:
>> >> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-König 
>> >> :
>> >> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga 
>> >> > wrote:
>> >> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-König 
>> >> >> :
>> >> >> > This is surprising. I didn't recheck the manual, but that looks very
>> >> >> > uncomfortable.
>> >> >>
>> >> >> I agree but this exactly the hardware way of working described in the
>> >> >> reference manual.
>> >> >
>> >> > IMHO that's a hw bug. This makes it for example impossible to implement
>> >> > SMBus block transfers (I think).
>> >>
>> >> This is not correct.
>> >> Setting STOP/START bit does not mean the the pulse will be sent right now.
>> >> Here we have just to prepare the hardware for the 2 next pulse but the
>> >> STOP/START/ACK pulse will be generated at the right time as required
>> >> by I2C specification.
>> >> So SMBus block transfer will be possible.
>> >
>> > A block transfer consists of a byte that specifies the count of bytes
>> > yet to come. So the device sends for example:
>> >
>> > 0x01 0xab
>> >
>> > So when you read the 1 in the first byte it's already too late to set
>> > STOP to get it after the 2nd byte.
>> >
>> > Not sure I got all the required details right, though.
>>
>> Ok I understand your use case but I always think that the harware manages it.
>> If I take the above example, the I2C SMBus block read transaction will
>> be as below:
>> S Addr Wr [A] Comm [A]
>>S Addr Rd [A] [Count] A [Data1] A [Data2] NA P
>>
>> The first message is a single byte-transmission so there is no problem.
>>
>> The second message is a N-byte reception with N = 3
>>
>> When the I2C controller has finished to send the device address (S
>> Addr Rd), the ADDR flag is set and an interrupt is raised.
>> In the routine that handles ADDR event, we set ACK bit in order to
>> generate ACK pulse as soon as a data byte is received in the shift
>> register and then we clear the ADDR flag.
>> Please note that the SCL line is stretched low until ADDR flag is cleared.
>> So, as far I understand, the device could not sent any data as long as
>> the SCL line is stretched low. Right ?
>>
>> Then, as soon as the SCL line is high, the device could send the first
>> data byte (Count).
>> When this byte is received in the shift register, an ACK is
>> automatically generated as defined during adress match phase and the
>> data byte is pushed in DR (data register).
>> Then, an interrupt is raised as RXNE (RX not empty) flag is set.
>> In the routine that handles RXNE event, as N=3, we just clear all
>> buffer interrupts in order to avoid another system preemption due to
>> RXNE event but we does not read the data in DR.
>
> In my example I want to receive a block of length 1, so only two bytes
> are read, a 1 (the length) and the data byte (0xab in my example). I
> think that as soon as you read the 1 it's already to late to schedule
> the NA after the next byte?

Not really. This 2-byte reception is also correctly managed.
Indeed, in this case, when the controller has sent the device address,
the ADDR flag is set and an interrupt is raised.
So, as long as the ADDR flag is not cleared, the SCL line is stretched
low and the device could not send any data.
During this address match phase, for a 2-byte reception, we enable
NACK and set POS bit (ACK/NACK position).
As POS=1, the NACK will be sent for the next byte which will be
received in the shift register instead of the current one.
So in this example, the next byte will be the last one.
After that, we clear the ADDR flag and the device is allowed to send data.

When the first data is received in the shift register,  the RXNE flag
is set and an interrupt is raised.
As it is a 2-byte reception, we just clear all interrupts buffer to
avoid another preemption due to RXNE but we does not read DR.

Then, the second and last byte is received in the shift register.
The NACK is automatically sent by I2C controller as it was configured
to do that in the address match phase described above.
Moereover, as the first byte has not been read in DR, the BTF event
flag is set and an interrupt is raised.
Again, the SCL line is stretching low as long as data register has not
been read.
In the meantime, we set STOP bit to generate the pulse and we launch 2
consecutive read of DR to retrieve the 2 data bytes and release SCL
stretching.

In that way, NA and STOP are generated as expected even for a 2-byte reception.

Best regards,

Cedric


Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

2017-01-12 Thread M'boumba Cedric Madianga
>>> > I don't understand scl_period = 1 µs for Fast Mode. For a bus freqency
>>> > of 400 kHz we need low + high = 2.5 µs. Is there a factor 10 missing
>>> > somewhere?
>>>
>>> As CCR = SCL_period * I2C parent clk frequency with minimal freq =
>>> 2Mhz and SCL_period = 1 we have:
>>> CCR = 1 * 2Mhz = 2.
>>> But to compute, scl_low and scl_high in Fast mode, we have to do the
>>> following thing as Duty=1:
>>> scl_high = 9 * CCR * I2C parent clk period
>>> scl_low = 16 * CCR * I2C parent clk period
>>> In our example:
>>> scl_high = 9 * 2 * 0,005 = 0,09 sec = 9 µs
>>> scl_low = 16 * 2 * 0.005 = 0,16 sec = 16 µs
>>> So low + high = 27 µs > 2,5 µs
>>
>> For me 9 µs + 16 µs is 25 µs, resulting in 40 kHz. That's why I wondered
>> if there is a factor 10 missing somewhere.
>
> Hum ok. I am going to double-check what is wrong because when I check
> with the scope I always reach 400Khz for SCL.
> I will let you know.

There is one point I miss here that is described in the reference manual:
To reach the 400 kHz maximum I²C fast mode clock, the I2C parent rate
must be a multiple of 10 MHz.
So, contrary to what we said in a previous thread, 400 kHz could not
be reached with low frequencies.
In that way, we could compute CCR with duty = 0 by default.
So, I find another formula very close to the first one I pushed in the
first version:

In fast mode, we compute CCR with duty = 0:
t_scl_high = CCR * I2C parent clk period
t_scl_low = 2 *CCR * I2C parent clk period
So, CCR = I2C parent rate / 400 kHz / 3

For example with parent rate = 40 MHz:
CCR = 4000 / 40 / 3 = 33.3 = 33
t_scl_high = 33 * (1 / 200) = 825 ns > 600 ns
t_scl_low = 2 * 16 * (1 / 200) = 1650 ns > 1300 ns

It seems ok now.

Best regards,

Cedric


Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

2017-01-12 Thread M'boumba Cedric Madianga
2017-01-12 13:03 GMT+01:00 Uwe Kleine-König :
> Hello Cedric,
>
> On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga wrote:
>> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-König :
>> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
>> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-König 
>> >> :
>> >> > This is surprising. I didn't recheck the manual, but that looks very
>> >> > uncomfortable.
>> >>
>> >> I agree but this exactly the hardware way of working described in the
>> >> reference manual.
>> >
>> > IMHO that's a hw bug. This makes it for example impossible to implement
>> > SMBus block transfers (I think).
>>
>> This is not correct.
>> Setting STOP/START bit does not mean the the pulse will be sent right now.
>> Here we have just to prepare the hardware for the 2 next pulse but the
>> STOP/START/ACK pulse will be generated at the right time as required
>> by I2C specification.
>> So SMBus block transfer will be possible.
>
> A block transfer consists of a byte that specifies the count of bytes
> yet to come. So the device sends for example:
>
> 0x01 0xab
>
> So when you read the 1 in the first byte it's already too late to set
> STOP to get it after the 2nd byte.
>
> Not sure I got all the required details right, though.

Ok I understand your use case but I always think that the harware manages it.
If I take the above example, the I2C SMBus block read transaction will
be as below:
S Addr Wr [A] Comm [A]
   S Addr Rd [A] [Count] A [Data1] A [Data2] NA P

The first message is a single byte-transmission so there is no problem.

The second message is a N-byte reception with N = 3

When the I2C controller has finished to send the device address (S
Addr Rd), the ADDR flag is set and an interrupt is raised.
In the routine that handles ADDR event, we set ACK bit in order to
generate ACK pulse as soon as a data byte is received in the shift
register and then we clear the ADDR flag.
Please note that the SCL line is stretched low until ADDR flag is cleared.
So, as far I understand, the device could not sent any data as long as
the SCL line is stretched low. Right ?

Then, as soon as the SCL line is high, the device could send the first
data byte (Count).
When this byte is received in the shift register, an ACK is
automatically generated as defined during adress match phase and the
data byte is pushed in DR (data register).
Then, an interrupt is raised as RXNE (RX not empty) flag is set.
In the routine that handles RXNE event, as N=3, we just clear all
buffer interrupts in order to avoid another system preemption due to
RXNE event but we does not read the data in DR.

After receiving the ACK, the device could send the second data byte (Data1).
When this byte is received in the shift register, an ACK is
automatically generated.
As the first data byte has not been read yet in DR, the BTF (Byte
Transfer Finihed) flag is set and an interrupt is raised.
So, in that case, the SCL line is also streched low as long as the
data register has not been read.
In the routine that handle BTF event, we enable NACK in order to
generate this pulse as soon as the last data byte will be received and
then we read DR register ([Count])
At this moment, SCL line is released and the device could send the
last data byte.

After receiving the ACK, the device could send the third and last data
byte (Data2)
When this byte is received in the shift register, a NACK is
automatically generated as we enable it as explained above.
As the second data byte  (Data1) has not been read yet in DR, the BTF
flag is set again and an interrupt is raised.
The SCL line is stretched low and in that way we could set the STOP
bit to generate this pulse.
Then we run 2 consecutives read of DR to retrieve [Data1] and [Data2]
and to set SCL high.

So, thanks to SCL stretching, it seems that NA and P will be generated
at the right time.

Please let me know if it is not correct.

Best regards,

Cedric


Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

2017-01-12 Thread M'boumba Cedric Madianga
Hi Uwe,

2017-01-11 16:42 GMT+01:00 Uwe Kleine-König :
> Hello Cedric,
>
> On Wed, Jan 11, 2017 at 03:20:41PM +0100, M'boumba Cedric Madianga wrote:
>> >
>> >> +  */
>> >> + 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);
>> >
>> > You could get rid of this, when caching the value of CR1. Would save two
>> > register reads here. This doesn't work for all registers, but it should
>> > be possible to apply for most of them, maybe enough to get rid of the
>> > clr_bits and set_bits function.
>>
>> I agree at many places I could save registers read by not using
>> clr_bits and set_bits function when the registers in question has been
>> already read.
>> But it is not enough to get rid of the clr_bits and set_bits function.
>> For example when calling stm32f4_i2c_terminate_xfer(), the CR1
>> register is never read before so set_bits function is useful.
>
> I didn't double check the manual, but I would expect that CR1 isn't
> modified by hardware. So you can cache the result in the driver data
> structure and do the necessary modifications with that one.

CR1 is modified by hardware to clear some bits set by software during
the communication.

>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.   | Uwe Kleine-König|
> Industrial Linux Solutions | http://www.pengutronix.de/  |

Best regards,

Cedric


Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

2017-01-12 Thread M'boumba Cedric Madianga
2017-01-11 16:39 GMT+01:00 Uwe Kleine-König :
> On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
>> Hi Uwe,
>>
>> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-König :
>> > Hello Cedric,
>> >
>> > On Thu, Jan 05, 2017 at 10:07:23AM +0100, M'boumba Cedric Madianga wrote:
>> >> +/*
>> >> + * In standard mode:
>> >> + * SCL period = SCL high period = SCL low period = CCR * I2C parent clk 
>> >> period
>> >> + *
>> >> + * In fast mode:
>> >> + * If Duty = 0; SCL high period = 1  * CCR * I2C parent clk period
>  ^^
>> >> + *   SCL low period  = 2  * CCR * I2C parent clk period
>   ^^
>> >> + * If Duty = 1; SCL high period = 9  * CCR * I2C parent clk period
>  ^^
>> >> + *   SCL low period  = 16 * CCR * I2C parent clk period
>
>> > s/  \*/ */ several times
>>
>> Sorry but I don't see where is the issue as the style for multi-line
>> comments seems ok.
>> Could you please clarify that point if possible ? Thanks in advance
>
> There are several places with double spaces before * marked above.

Ok I see thanks.

>
>> >> + * In order to reach 400 kHz with lower I2C parent clk frequencies we 
>> >> always set
>> >> + * Duty = 1
>> >> + *
>> >> + * For both modes, we have CCR = SCL period * I2C parent clk frequency
>> >> + * with scl_period = 5 microseconds in Standard mode and scl_period = 1
>> > s/mode/Mode/
>>
>> ok thanks
>>
>> >
>> >> + * microsecond in Fast Mode in order to satisfy scl_high and scl_low 
>> >> periods
>> >> + * constraints defined by i2c bus specification
>> >
>> > I don't understand scl_period = 1 µs for Fast Mode. For a bus freqency
>> > of 400 kHz we need low + high = 2.5 µs. Is there a factor 10 missing
>> > somewhere?
>>
>> As CCR = SCL_period * I2C parent clk frequency with minimal freq =
>> 2Mhz and SCL_period = 1 we have:
>> CCR = 1 * 2Mhz = 2.
>> But to compute, scl_low and scl_high in Fast mode, we have to do the
>> following thing as Duty=1:
>> scl_high = 9 * CCR * I2C parent clk period
>> scl_low = 16 * CCR * I2C parent clk period
>> In our example:
>> scl_high = 9 * 2 * 0,005 = 0,09 sec = 9 µs
>> scl_low = 16 * 2 * 0.005 = 0,16 sec = 16 µs
>> So low + high = 27 µs > 2,5 µs
>
> For me 9 µs + 16 µs is 25 µs, resulting in 40 kHz. That's why I wondered
> if there is a factor 10 missing somewhere.

Hum ok. I am going to double-check what is wrong because when I check
with the scope I always reach 400Khz for SCL.
I will let you know.
>
>> >> + */
>> >> +static struct stm32f4_i2c_timings i2c_timings[] = {
>> >> [...]
>> >> +
>> >> +/**
>> >> + * stm32f4_i2c_hw_config() - Prepare I2C block
>> >> + * @i2c_dev: Controller's private data
>> >> + */
>> >> +static int stm32f4_i2c_hw_config(struct stm32f4_i2c_dev *i2c_dev)
>> >> +{
>> >> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR1;
>> >> + int ret = 0;
>> >> +
>> >> + /* Disable I2C */
>> >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_PE);
>> >> +
>> >> + ret = stm32f4_i2c_set_periph_clk_freq(i2c_dev);
>> >> + if (ret)
>> >> + return ret;
>> >> +
>> >> + stm32f4_i2c_set_rise_time(i2c_dev);
>> >> +
>> >> + stm32f4_i2c_set_speed_mode(i2c_dev);
>> >> +
>> >> + stm32f4_i2c_set_filter(i2c_dev);
>> >> +
>> >> + /* Enable I2C */
>> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_PE);
>> >
>> > This function is called after a hw reset, so there should be no need to
>> > use clr_bits and set_bits because the value read from hw should be
>> > known.
>>
>> ok thanks
>>
>> >
>> >> + return ret;
>> >
>> > return 0;
>>
>> ok thanks
>>
>> >
>> >> +}
>> >> +
>> >> +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,
>

Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

2017-01-11 Thread M'boumba Cedric Madianga
>
>> +  */
>> + 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);
>
> You could get rid of this, when caching the value of CR1. Would save two
> register reads here. This doesn't work for all registers, but it should
> be possible to apply for most of them, maybe enough to get rid of the
> clr_bits and set_bits function.

I agree at many places I could save registers read by not using
clr_bits and set_bits function when the registers in question has been
already read.
But it is not enough to get rid of the clr_bits and set_bits function.
For example when calling stm32f4_i2c_terminate_xfer(), the CR1
register is never read before so set_bits function is useful.
Another example, when stm32f4_i2c_handle_rx_done(), the CR1 register
is also never read before so clr_bits finction is again useful.

2017-01-11 14:58 GMT+01:00 M'boumba Cedric Madianga :
> Hi Uwe,
>
> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-König :
>> Hello Cedric,
>>
>> On Thu, Jan 05, 2017 at 10:07:23AM +0100, M'boumba Cedric Madianga wrote:
>>> +/*
>>> + * In standard mode:
>>> + * SCL period = SCL high period = SCL low period = CCR * I2C parent clk 
>>> period
>>> + *
>>> + * In fast mode:
>>> + * If Duty = 0; SCL high period = 1  * CCR * I2C parent clk period
>>> + *   SCL low period  = 2  * CCR * I2C parent clk period
>>> + * If Duty = 1; SCL high period = 9  * CCR * I2C parent clk period
>>> + *   SCL low period  = 16 * CCR * I2C parent clk period
>> s/  \*/ */ several times
>
> Sorry but I don't see where is the issue as the style for multi-line
> comments seems ok.
> Could you please clarify that point if possible ? Thanks in advance
>
>>
>>> + * In order to reach 400 kHz with lower I2C parent clk frequencies we 
>>> always set
>>> + * Duty = 1
>>> + *
>>> + * For both modes, we have CCR = SCL period * I2C parent clk frequency
>>> + * with scl_period = 5 microseconds in Standard mode and scl_period = 1
>> s/mode/Mode/
>
> ok thanks
>
>>
>>> + * microsecond in Fast Mode in order to satisfy scl_high and scl_low 
>>> periods
>>> + * constraints defined by i2c bus specification
>>
>> I don't understand scl_period = 1 µs for Fast Mode. For a bus freqency
>> of 400 kHz we need low + high = 2.5 µs. Is there a factor 10 missing
>> somewhere?
>
> As CCR = SCL_period * I2C parent clk frequency with minimal freq =
> 2Mhz and SCL_period = 1 we have:
> CCR = 1 * 2Mhz = 2.
> But to compute, scl_low and scl_high in Fast mode, we have to do the
> following thing as Duty=1:
> scl_high = 9 * CCR * I2C parent clk period
> scl_low = 16 * CCR * I2C parent clk period
> In our example:
> scl_high = 9 * 2 * 0,005 = 0,09 sec = 9 µs
> scl_low = 16 * 2 * 0.005 = 0,16 sec = 16 µs
> So low + high = 27 µs > 2,5 µs
>
>>
>>> + */
>>> +static struct stm32f4_i2c_timings i2c_timings[] = {
>>> [...]
>>> +
>>> +/**
>>> + * stm32f4_i2c_hw_config() - Prepare I2C block
>>> + * @i2c_dev: Controller's private data
>>> + */
>>> +static int stm32f4_i2c_hw_config(struct stm32f4_i2c_dev *i2c_dev)
>>> +{
>>> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR1;
>>> + int ret = 0;
>>> +
>>> + /* Disable I2C */
>>> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_PE);
>>> +
>>> + ret = stm32f4_i2c_set_periph_clk_freq(i2c_dev);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + stm32f4_i2c_set_rise_time(i2c_dev);
>>> +
>>> + stm32f4_i2c_set_speed_mode(i2c_dev);
>>> +
>>> + stm32f4_i2c_set_filter(i2c_dev);
>>> +
>>> + /* Enable I2C */
>>> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_PE);
>>
>> This function is called after a hw reset, so there should be no need to
>> use clr_bits and set_bits because the value read from hw should be
>> known.
>
> ok thanks
>
>>
>>> + return ret;
>>
>> return 0;
>
> ok thanks
>
>>
>>> +}
>>> +
>>> +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,

Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

2017-01-11 Thread M'boumba Cedric Madianga
Hi Uwe,

2017-01-11 9:22 GMT+01:00 Uwe Kleine-König :
> Hello Cedric,
>
> On Thu, Jan 05, 2017 at 10:07:23AM +0100, M'boumba Cedric Madianga wrote:
>> +/*
>> + * In standard mode:
>> + * SCL period = SCL high period = SCL low period = CCR * I2C parent clk 
>> period
>> + *
>> + * In fast mode:
>> + * If Duty = 0; SCL high period = 1  * CCR * I2C parent clk period
>> + *   SCL low period  = 2  * CCR * I2C parent clk period
>> + * If Duty = 1; SCL high period = 9  * CCR * I2C parent clk period
>> + *   SCL low period  = 16 * CCR * I2C parent clk period
> s/  \*/ */ several times

Sorry but I don't see where is the issue as the style for multi-line
comments seems ok.
Could you please clarify that point if possible ? Thanks in advance

>
>> + * In order to reach 400 kHz with lower I2C parent clk frequencies we 
>> always set
>> + * Duty = 1
>> + *
>> + * For both modes, we have CCR = SCL period * I2C parent clk frequency
>> + * with scl_period = 5 microseconds in Standard mode and scl_period = 1
> s/mode/Mode/

ok thanks

>
>> + * microsecond in Fast Mode in order to satisfy scl_high and scl_low periods
>> + * constraints defined by i2c bus specification
>
> I don't understand scl_period = 1 µs for Fast Mode. For a bus freqency
> of 400 kHz we need low + high = 2.5 µs. Is there a factor 10 missing
> somewhere?

As CCR = SCL_period * I2C parent clk frequency with minimal freq =
2Mhz and SCL_period = 1 we have:
CCR = 1 * 2Mhz = 2.
But to compute, scl_low and scl_high in Fast mode, we have to do the
following thing as Duty=1:
scl_high = 9 * CCR * I2C parent clk period
scl_low = 16 * CCR * I2C parent clk period
In our example:
scl_high = 9 * 2 * 0,005 = 0,09 sec = 9 µs
scl_low = 16 * 2 * 0.005 = 0,16 sec = 16 µs
So low + high = 27 µs > 2,5 µs

>
>> + */
>> +static struct stm32f4_i2c_timings i2c_timings[] = {
>> [...]
>> +
>> +/**
>> + * stm32f4_i2c_hw_config() - Prepare I2C block
>> + * @i2c_dev: Controller's private data
>> + */
>> +static int stm32f4_i2c_hw_config(struct stm32f4_i2c_dev *i2c_dev)
>> +{
>> + void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR1;
>> + int ret = 0;
>> +
>> + /* Disable I2C */
>> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_PE);
>> +
>> + ret = stm32f4_i2c_set_periph_clk_freq(i2c_dev);
>> + if (ret)
>> + return ret;
>> +
>> + stm32f4_i2c_set_rise_time(i2c_dev);
>> +
>> + stm32f4_i2c_set_speed_mode(i2c_dev);
>> +
>> + stm32f4_i2c_set_filter(i2c_dev);
>> +
>> + /* Enable I2C */
>> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_PE);
>
> This function is called after a hw reset, so there should be no need to
> use clr_bits and set_bits because the value read from hw should be
> known.

ok thanks

>
>> + return ret;
>
> return 0;

ok thanks

>
>> +}
>> +
>> +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_dbg(i2c_dev->dev, "bus not free\n");
>> + ret = -EBUSY;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +/**
>> + * stm32f4_i2c_write_ byte() - Write a byte in the data register
>> + * @i2c_dev: Controller's private data
>> + * @byte: Data to write in the register
>> + */
>> +static void stm32f4_i2c_write_byte(struct stm32f4_i2c_dev *i2c_dev, u8 byte)
>> +{
>> + writel_relaxed(byte, i2c_dev->base + STM32F4_I2C_DR);
>> +}
>> +
>> +/**
>> + * stm32f4_i2c_write_msg() - Fill the data register in write mode
>> + * @i2c_dev: Controller's private data
>> + *
>> + * This function fills the data register with I2C transfer buffer
>> + */
>> +static void stm32f4_i2c_write_msg(struct stm32f4_i2c_dev *i2c_dev)
>> +{
>> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
>> +
>> + stm32f4_i2c_write_byte(i2c_dev, *msg->buf++);
>> + msg->count--;
>> +}
>> +
>> +static void stm32f4_i2c_read_msg(struct stm32f4_i2c_dev *i2c_dev)
>> +{
>> + struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
>> + u32 rbuf;
>> +
>> + rbuf

[PATCH v8 0/5] Add support for the STM32F4 I2C

2017-01-05 Thread M'boumba Cedric Madianga
This patchset adds support for the I2C controller embedded in STM32F4xx SoC.
It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus
speed.

Changes since v7:
- Remove unneeded parenthesis in some macro definitions (Uwe)
- Fix some typo (s/KhzkHZ, s/PEC/POC) (Uwe)
- Fix alignment issues in some structures declaration (Uwe)
- Clarify comments to argue i2c_timing values chosen (Uwe)
- Raise an error if parent clk rate is out of scope during I2C hw config (Uwe)
- Use dev_dbg instead of dev_err message when I2C bus is busy  (Uwe)
- Add more comments about stuff done by stm32f4_i2c_handle_rx_btf() (Uwe)
- Simplify stm32f4_i2c_isr_error() routine implementation by removing possible
  status checking (Uwe)
- Rework stm32f4_i2c_isr_error() routine by removing the loop to check which 
status occured  (Uwe)
- Add open-drain property for SCL pins  (Uwe)
- Rework unneeded mul_ccr field from i2c_timing structure
- Remove min_ccr field from i2c_timing structure as default scl_period is chosen
  to have a correct minimal ccr value
- Execute hw_config once during probe
- Remove soft_reset after an I2C error as all errors are now handled and
  hw_config is done once during probe
- Generate STOP by software when Acknowledge failure occurs
- Set the max speed mode for I2C pins
- Add bias-disable property for I2C pins
- Use intrinsic limitation of APB bus to set I2C max input clk

M'boumba Cedric Madianga (5):
  dt-bindings: Document the STM32 I2C bindings
  i2c: Add STM32F4 I2C driver
  ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
  ARM: dts: stm32: Add I2C1 support for STM32429 eval board
  ARM: configs: stm32: Add I2C support for STM32 defconfig

 .../devicetree/bindings/i2c/i2c-stm32.txt  |  33 +
 arch/arm/boot/dts/stm32429i-eval.dts   |   6 +
 arch/arm/boot/dts/stm32f429.dtsi   |  23 +
 arch/arm/configs/stm32_defconfig   |   3 +
 drivers/i2c/busses/Kconfig |  10 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-stm32f4.c   | 866 +
 7 files changed, 942 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
 create mode 100644 drivers/i2c/busses/i2c-stm32f4.c

-- 
1.9.1



[PATCH v8 1/5] dt-bindings: Document the STM32 I2C bindings

2017-01-05 Thread M'boumba Cedric Madianga
This patch adds documentation of device tree bindings for the STM32 I2C
controller.

Signed-off-by: M'boumba Cedric Madianga 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/i2c/i2c-stm32.txt  | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt 
b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
new file mode 100644
index 000..78eaf7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
@@ -0,0 +1,33 @@
+* I2C controller embedded in STMicroelectronics STM32 I2C platform
+
+Required properties :
+- compatible : Must be "st,stm32f4-i2c"
+- reg : Offset and length of the register set for the device
+- interrupts : Must contain the interrupt id for I2C event and then the
+  interrupt id for I2C error.
+- resets: Must contain the phandle to the reset controller.
+- clocks: Must contain the input clock of the I2C instance.
+- A pinctrl state named "default" must be defined to set pins in mode of
+  operation for I2C transfer
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+  the default 100 kHz frequency will be used. As only Normal and Fast modes
+  are supported, possible values are 10 and 40.
+
+Example :
+
+   i2c@40005400 {
+   compatible = "st,stm32f4-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x40005400 0x400>;
+   interrupts = <31>,
+<32>;
+   resets = <&rcc 277>;
+   clocks = <&rcc 0 149>;
+   pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
+   pinctrl-names = "default";
+   };
-- 
1.9.1



[PATCH v8 2/5] i2c: Add STM32F4 I2C driver

2017-01-05 Thread M'boumba Cedric Madianga
This patch adds support for the STM32F4 I2C controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/i2c/busses/Kconfig   |  10 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-stm32f4.c | 866 +++
 3 files changed, 877 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 000..23e5757
--- /dev/null
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -0,0 +1,866 @@
+/*
+ * Driver for STMicroelectronics STM32 I2C controller
+ *
+ * This I2C controller is described in the STM32F429/439 Soc reference manual.
+ * Please see below a link to the documentation:
+ * http://www.st.com/resource/en/reference_manual/DM00031020.pdf
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2016
+ * Author: M'boumba Cedric Madianga 
+ *
+ * This driver is based on i2c-st.c
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* STM32F4 I2C offset registers */
+#define STM32F4_I2C_CR10x00
+#define STM32F4_I2C_CR20x04
+#define STM32F4_I2C_DR 0x10
+#define STM32F4_I2C_SR10x14
+#define STM32F4_I2C_SR20x18
+#define STM32F4_I2C_CCR0x1C
+#define STM32F4_I2C_TRISE  0x20
+#define STM32F4_I2C_FLTR   0x24
+
+/* STM32F4 I2C control 1*/
+#define STM32F4_I2C_CR1_POSBIT(11)
+#define STM32F4_I2C_CR1_ACKBIT(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)
+#define STM32F4_I2C_CR2_ITBUFENBIT(10)
+#define STM32F4_I2C_CR2_ITEVTENBIT(9)
+#define STM32F4_I2C_CR2_ITERRENBIT(8)
+#define STM32F4_I2C_CR2_IRQ_MASK   (STM32F4_I2C_CR2_ITBUFEN | \
+STM32F4_I2C_CR2_ITEVTEN | \
+STM32F4_I2C_CR2_ITERREN)
+
+/* 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_TXEBIT(7)
+#define STM32F4_I2C_SR1_RXNE   BIT(6)
+#define STM32F4_I2C_SR1_BTFBIT(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)
+#d

[PATCH v8 4/5] ARM: dts: stm32: Add I2C1 support for STM32429 eval board

2017-01-05 Thread M'boumba Cedric Madianga
This patch adds I2C1 instance support for STM32x9I-Eval board.

Signed-off-by: M'boumba Cedric Madianga 
---
 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 76f7206..c943539 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -146,3 +146,9 @@
pinctrl-names = "default";
status = "okay";
 };
+
+&i2c1 {
+   pinctrl-0 = <&i2c1_pins_b>;
+   pinctrl-names = "default";
+   status = "okay";
+};
-- 
1.9.1



[PATCH v8 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC

2017-01-05 Thread M'boumba Cedric Madianga
This patch adds I2C1 support for STM32F429 SoC

Signed-off-by: Patrice Chotard 
Signed-off-by: M'boumba Cedric Madianga 
---
 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 e4dae0e..5b063e9 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 
+#include 
 
 / {
clocks {
@@ -153,6 +154,18 @@
status = "disabled";
};
 
+   i2c1: i2c@40005400 {
+   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";
+   };
+
usart7: serial@40007800 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40007800 0x400>;
@@ -355,6 +368,16 @@
slew-rate = <2>;
};
};
+
+   i2c1_pins_b: i2c1@0 {
+   pins {
+   pinmux = ,
+;
+   bias-disable;
+   drive-open-drain;
+   slew-rate = <3>;
+   };
+   };
};
 
rcc: rcc@40023810 {
-- 
1.9.1



[PATCH v8 5/5] ARM: configs: stm32: Add I2C support for STM32 defconfig

2017-01-05 Thread M'boumba Cedric Madianga
This patch adds I2C support for STM32 default configuration

Signed-off-by: M'boumba Cedric Madianga 
---
 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 5a72d69..323d2a3 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -47,6 +47,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
-- 
1.9.1



[PATCH RESEND] dmaengine: stm32-dma: Add error messages if xlate fails

2017-01-05 Thread M'boumba Cedric Madianga
This patch adds some error messages when a slave device fails to request a
channel.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
---
Resolve conflicts issue
---
 drivers/dma/stm32-dma.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index fc9738e..4eacd9d 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -987,30 +987,36 @@ static struct dma_chan *stm32_dma_of_xlate(struct 
of_phandle_args *dma_spec,
   struct of_dma *ofdma)
 {
struct stm32_dma_device *dmadev = ofdma->of_dma_data;
+   struct device *dev = dmadev->ddev.dev;
struct stm32_dma_cfg cfg;
struct stm32_dma_chan *chan;
struct dma_chan *c;
 
-   if (dma_spec->args_count < 3)
+   if (dma_spec->args_count < 4) {
+   dev_err(dev, "Bad number of cells\n");
return NULL;
+   }
 
cfg.channel_id = dma_spec->args[0];
cfg.request_line = dma_spec->args[1];
cfg.stream_config = dma_spec->args[2];
-   cfg.threshold = 0;
+   cfg.threshold = dma_spec->args[3];
 
-   if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) || (cfg.request_line >=
-   STM32_DMA_MAX_REQUEST_ID))
+   if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) ||
+   (cfg.request_line >= STM32_DMA_MAX_REQUEST_ID)) {
+   dev_err(dev, "Bad channel and/or request id\n");
return NULL;
-
-   if (dma_spec->args_count > 3)
-   cfg.threshold = dma_spec->args[3];
+   }
 
chan = &dmadev->chan[cfg.channel_id];
 
c = dma_get_slave_channel(&chan->vchan.chan);
-   if (c)
-   stm32_dma_set_config(chan, &cfg);
+   if (!c) {
+   dev_err(dev, "No more channel avalaible\n");
+   return NULL;
+   }
+
+   stm32_dma_set_config(chan, &cfg);
 
return c;
 }
-- 
1.9.1



Re: [PATCH RESEND] dmaengine: stm32-dma: Rework starting transfer management

2017-01-03 Thread M'boumba Cedric Madianga
Hi Vinod,

> ah sorry, i missed to push topic/stm32-dma. can you rebase onnthis and
> resend again. Btw this fails as as well..
I have tried again and I don't have any issue.
Please see below my way of working and let me know if there is
something I don't understand:

slave-dma git://git.infradead.org/users/vkoul/slave-dma.git
$ git fetch slave-dma
$ git checkout -b dma-fixes slave-dma/topic/dma-fixes
$ git checkout -b dma-stm32 slave-dma/topic/stm32-dma
$ git rebase dma-fixes
First, rewinding head to replay your work on top of it...
Applying: dmaengine: stm32-dma: Fix typo in Kconfig
Applying: dt-bindings: stm32-dma: Fix typo regarding DMA client binding
Applying: dmaengine: stm32-dma: Rework starting transfer management
Applying: dmaengine: stm32-dma: Fix residue computation issue in cyclic mode
Applying: dmaengine: stm32-dma: Add synchronization support
Applying: dmaengine: stm32-dma: Add max_burst support

Best regards,

Cedric


Re: [PATCH v7 2/5] i2c: Add STM32F4 I2C driver

2017-01-02 Thread M'boumba Cedric Madianga
Hello Uwe,

>> Is it possible to make it more obvious by doing:
>>
>> status = read_from_status_register() & 
>> read_from_interrupt_enable_register();
>>
>> at a single place?
Contrary to what I said previously I have to keep possible_status
variable as for one irq enabled we allow several events.
For example, ITBUFEN allows to generate an irq for RXNE and for TXE events.
So, using status = read_from_status_register() &
read_from_interrupt_enable_register(); is not possible.

Best regards,

Cedric


[PATCH RESEND] dmaengine: stm32-dma: Rework starting transfer management

2017-01-02 Thread M'boumba Cedric Madianga
This patch reworks the way to manage transfer starting.
Now, starting DMA is only allowed when the channel is not busy.
Then, stm32_dma_start_transfer is declared as void.
At least, after each transfer completion, we start the next transfer if a
new descriptor as been queued in the issued list during an ongoing
transfer.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
---
 drivers/dma/stm32-dma.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 3056ce7..adb846c 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -421,7 +421,7 @@ static void stm32_dma_dump_reg(struct stm32_dma_chan *chan)
dev_dbg(chan2dev(chan), "SFCR:  0x%08x\n", sfcr);
 }
 
-static int stm32_dma_start_transfer(struct stm32_dma_chan *chan)
+static void stm32_dma_start_transfer(struct stm32_dma_chan *chan)
 {
struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
struct virt_dma_desc *vdesc;
@@ -432,12 +432,12 @@ static int stm32_dma_start_transfer(struct stm32_dma_chan 
*chan)
 
ret = stm32_dma_disable_chan(chan);
if (ret < 0)
-   return ret;
+   return;
 
if (!chan->desc) {
vdesc = vchan_next_desc(&chan->vchan);
if (!vdesc)
-   return -EPERM;
+   return;
 
chan->desc = to_stm32_dma_desc(vdesc);
chan->next_sg = 0;
@@ -471,7 +471,7 @@ static int stm32_dma_start_transfer(struct stm32_dma_chan 
*chan)
 
chan->busy = true;
 
-   return 0;
+   dev_dbg(chan2dev(chan), "vchan %p: started\n", &chan->vchan);
 }
 
 static void stm32_dma_configure_next_sg(struct stm32_dma_chan *chan)
@@ -552,15 +552,13 @@ static void stm32_dma_issue_pending(struct dma_chan *c)
 {
struct stm32_dma_chan *chan = to_stm32_dma_chan(c);
unsigned long flags;
-   int ret;
 
spin_lock_irqsave(&chan->vchan.lock, flags);
-   if (!chan->busy) {
-   if (vchan_issue_pending(&chan->vchan) && !chan->desc) {
-   ret = stm32_dma_start_transfer(chan);
-   if ((!ret) && (chan->desc->cyclic))
-   stm32_dma_configure_next_sg(chan);
-   }
+   if (vchan_issue_pending(&chan->vchan) && !chan->desc && !chan->busy) {
+   dev_dbg(chan2dev(chan), "vchan %p: issued\n", &chan->vchan);
+   stm32_dma_start_transfer(chan);
+   if (chan->desc->cyclic)
+   stm32_dma_configure_next_sg(chan);
}
spin_unlock_irqrestore(&chan->vchan.lock, flags);
 }
-- 
1.9.1



Re: [PATCH 0/9] dmaengine: stm32-dma: Bug fixes and improvements series

2017-01-02 Thread M'boumba Cedric Madianga
Hi Vinod,

> So you should order fixes first and then new additions.
> Fixes go in for current release whereas the rest for next one.
Ok thanks for the info.

> I have applied two to fixes and rest to updated, patch 5 didn't apply, please
> resend that one.
I have tried to apply patch 5 on top of slave-dma/fixes branch but I
don't have any issue.
So, I am going to resend this patch in order to be sure that there is no diff.

Best regards,

Cedric


Re: [PATCH v7 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC

2016-12-30 Thread M'boumba Cedric Madianga
 Hi Linus,

2016-12-30 10:07 GMT+01:00 Linus Walleij :
> On Fri, Dec 23, 2016 at 2:09 PM, M'boumba Cedric Madianga
>  wrote:
>> 2016-12-22 20:11 GMT+01:00 Uwe Kleine-König :
>>> On Thu, Dec 22, 2016 at 02:35:02PM +0100, M'boumba Cedric Madianga wrote:
>>>> @@ -337,6 +350,16 @@
>>>>   slew-rate = <2>;
>>>>   };
>>>>   };
>>>> +
>>>> + i2c1_pins_b: i2c1@0 {
>>>> + pins1 {
>>>> + pinmux = 
>>>> ;
>>>> + drive-open-drain;
>>>> + };
>>>> + pins2 {
>>>> + pinmux = 
>>>> ;
>>>> + };
>>>
>>> the second doesn't need the open-drain property? Why?
>>
>> I thought that open-drain was only needed for SDA line.
>> But after double-checking I2C specification, it seems that SDA and SCL
>> lines need open-drain or open-collector to perform the wired-AND
>> function.
>
> I think I2C SDA/SCL must be open drain by definition.
>
> It also requires pull-up resistors, I guess you have these mounted on the 
> board
> so you do not need pull-up from the pin controller?
Yes, I have 1 pull-up resistor of 1,5K ohm for each line (SDA & SCL)
on the board

>
> Yours,
> Linus Walleij


Re: [PATCH v7 2/5] i2c: Add STM32F4 I2C driver

2016-12-28 Thread M'boumba Cedric Madianga
Hello Uwe,

2016-12-28 22:21 GMT+01:00 Uwe Kleine-König :
> Hello Cedric,
>
> On Fri, Dec 23, 2016 at 01:41:15PM +0100, M'boumba Cedric Madianga wrote:
>> > I don't understand why DUTY is required to reach 400 kHz. Given a parent
>> > freq of 30 MHz, with CCR = 25 and DUTY = 0 we have:
>> >
>> > t_high = 25 * 33.333 ns = 833.333 ns
>> > t_low = 2 * 25 * 33.333 ns = 1666.667 ns
>> >
>> > then t_high and t_low satisfy the i2c bus specification
>> > (t_low > 1300 ns, t_high > 600 ns) and we have t_low + t_high = 2500 ns
>> > = 1 / 400 kHz.
>> >
>> > Where is the error?
>> Hum ok you are right. I was a bad interpretation of the datasheet.
>> So now it is clearer. Thanks for that.
>> I will correct and improve my comments in the V8.
>
> The benefit of DUTY=1 is (I think) that you can reach 400 kHz also with
> lower parent frequencies. And so it't probably sensible to make use of
> it unconditionally for fast mode.
Ok I agree.

>
>> >> + * So, in order to cover both SCL high/low with Duty = 1,
>> >> + * CCR = 16 * SCL period * I2C CLK frequency
>> >
>> > I don't get that. Actually you need to use low + high, so
>> > CCR = parentrate / (25 * 400 kHz), right?
>> With your new inputs above, I think I could use a simpler implementation:
>> CCR = scl_high_period * parent_rate
>> with scl_high_period = 5 µs in standard mode to reach 100khz
>> and scl_high_period = 1 µs in fast mode to reach 400khz with 1/2 or
>> 16/9 duty cycle.
>> So, I am wondering if I have to let the customer setting the duty
>> cycle in the DT for example with "st,duty=0" or "st,duty=1" property
>> (0 for 1/2 and 1 for 16/9).
>> Or perhaps the best option it to use a default value. What is your
>> feeling regarding this point ?
>
> No, don't add a property to the device tree. Just take pencil and paper
> and think a while about the right algorithm to choose the right register
> settings.
Ok thanks

>
>
>> >> + cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
>> >> + freq = cr2 & STM32F4_I2C_CR2_FREQ_MASK;
>> >> +
>> >> + if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD)
>> >> + trise = freq + 1;
>> >> + else
>> >> + trise = freq * 300 / 1000 + 1;
>> >
>> > if freq is big such that freq * 300 overflows does this result in a
>> > wrong result, or does the compiler optimize correctly?
>> For sure the compiler will never exceeds u32 max value
>
> If I compile
> >8
> #include 
>
> void myfunc(unsigned freq)
> {
> unsigned trise = freq * 300 / 1000 + 1;
> printf("trise = %u", trise);
> }
>
> >8
>
> for arm with -O3 I get:
>
>  :
>0:   e3a01f4bmov r1, #300; 0x12c
>4:   e0010190mul r1, r0, r1
>8:   e59f3010ldr r3, [pc, #16]   ; 20 
>c:   e59f0010ldr r0, [pc, #16]   ; 24 
>   10:   e0812193umull   r2, r1, r3, r1
>   14:   e1a01321lsr r1, r1, #6
>   18:   e2811001add r1, r1, #1
>   1c:   eafeb   0 
>   20:   10624dd3.word   0x10624dd3
>   24:   .word   0x
>
> The mul instruction at offset 4 writes the least significant 32 bits of
> 300 * r0 to r1 and so doesn't handle overflow correctly.
In case of overflow, the parent frequency has to be at least at 1431657 Mhz.
The STM32F4 SoC will never reach this value for any parent clock.
So, I think that this point is not really critical and you can
probably keep these simple lines of code without adding u32 overflow
checking for big frequency.

>
>> > This is still not really understandable.
>> I have already added some comments from datasheet to explain the
>> different cases.
>> I don't see how I could be more understandable as it is clearly the
>> hardware way of working...
>
> You need to comment the check for the length, something like:
>
> /*
>  * To end the transfer correctly the foo bit has to be cleared
>  * already on the last but one byte to be transferred.
>  */
>
OK I will add more comments.

> and bonus points if you can shrink the number of functions that check
> for this stuff.
There are only 2 functions to handle this stuff:  handle_read() for
RXNE event and handle_rx_btf() for BTF event
I would prefer to keep 2 seperate functions to handle each event
according to buffer length as I d

Re: [PATCH v7 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC

2016-12-23 Thread M'boumba Cedric Madianga
Hi,


2016-12-22 20:11 GMT+01:00 Uwe Kleine-König :
> Hello,
>
> On Thu, Dec 22, 2016 at 02:35:02PM +0100, M'boumba Cedric Madianga wrote:
>> @@ -337,6 +350,16 @@
>>   slew-rate = <2>;
>>   };
>>   };
>> +
>> + i2c1_pins_b: i2c1@0 {
>> + pins1 {
>> + pinmux = ;
>> + drive-open-drain;
>> + };
>> + pins2 {
>> + pinmux = ;
>> + };
>
> the second doesn't need the open-drain property? Why?
I thought that open-drain was only needed for SDA line.
But after double-checking I2C specification, it seems that SDA and SCL
lines need open-drain or open-collector to perform the wired-AND
function.
I will do some trials with this config and will fix it in the V8.
Thanks

>
>> + };
>>   };
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.   | Uwe Kleine-König|
> Industrial Linux Solutions | http://www.pengutronix.de/  |


Re: [PATCH v7 2/5] i2c: Add STM32F4 I2C driver

2016-12-23 Thread M'boumba Cedric Madianga
Hi Uwe,

Thanks for your comments.
Please see below my answers and one question regarding duty cycle:

2016-12-23 10:00 GMT+01:00 Uwe Kleine-König :
> Hello,
>
> On Thu, Dec 22, 2016 at 02:35:01PM +0100, M'boumba Cedric Madianga wrote:
>> This patch adds support for the STM32F4 I2C controller.
>>
>> Signed-off-by: M'boumba Cedric Madianga 
>> ---
>>  drivers/i2c/busses/Kconfig   |  10 +
>>  drivers/i2c/busses/Makefile  |   1 +
>>  drivers/i2c/busses/i2c-stm32f4.c | 896 
>> +++
>>  3 files changed, 907 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 000..ca11dee
>> --- /dev/null
>> +++ b/drivers/i2c/busses/i2c-stm32f4.c
>> @@ -0,0 +1,896 @@
>> +/*
>> + * Driver for STMicroelectronics STM32 I2C controller
>> + *
>> + * This I2C controller is described in the STM32F429/439 Soc reference 
>> manual.
>> + * Please see below a link to the documentation:
>> + * http://www.st.com/resource/en/reference_manual/DM00031020.pdf
>> + *
>> + * Copyright (C) M'boumba Cedric Madianga 2016
>> + * Author: M'boumba Cedric Madianga 
>> + *
>> + * This driver is based on i2c-st.c
>> + *
>> + * License terms:  GNU General Public License (GPL), version 2
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* 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_TRISE0x20
>> +#define STM32F4_I2C_FLTR 0x24
>> +
>> +/* STM32F4 I2C control 1*/
>> +#define STM32F4_I2C_CR1_SWRSTBIT(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_STARTBIT(8)
>> +#define STM32F4_I2C_CR1_PE   BIT(0)
>> +
>> +/* STM32F4 I2C control 2 */
>> +#define STM32F4_I2C_CR2_FREQ_MASKGENMASK(5, 0)
>> +#define STM32F4_I2C_CR2_FREQ(n)  (((n) & 
>> STM32F4_I2C_CR2_FREQ_MASK))
>
> ((n) & STM32F4_I2C_CR2_FREQ_MASK)
>
> should be enough.
You are right. I will fix it in the V8.

>
>> +#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 (

[PATCH v7 2/5] i2c: Add STM32F4 I2C driver

2016-12-22 Thread M'boumba Cedric Madianga
This patch adds support for the STM32F4 I2C controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/i2c/busses/Kconfig   |  10 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-stm32f4.c | 896 +++
 3 files changed, 907 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 000..ca11dee
--- /dev/null
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -0,0 +1,896 @@
+/*
+ * Driver for STMicroelectronics STM32 I2C controller
+ *
+ * This I2C controller is described in the STM32F429/439 Soc reference manual.
+ * Please see below a link to the documentation:
+ * http://www.st.com/resource/en/reference_manual/DM00031020.pdf
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2016
+ * Author: M'boumba Cedric Madianga 
+ *
+ * This driver is based on i2c-st.c
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* STM32F4 I2C offset registers */
+#define STM32F4_I2C_CR10x00
+#define STM32F4_I2C_CR20x04
+#define STM32F4_I2C_DR 0x10
+#define STM32F4_I2C_SR10x14
+#define STM32F4_I2C_SR20x18
+#define STM32F4_I2C_CCR0x1C
+#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_POSBIT(11)
+#define STM32F4_I2C_CR1_ACKBIT(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))
+#define STM32F4_I2C_CR2_ITBUFENBIT(10)
+#define STM32F4_I2C_CR2_ITEVTENBIT(9)
+#define STM32F4_I2C_CR2_ITERRENBIT(8)
+#define STM32F4_I2C_CR2_IRQ_MASK   (STM32F4_I2C_CR2_ITBUFEN | \
+STM32F4_I2C_CR2_ITEVTEN | \
+STM32F4_I2C_CR2_ITERREN)
+
+/* 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_TXEBIT(7)
+#define STM32F4_I2C_SR1_RXNE   BIT(6)
+#define STM32F4_I2C_SR1_BTFBIT(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))

[PATCH v7 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC

2016-12-22 Thread M'boumba Cedric Madianga
This patch adds I2C1 support for STM32F429 SoC

Signed-off-by: Patrice Chotard 
Signed-off-by: M'boumba Cedric Madianga 
---
 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..2277a2d 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 
+#include 
 
 / {
clocks {
@@ -140,6 +141,18 @@
status = "disabled";
};
 
+   i2c1: i2c@40005400 {
+   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";
+   };
+
usart7: serial@40007800 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40007800 0x400>;
@@ -337,6 +350,16 @@
slew-rate = <2>;
};
};
+
+   i2c1_pins_b: i2c1@0 {
+   pins1 {
+   pinmux = ;
+   drive-open-drain;
+   };
+   pins2 {
+   pinmux = ;
+   };
+   };
};
 
rcc: rcc@40023810 {
-- 
1.9.1



[PATCH v7 1/5] dt-bindings: Document the STM32 I2C bindings

2016-12-22 Thread M'boumba Cedric Madianga
This patch adds documentation of device tree bindings for the STM32 I2C
controller.

Signed-off-by: M'boumba Cedric Madianga 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/i2c/i2c-stm32.txt  | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt 
b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
new file mode 100644
index 000..78eaf7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
@@ -0,0 +1,33 @@
+* I2C controller embedded in STMicroelectronics STM32 I2C platform
+
+Required properties :
+- compatible : Must be "st,stm32f4-i2c"
+- reg : Offset and length of the register set for the device
+- interrupts : Must contain the interrupt id for I2C event and then the
+  interrupt id for I2C error.
+- resets: Must contain the phandle to the reset controller.
+- clocks: Must contain the input clock of the I2C instance.
+- A pinctrl state named "default" must be defined to set pins in mode of
+  operation for I2C transfer
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+  the default 100 kHz frequency will be used. As only Normal and Fast modes
+  are supported, possible values are 10 and 40.
+
+Example :
+
+   i2c@40005400 {
+   compatible = "st,stm32f4-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x40005400 0x400>;
+   interrupts = <31>,
+<32>;
+   resets = <&rcc 277>;
+   clocks = <&rcc 0 149>;
+   pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
+   pinctrl-names = "default";
+   };
-- 
1.9.1



[PATCH v7 4/5] ARM: dts: stm32: Add I2C1 support for STM32429 eval board

2016-12-22 Thread M'boumba Cedric Madianga
This patch adds I2C1 instance support for STM32x9I-Eval board.

Signed-off-by: M'boumba Cedric Madianga 
---
 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";
+};
-- 
1.9.1



[PATCH v7 5/5] ARM: configs: stm32: Add I2C support for STM32 defconfig

2016-12-22 Thread M'boumba Cedric Madianga
This patch adds I2C support for STM32 default configuration

Signed-off-by: M'boumba Cedric Madianga 
---
 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
-- 
1.9.1



[PATCH v7 0/5] Add support for the STM32F4 I2C

2016-12-22 Thread M'boumba Cedric Madianga
This patchset adds support for the I2C controller embedded in STM32F4xx SoC.
It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus
speed.

Changes since v6:
- Add commit message for the patches in defconfig, .dtsi and .dts files (Alex)
- Order I2C instance base address in .dtsi file (Alex)
- Add commit message for the patch in stm32429i-eval.dts  (Alex)
- Add link to the STM32F4 Soc ref manual where I2C device is described (Uwe)
- Use more usal way to define constants with several lines (Uwe)
- Remove rate variable from stm32f4_i2c_timings as it is not used (Uwe)
- Remove irq variable from stm32f4_i2c_dev struct are they are only needed
  during probe (Uwe)
- Add comment from datasheet to explain stm32f4_i2c_timings values (Uwe)
- Rework i2c soft_reset implementation (Uwe)
- Replace "it" by "irq" as it is a more usual abbreviation for interrupt (Uwe)
- Add comment from datasheet to explain periph clk freq calculation (Uwe)
- Use DIV_ROUND_UP instead of plain division when required (Uwe)
- Add comment from datasheet to explain timing rise calculation (Uwe)
- Rework timing rise calculation by using shorter computation (Uwe)
- Remove (u8) cast when reading I2C data register (Uwe)
- Rework isr_event routine to handle several events during one call of the
  routine (Uwe)
- Precise which type of irq is failed when a irq request error occurs (Uwe)
- Use devm_request_irq() instead of devm_request_threaded_irq() to avoid
  spurious evt irq when clearing status registers in threaded context

M'boumba Cedric Madianga (5):
  dt-bindings: Document the STM32 I2C bindings
  i2c: Add STM32F4 I2C driver
  ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
  ARM: dts: stm32: Add I2C1 support for STM32429 eval board
  ARM: configs: stm32: Add I2C support for STM32 defconfig

 .../devicetree/bindings/i2c/i2c-stm32.txt  |  33 +
 arch/arm/boot/dts/stm32429i-eval.dts   |   6 +
 arch/arm/boot/dts/stm32f429.dtsi   |  23 +
 arch/arm/configs/stm32_defconfig   |   3 +
 drivers/i2c/busses/Kconfig |  10 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-stm32f4.c   | 896 +
 7 files changed, 972 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
 create mode 100644 drivers/i2c/busses/i2c-stm32f4.c

-- 
1.9.1



Re: [PATCH v6 2/5] i2c: Add STM32F4 I2C driver

2016-12-15 Thread M'boumba Cedric Madianga
Hello,

Thanks for this review, it will help.

2016-12-13 10:20 GMT+01:00 Uwe Kleine-König :
> 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 
>> ---
>>  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 000..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 
>> + *
>> + * 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.
The device is described in the reference manual of the STM32F429/439 SoC.
As this reference manual is public, I will add it at the beginning of
the driver as requested.

>
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* 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_TRISE0x20
>> +#define STM32F4_I2C_FLTR 0x24
>> +
>> +/* STM32F4 I2C control 1*/
>> +#define STM32F4_I2C_CR1_SWRSTBIT(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_STARTBIT(8)
>> +#define STM32F4_I2C_CR1_PE   BIT(0)
>> +
>> +/* STM32F4 I2C control 2 */
>> +#define STM32F4_I2C_CR2_FREQ_MASKGENMASK(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.
OK I will fix it in the V7. Thanks.

>
>> +#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

[PATCH 4/9] dmaengine: stm32-dma: Fix null pointer dereference in stm32_dma_tx_status

2016-12-13 Thread M'boumba Cedric Madianga
chan->desc is always set to NULL when a DMA transfer is complete.
As a DMA transfer could be complete during the call of stm32_dma_tx_status,
we need to be sure that chan->desc is not NULL before using this variable
to avoid a null pointer deference issue.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
---
 drivers/dma/stm32-dma.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index a884b85..3056ce7 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -880,7 +880,7 @@ static enum dma_status stm32_dma_tx_status(struct dma_chan 
*c,
struct virt_dma_desc *vdesc;
enum dma_status status;
unsigned long flags;
-   u32 residue;
+   u32 residue = 0;
 
status = dma_cookie_status(c, cookie, state);
if ((status == DMA_COMPLETE) || (!state))
@@ -888,16 +888,12 @@ static enum dma_status stm32_dma_tx_status(struct 
dma_chan *c,
 
spin_lock_irqsave(&chan->vchan.lock, flags);
vdesc = vchan_find_desc(&chan->vchan, cookie);
-   if (cookie == chan->desc->vdesc.tx.cookie) {
+   if (chan->desc && cookie == chan->desc->vdesc.tx.cookie)
residue = stm32_dma_desc_residue(chan, chan->desc,
 chan->next_sg);
-   } else if (vdesc) {
+   else if (vdesc)
residue = stm32_dma_desc_residue(chan,
 to_stm32_dma_desc(vdesc), 0);
-   } else {
-   residue = 0;
-   }
-
dma_set_residue(state, residue);
 
spin_unlock_irqrestore(&chan->vchan.lock, flags);
-- 
1.9.1



[PATCH 8/9] dmaengine: stm32-dma: Add synchronization support

2016-12-13 Thread M'boumba Cedric Madianga
Implement the new device_synchronize() callback to allow proper
synchronization when stopping a channel.

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/dma/stm32-dma.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 35639f6..b7be43a 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -403,6 +403,13 @@ static int stm32_dma_terminate_all(struct dma_chan *c)
return 0;
 }
 
+static void stm32_dma_synchronize(struct dma_chan *c)
+{
+   struct stm32_dma_chan *chan = to_stm32_dma_chan(c);
+
+   vchan_synchronize(&chan->vchan);
+}
+
 static void stm32_dma_dump_reg(struct stm32_dma_chan *chan)
 {
struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
@@ -1068,6 +1075,7 @@ static int stm32_dma_probe(struct platform_device *pdev)
dd->device_prep_dma_cyclic = stm32_dma_prep_dma_cyclic;
dd->device_config = stm32_dma_slave_config;
dd->device_terminate_all = stm32_dma_terminate_all;
+   dd->device_synchronize = stm32_dma_synchronize;
dd->src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
-- 
1.9.1



[PATCH 1/9] dmaengine: stm32-dma: Set correct args number for DMA request from DT

2016-12-13 Thread M'boumba Cedric Madianga
This patch sets the right number of arguments to be used for DMA clients
which request channels from DT.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
---
 drivers/dma/stm32-dma.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 3688d08..a884b85 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -972,21 +972,18 @@ static struct dma_chan *stm32_dma_of_xlate(struct 
of_phandle_args *dma_spec,
struct stm32_dma_chan *chan;
struct dma_chan *c;
 
-   if (dma_spec->args_count < 3)
+   if (dma_spec->args_count < 4)
return NULL;
 
cfg.channel_id = dma_spec->args[0];
cfg.request_line = dma_spec->args[1];
cfg.stream_config = dma_spec->args[2];
-   cfg.threshold = 0;
+   cfg.threshold = dma_spec->args[3];
 
if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) || (cfg.request_line >=
STM32_DMA_MAX_REQUEST_ID))
return NULL;
 
-   if (dma_spec->args_count > 3)
-   cfg.threshold = dma_spec->args[3];
-
chan = &dmadev->chan[cfg.channel_id];
 
c = dma_get_slave_channel(&chan->vchan.chan);
-- 
1.9.1



[PATCH 5/9] dmaengine: stm32-dma: Rework starting transfer management

2016-12-13 Thread M'boumba Cedric Madianga
This patch reworks the way to manage transfer starting.
Now, starting DMA is only allowed when the channel is not busy.
Then, stm32_dma_start_transfer is declared as void.
At least, after each transfer completion, we start the next transfer if a
new descriptor as been queued in the issued list during an ongoing
transfer.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
---
 drivers/dma/stm32-dma.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 3056ce7..adb846c 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -421,7 +421,7 @@ static void stm32_dma_dump_reg(struct stm32_dma_chan *chan)
dev_dbg(chan2dev(chan), "SFCR:  0x%08x\n", sfcr);
 }
 
-static int stm32_dma_start_transfer(struct stm32_dma_chan *chan)
+static void stm32_dma_start_transfer(struct stm32_dma_chan *chan)
 {
struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
struct virt_dma_desc *vdesc;
@@ -432,12 +432,12 @@ static int stm32_dma_start_transfer(struct stm32_dma_chan 
*chan)
 
ret = stm32_dma_disable_chan(chan);
if (ret < 0)
-   return ret;
+   return;
 
if (!chan->desc) {
vdesc = vchan_next_desc(&chan->vchan);
if (!vdesc)
-   return -EPERM;
+   return;
 
chan->desc = to_stm32_dma_desc(vdesc);
chan->next_sg = 0;
@@ -471,7 +471,7 @@ static int stm32_dma_start_transfer(struct stm32_dma_chan 
*chan)
 
chan->busy = true;
 
-   return 0;
+   dev_dbg(chan2dev(chan), "vchan %p: started\n", &chan->vchan);
 }
 
 static void stm32_dma_configure_next_sg(struct stm32_dma_chan *chan)
@@ -552,15 +552,13 @@ static void stm32_dma_issue_pending(struct dma_chan *c)
 {
struct stm32_dma_chan *chan = to_stm32_dma_chan(c);
unsigned long flags;
-   int ret;
 
spin_lock_irqsave(&chan->vchan.lock, flags);
-   if (!chan->busy) {
-   if (vchan_issue_pending(&chan->vchan) && !chan->desc) {
-   ret = stm32_dma_start_transfer(chan);
-   if ((!ret) && (chan->desc->cyclic))
-   stm32_dma_configure_next_sg(chan);
-   }
+   if (vchan_issue_pending(&chan->vchan) && !chan->desc && !chan->busy) {
+   dev_dbg(chan2dev(chan), "vchan %p: issued\n", &chan->vchan);
+   stm32_dma_start_transfer(chan);
+   if (chan->desc->cyclic)
+   stm32_dma_configure_next_sg(chan);
}
spin_unlock_irqrestore(&chan->vchan.lock, flags);
 }
-- 
1.9.1



[PATCH 6/9] dmaengine: stm32-dma: Fix residue computation issue in cyclic mode

2016-12-13 Thread M'boumba Cedric Madianga
This patch resolves the residue computation issue detected in cyclic mode.
Now, in cyclic mode, we increment next_sg variable as soon as a period is
transferred instead of after pushing a new sg request.
Then, we take into account that after transferring a complete buffer,
the next_sg variable is equal to 0.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
---
 drivers/dma/stm32-dma.c | 39 ++-
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index adb846c..ba929a9 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -500,8 +500,6 @@ static void stm32_dma_configure_next_sg(struct 
stm32_dma_chan *chan)
dev_dbg(chan2dev(chan), "CT=0 <=> SM1AR: 0x%08x\n",
stm32_dma_read(dmadev, STM32_DMA_SM1AR(id)));
}
-
-   chan->next_sg++;
}
 }
 
@@ -510,6 +508,7 @@ static void stm32_dma_handle_chan_done(struct 
stm32_dma_chan *chan)
if (chan->desc) {
if (chan->desc->cyclic) {
vchan_cyclic_callback(&chan->desc->vdesc);
+   chan->next_sg++;
stm32_dma_configure_next_sg(chan);
} else {
chan->busy = false;
@@ -846,26 +845,40 @@ static struct dma_async_tx_descriptor 
*stm32_dma_prep_dma_memcpy(
return vchan_tx_prep(&chan->vchan, &desc->vdesc, flags);
 }
 
+static u32 stm32_dma_get_remaining_bytes(struct stm32_dma_chan *chan)
+{
+   u32 dma_scr, width, ndtr;
+   struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
+
+   dma_scr = stm32_dma_read(dmadev, STM32_DMA_SCR(chan->id));
+   width = STM32_DMA_SCR_PSIZE_GET(dma_scr);
+   ndtr = stm32_dma_read(dmadev, STM32_DMA_SNDTR(chan->id));
+
+   return ndtr << width;
+}
+
 static size_t stm32_dma_desc_residue(struct stm32_dma_chan *chan,
 struct stm32_dma_desc *desc,
 u32 next_sg)
 {
-   struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
-   u32 dma_scr, width, residue, count;
+   u32 residue = 0;
int i;
 
-   residue = 0;
+   /*
+* In cyclic mode, for the last period, residue = remaining bytes from
+* NDTR
+*/
+   if (chan->desc->cyclic && next_sg == 0)
+   return stm32_dma_get_remaining_bytes(chan);
 
+   /*
+* For all other periods in cyclic mode, and in sg mode,
+* residue = remaining bytes from NDTR + remaining periods/sg to be
+* transferred
+*/
for (i = next_sg; i < desc->num_sgs; i++)
residue += desc->sg_req[i].len;
-
-   if (next_sg != 0) {
-   dma_scr = stm32_dma_read(dmadev, STM32_DMA_SCR(chan->id));
-   width = STM32_DMA_SCR_PSIZE_GET(dma_scr);
-   count = stm32_dma_read(dmadev, STM32_DMA_SNDTR(chan->id));
-
-   residue += count << width;
-   }
+   residue += stm32_dma_get_remaining_bytes(chan);
 
return residue;
 }
-- 
1.9.1



[PATCH 2/9] dmaengine: stm32-dma: Fix typo in Kconfig

2016-12-13 Thread M'boumba Cedric Madianga
As STM32 DMA driver is only used as buit-in driver, it couldn't be used as
module.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
---
 drivers/dma/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 263495d..96da57a 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -458,7 +458,7 @@ config STM32_DMA
help
  Enable support for the on-chip DMA controller on STMicroelectronics
  STM32 MCUs.
- If you have a board based on such a MCU and wish to use DMA say Y or M
+ If you have a board based on such a MCU and wish to use DMA say Y
  here.
 
 config S3C24XX_DMAC
-- 
1.9.1



[PATCH 3/9] dt-bindings: stm32-dma: Fix typo regarding DMA client binding

2016-12-13 Thread M'boumba Cedric Madianga
Only four cells are required for dma client binding not five.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
---
 Documentation/devicetree/bindings/dma/stm32-dma.txt | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/stm32-dma.txt 
b/Documentation/devicetree/bindings/dma/stm32-dma.txt
index 70cd13f..4408af6 100644
--- a/Documentation/devicetree/bindings/dma/stm32-dma.txt
+++ b/Documentation/devicetree/bindings/dma/stm32-dma.txt
@@ -40,8 +40,7 @@ Example:
 
 DMA clients connected to the STM32 DMA controller must use the format
 described in the dma.txt file, using a five-cell specifier for each
-channel: a phandle plus four integer cells.
-The four cells in order are:
+channel: a phandle to the DMA controller plus the following four integer cells:
 
 1. The channel id
 2. The request line number
@@ -61,7 +60,7 @@ The four cells in order are:
0x1: medium
0x2: high
0x3: very high
-5. A 32bit mask specifying the DMA FIFO threshold configuration which are 
device
+4. A 32bit mask specifying the DMA FIFO threshold configuration which are 
device
dependent:
  -bit 0-1: Fifo threshold
0x0: 1/4 full FIFO
-- 
1.9.1



[PATCH 7/9] dmaengine: stm32-dma: Add error messages if xlate fails

2016-12-13 Thread M'boumba Cedric Madianga
This patch adds some error messages when a slave device fails to request a
channel.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
---
 drivers/dma/stm32-dma.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index ba929a9..35639f6 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -975,27 +975,36 @@ static struct dma_chan *stm32_dma_of_xlate(struct 
of_phandle_args *dma_spec,
   struct of_dma *ofdma)
 {
struct stm32_dma_device *dmadev = ofdma->of_dma_data;
+   struct device *dev = dmadev->ddev.dev;
struct stm32_dma_cfg cfg;
struct stm32_dma_chan *chan;
struct dma_chan *c;
 
-   if (dma_spec->args_count < 4)
+   if (dma_spec->args_count < 4) {
+   dev_err(dev, "Bad number of cells\n");
return NULL;
+   }
 
cfg.channel_id = dma_spec->args[0];
cfg.request_line = dma_spec->args[1];
cfg.stream_config = dma_spec->args[2];
cfg.threshold = dma_spec->args[3];
 
-   if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) || (cfg.request_line >=
-   STM32_DMA_MAX_REQUEST_ID))
+   if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) ||
+   (cfg.request_line >= STM32_DMA_MAX_REQUEST_ID)) {
+   dev_err(dev, "Bad channel and/or request id\n");
return NULL;
+   }
 
chan = &dmadev->chan[cfg.channel_id];
 
c = dma_get_slave_channel(&chan->vchan.chan);
-   if (c)
-   stm32_dma_set_config(chan, &cfg);
+   if (!c) {
+   dev_err(dev, "No more channel avalaible\n");
+   return NULL;
+   }
+
+   stm32_dma_set_config(chan, &cfg);
 
return c;
 }
-- 
1.9.1



[PATCH 9/9] dmaengine: stm32-dma: Add max_burst support

2016-12-13 Thread M'boumba Cedric Madianga
This patch sets the max_burst value supported by the STM32 DMA

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/dma/stm32-dma.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index b7be43a..49f86ca 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -114,6 +114,7 @@
 #define STM32_DMA_MAX_CHANNELS 0x08
 #define STM32_DMA_MAX_REQUEST_ID   0x08
 #define STM32_DMA_MAX_DATA_PARAM   0x03
+#define STM32_DMA_MAX_BURST16
 
 enum stm32_dma_width {
STM32_DMA_BYTE,
@@ -1084,6 +1085,7 @@ static int stm32_dma_probe(struct platform_device *pdev)
BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
dd->directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
dd->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+   dd->max_burst = STM32_DMA_MAX_BURST;
dd->dev = &pdev->dev;
INIT_LIST_HEAD(&dd->channels);
 
-- 
1.9.1



[PATCH 0/9] dmaengine: stm32-dma: Bug fixes and improvements series

2016-12-13 Thread M'boumba Cedric Madianga
This patchset adds bug fixes reported by devices using STM32 DMA and some
improvements mainly linked to dmaengine framework evolution.

M'boumba Cedric Madianga (9):
  dmaengine: stm32-dma: Set correct args number for DMA request from DT
  dmaengine: stm32-dma: Fix typo in Kconfig
  dt-bindings: stm32-dma: Fix typo regarding DMA client binding
  dmaengine: stm32-dma: Fix null pointer dereference in stm32_dma_tx_status
  dmaengine: stm32-dma: Rework starting transfer management
  dmaengine: stm32-dma: Fix residue computation issue in cyclic mode
  dmaengine: stm32-dma: Add error messages if xlate fails
  dmaengine: stm32-dma: Add synchronization support
  dmaengine: stm32-dma: Add max_burst support

 .../devicetree/bindings/dma/stm32-dma.txt  |   5 +-
 drivers/dma/Kconfig|   2 +-
 drivers/dma/stm32-dma.c| 103 +
 3 files changed, 66 insertions(+), 44 deletions(-)

-- 
1.9.1



[PATCH v6 1/5] dt-bindings: Document the STM32 I2C bindings

2016-12-12 Thread M'boumba Cedric Madianga
This patch adds documentation of device tree bindings for the STM32 I2C
controller.

Signed-off-by: M'boumba Cedric Madianga 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/i2c/i2c-stm32.txt  | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt 
b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
new file mode 100644
index 000..78eaf7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
@@ -0,0 +1,33 @@
+* I2C controller embedded in STMicroelectronics STM32 I2C platform
+
+Required properties :
+- compatible : Must be "st,stm32f4-i2c"
+- reg : Offset and length of the register set for the device
+- interrupts : Must contain the interrupt id for I2C event and then the
+  interrupt id for I2C error.
+- resets: Must contain the phandle to the reset controller.
+- clocks: Must contain the input clock of the I2C instance.
+- A pinctrl state named "default" must be defined to set pins in mode of
+  operation for I2C transfer
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+  the default 100 kHz frequency will be used. As only Normal and Fast modes
+  are supported, possible values are 10 and 40.
+
+Example :
+
+   i2c@40005400 {
+   compatible = "st,stm32f4-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x40005400 0x400>;
+   interrupts = <31>,
+<32>;
+   resets = <&rcc 277>;
+   clocks = <&rcc 0 149>;
+   pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
+   pinctrl-names = "default";
+   };
-- 
1.9.1



[PATCH v6 5/5] ARM: configs: stm32: Add I2C support for STM32 defconfig

2016-12-12 Thread M'boumba Cedric Madianga
Signed-off-by: M'boumba Cedric Madianga 
---
 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
-- 
1.9.1



[PATCH v6 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC

2016-12-12 Thread M'boumba Cedric Madianga
Signed-off-by: Patrice Chotard 
Signed-off-by: M'boumba Cedric Madianga 
---
 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 
+#include 
 
 / {
clocks {
@@ -337,6 +338,16 @@
slew-rate = <2>;
};
};
+
+   i2c1_pins_b: i2c1@0 {
+   pins1 {
+   pinmux = ;
+   drive-open-drain;
+   };
+   pins2 {
+   pinmux = ;
+   };
+   };
};
 
rcc: rcc@40023810 {
@@ -409,6 +420,18 @@
interrupts = <80>;
clocks = <&rcc 0 38>;
};
+
+   i2c1: i2c@40005400 {
+   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";
+   };
};
 };
 
-- 
1.9.1



[PATCH v6 4/5] ARM: dts: stm32: Add I2C1 support for STM32429 eval board

2016-12-12 Thread M'boumba Cedric Madianga
Signed-off-by: M'boumba Cedric Madianga 
---
 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";
+};
-- 
1.9.1



[PATCH v6 2/5] i2c: Add STM32F4 I2C driver

2016-12-12 Thread M'boumba Cedric Madianga
This patch adds support for the STM32F4 I2C controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 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 000..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 
+ *
+ * This driver is based on i2c-st.c
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* STM32F4 I2C offset registers */
+#define STM32F4_I2C_CR10x00
+#define STM32F4_I2C_CR20x04
+#define STM32F4_I2C_DR 0x10
+#define STM32F4_I2C_SR10x14
+#define STM32F4_I2C_SR20x18
+#define STM32F4_I2C_CCR0x1C
+#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_POSBIT(11)
+#define STM32F4_I2C_CR1_ACKBIT(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))
+#define STM32F4_I2C_CR2_ITBUFENBIT(10)
+#define STM32F4_I2C_CR2_ITEVTENBIT(9)
+#define STM32F4_I2C_CR2_ITERRENBIT(8)
+#define STM32F4_I2C_CR2_IRQ_MASK   (STM32F4_I2C_CR2_ITBUFEN \
+   | STM32F4_I2C_CR2_ITEVTEN \
+   | STM32F4_I2C_CR2_ITERREN)
+
+/* 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_TXEBIT(7)
+#define STM32F4_I2C_SR1_RXNE   BIT(6)
+#define STM32F4_I2C_SR1_BTFBIT(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_VALU

[PATCH v6 0/5] Add support for the STM32F4 I2C

2016-12-12 Thread M'boumba Cedric Madianga
This patchset adds support for the I2C controller embedded in STM32F4xx SoC.
It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus
speed.

Changes since v5:
- Change commit header from "ARM: dts:" to "ARM: dts: stm32:" (Alex)
- Change commit header from "ARM: configs:" to "ARM: configs: stm32:" (Alex)
- Fix warnings due to variable set but unused (Wolfram)
- Remove double space in Kconfig (Wolfram)
- Fix warning due to bad type parameter when using clamp() function
  (build-bot)

M'boumba Cedric Madianga (5):
  dt-bindings: Document the STM32 I2C bindings
  i2c: Add STM32F4 I2C driver
  ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
  ARM: dts: stm32: Add I2C1 support for STM32429 eval board
  ARM: configs: stm32: Add I2C support for STM32 defconfig

 .../devicetree/bindings/i2c/i2c-stm32.txt  |  33 +
 arch/arm/boot/dts/stm32429i-eval.dts   |   6 +
 arch/arm/boot/dts/stm32f429.dtsi   |  23 +
 arch/arm/configs/stm32_defconfig   |   3 +
 drivers/i2c/busses/Kconfig |  10 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-stm32f4.c   | 849 +
 7 files changed, 925 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
 create mode 100644 drivers/i2c/busses/i2c-stm32f4.c

-- 
1.9.1



Re: [PATCH v5 2/5] i2c: Add STM32F4 I2C driver

2016-12-12 Thread M'boumba Cedric Madianga
Hi Wolfram,

Thanks for your comments.
I will fix all of them + build errors reported by build-bot in the V6.

Best regards,

Cedric Madianga

2016-12-11 22:42 GMT+01:00 Wolfram Sang :
> Hi,
>
>> +config I2C_STM32F4
>> + tristate "STMicroelectronics STM32F4 I2C support"
>> + depends on ARCH_STM32  || COMPILE_TEST
>
> Double space.
>
>> +#define STM32F4_I2C_MIN_FREQ 2
>> +#define STM32F4_I2C_MAX_FREQ 42
>
> Those two must be unsigned to fix the build error (e.g. 2U) reported by
> build-bot.
>
> Also, I get the following build warnings:
>
>   CC  drivers/i2c/busses/i2c-stm32f4.o
> drivers/i2c/busses/i2c-stm32f4.c: In function ‘stm32f4_i2c_handle_rx_addr’:
> drivers/i2c/busses/i2c-stm32f4.c:445:6: warning: variable ‘sr2’ set but not 
> used [-Wunused-but-set-variable]
>   u32 sr2;
>   ^~~
> drivers/i2c/busses/i2c-stm32f4.c: In function ‘stm32f4_i2c_isr_event’:
> drivers/i2c/busses/i2c-stm32f4.c:496:41: warning: variable ‘sr2’ set but not 
> used [-Wunused-but-set-variable]
>   u32 real_status, possible_status, ien, sr2;
>
> I assume those are reads to clear the register, so we really don't need
> to save the value in a variable.
>
> Rest is looking good.
>
> Thanks,
>
>Wolfram
>


Re: [PATCH v5 4/5] ARM: dts: Add I2C1 support for STM32429 eval board

2016-12-08 Thread M'boumba Cedric Madianga
Hi Alex,


2016-12-08 9:39 GMT+01:00 Alexandre Torgue :
> Hi Cedric,
>
> On 12/08/2016 09:26 AM, M'boumba Cedric Madianga wrote:
>>
>> Signed-off-by: M'boumba Cedric Madianga 
>> ---
>>  arch/arm/boot/dts/stm32429i-eval.dts | 6 ++
>>  1 file changed, 6 insertions(+)
>>
> Can you change the commit header by: ARM: dts: stm32: Add I2C1 support for
> STM32429 eval board
Ok, I will use this typo in the next version

>
> thx
> Alex
>
>
>> 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";
>> +};
>>
>


Re: [PATCH v5 5/5] ARM: configs: Add I2C support for STM32 defconfig

2016-12-08 Thread M'boumba Cedric Madianga
Hi Alex,

2016-12-08 9:38 GMT+01:00 Alexandre Torgue :
> Hi Cedric,
>
> On 12/08/2016 09:26 AM, M'boumba Cedric Madianga wrote:
>>
>> Signed-off-by: M'boumba Cedric Madianga 
>> ---
>>  arch/arm/configs/stm32_defconfig | 3 +++
>>  1 file changed, 3 insertions(+)
>>
> Can you change the commit header by ARM: configs: stm32: Add I2C support
Ok, I will use this typo in the next version

>
> Thx
> alex
>
>
>
>
>
>> 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
>>
>


[PATCH v5 4/5] ARM: dts: Add I2C1 support for STM32429 eval board

2016-12-08 Thread M'boumba Cedric Madianga
Signed-off-by: M'boumba Cedric Madianga 
---
 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";
+};
-- 
1.9.1



[PATCH v5 3/5] ARM: dts: Add I2C1 support for STM32F429 SoC

2016-12-08 Thread M'boumba Cedric Madianga
Signed-off-by: Patrice Chotard 
Signed-off-by: M'boumba Cedric Madianga 
---
 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 
+#include 
 
 / {
clocks {
@@ -337,6 +338,16 @@
slew-rate = <2>;
};
};
+
+   i2c1_pins_b: i2c1@0 {
+   pins1 {
+   pinmux = ;
+   drive-open-drain;
+   };
+   pins2 {
+   pinmux = ;
+   };
+   };
};
 
rcc: rcc@40023810 {
@@ -409,6 +420,18 @@
interrupts = <80>;
clocks = <&rcc 0 38>;
};
+
+   i2c1: i2c@40005400 {
+   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";
+   };
};
 };
 
-- 
1.9.1



[PATCH v5 0/5] Add support for the STM32F4 I2C

2016-12-08 Thread M'boumba Cedric Madianga
This patchset adds support for the I2C controller embedded in STM32F4xx SoC.
It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus
speed.

Changes since v4:
- Use clamp() function to use a value in a given range as it was missed in V4

M'boumba Cedric Madianga (5):
  dt-bindings: Document the STM32 I2C bindings
  i2c: Add STM32F4 I2C driver
  ARM: dts: Add I2C1 support for STM32F429 SoC
  ARM: dts: Add I2C1 support for STM32429 eval board
  ARM: configs: Add I2C support for STM32 defconfig

 .../devicetree/bindings/i2c/i2c-stm32.txt  |  33 +
 arch/arm/boot/dts/stm32429i-eval.dts   |   6 +
 arch/arm/boot/dts/stm32f429.dtsi   |  23 +
 arch/arm/configs/stm32_defconfig   |   3 +
 drivers/i2c/busses/Kconfig |  10 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-stm32f4.c   | 851 +
 7 files changed, 927 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
 create mode 100644 drivers/i2c/busses/i2c-stm32f4.c

-- 
1.9.1



[PATCH v5 1/5] dt-bindings: Document the STM32 I2C bindings

2016-12-08 Thread M'boumba Cedric Madianga
This patch adds documentation of device tree bindings for the STM32 I2C
controller.

Signed-off-by: M'boumba Cedric Madianga 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/i2c/i2c-stm32.txt  | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt 
b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
new file mode 100644
index 000..78eaf7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
@@ -0,0 +1,33 @@
+* I2C controller embedded in STMicroelectronics STM32 I2C platform
+
+Required properties :
+- compatible : Must be "st,stm32f4-i2c"
+- reg : Offset and length of the register set for the device
+- interrupts : Must contain the interrupt id for I2C event and then the
+  interrupt id for I2C error.
+- resets: Must contain the phandle to the reset controller.
+- clocks: Must contain the input clock of the I2C instance.
+- A pinctrl state named "default" must be defined to set pins in mode of
+  operation for I2C transfer
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+  the default 100 kHz frequency will be used. As only Normal and Fast modes
+  are supported, possible values are 10 and 40.
+
+Example :
+
+   i2c@40005400 {
+   compatible = "st,stm32f4-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x40005400 0x400>;
+   interrupts = <31>,
+<32>;
+   resets = <&rcc 277>;
+   clocks = <&rcc 0 149>;
+   pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
+   pinctrl-names = "default";
+   };
-- 
1.9.1



[PATCH v5 2/5] i2c: Add STM32F4 I2C driver

2016-12-08 Thread M'boumba Cedric Madianga
This patch adds support for the STM32F4 I2C controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/i2c/busses/Kconfig   |  10 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-stm32f4.c | 851 +++
 3 files changed, 862 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-stm32f4.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 8e43914..584e0d7 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 000..0630354
--- /dev/null
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -0,0 +1,851 @@
+/*
+ * Driver for STMicroelectronics STM32 I2C controller
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2015
+ * Author: M'boumba Cedric Madianga 
+ *
+ * This driver is based on i2c-st.c
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* STM32F4 I2C offset registers */
+#define STM32F4_I2C_CR10x00
+#define STM32F4_I2C_CR20x04
+#define STM32F4_I2C_DR 0x10
+#define STM32F4_I2C_SR10x14
+#define STM32F4_I2C_SR20x18
+#define STM32F4_I2C_CCR0x1C
+#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_POSBIT(11)
+#define STM32F4_I2C_CR1_ACKBIT(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))
+#define STM32F4_I2C_CR2_ITBUFENBIT(10)
+#define STM32F4_I2C_CR2_ITEVTENBIT(9)
+#define STM32F4_I2C_CR2_ITERRENBIT(8)
+#define STM32F4_I2C_CR2_IRQ_MASK   (STM32F4_I2C_CR2_ITBUFEN \
+   | STM32F4_I2C_CR2_ITEVTEN \
+   | STM32F4_I2C_CR2_ITERREN)
+
+/* 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_TXEBIT(7)
+#define STM32F4_I2C_SR1_RXNE   BIT(6)
+#define STM32F4_I2C_SR1_BTFBIT(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_VALU

[PATCH v5 5/5] ARM: configs: Add I2C support for STM32 defconfig

2016-12-08 Thread M'boumba Cedric Madianga
Signed-off-by: M'boumba Cedric Madianga 
---
 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
-- 
1.9.1



[PATCH v4 4/5] ARM: dts: Add I2C1 support for STM32429 eval board

2016-12-07 Thread M'boumba Cedric Madianga
Signed-off-by: M'boumba Cedric Madianga 
---
 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";
+};
-- 
1.9.1



[PATCH v4 2/5] i2c: Add STM32F4 I2C driver

2016-12-07 Thread M'boumba Cedric Madianga
This patch adds support for the STM32F4 I2C controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/i2c/busses/Kconfig   |  10 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-stm32f4.c | 857 +++
 3 files changed, 868 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-stm32f4.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 8e43914..584e0d7 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 000..faf12fd
--- /dev/null
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -0,0 +1,857 @@
+/*
+ * Driver for STMicroelectronics STM32 I2C controller
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2015
+ * Author: M'boumba Cedric Madianga 
+ *
+ * This driver is based on i2c-st.c
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* STM32F4 I2C offset registers */
+#define STM32F4_I2C_CR10x00
+#define STM32F4_I2C_CR20x04
+#define STM32F4_I2C_DR 0x10
+#define STM32F4_I2C_SR10x14
+#define STM32F4_I2C_SR20x18
+#define STM32F4_I2C_CCR0x1C
+#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_POSBIT(11)
+#define STM32F4_I2C_CR1_ACKBIT(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))
+#define STM32F4_I2C_CR2_ITBUFENBIT(10)
+#define STM32F4_I2C_CR2_ITEVTENBIT(9)
+#define STM32F4_I2C_CR2_ITERRENBIT(8)
+#define STM32F4_I2C_CR2_IRQ_MASK   (STM32F4_I2C_CR2_ITBUFEN \
+   | STM32F4_I2C_CR2_ITEVTEN \
+   | STM32F4_I2C_CR2_ITERREN)
+
+/* 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_TXEBIT(7)
+#define STM32F4_I2C_SR1_RXNE   BIT(6)
+#define STM32F4_I2C_SR1_BTFBIT(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_VALU

[PATCH v4 5/5] ARM: configs: Add I2C support for STM32 defconfig

2016-12-07 Thread M'boumba Cedric Madianga
Signed-off-by: M'boumba Cedric Madianga 
---
 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
-- 
1.9.1



[PATCH v4 0/5] Add support for the STM32F4 I2C

2016-12-07 Thread M'boumba Cedric Madianga
This patchset adds support for the I2C controller embedded in STM32F4xx SoC.
It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus
speed.

Changes since v3 after Wolfram's review:
- Add COMPILE_TEST flag in Kconfig
- Use correct driver name in Kconfig i.e i2c-stm32f4 instead of i2c-st
- Use more comprehensible name stm32f4_i2c_msg for client specific data
- Don't store reset control node as just needed in probe
- Use clamp() function to test value between 2 ranges
- Use new "i2c_8bit_addr_from_msg() function to build I2C address
- Don't write error messages for timeout
- Remove error message when i2c_add_adapter() fails as it is already handled by
  the i2c core driver

M'boumba Cedric Madianga (5):
  dt-bindings: Document the STM32 I2C bindings
  i2c: Add STM32F4 I2C driver
  ARM: dts: Add I2C1 support for STM32F429 SoC
  ARM: dts: Add I2C1 support for STM32429 eval board
  ARM: configs: Add I2C support for STM32 defconfig

 .../devicetree/bindings/i2c/i2c-stm32.txt  |  33 +
 arch/arm/boot/dts/stm32429i-eval.dts   |   6 +
 arch/arm/boot/dts/stm32f429.dtsi   |  23 +
 arch/arm/configs/stm32_defconfig   |   3 +
 drivers/i2c/busses/Kconfig |  10 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-stm32f4.c   | 857 +
 7 files changed, 933 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
 create mode 100644 drivers/i2c/busses/i2c-stm32f4.c

-- 
1.9.1



[PATCH v4 3/5] ARM: dts: Add I2C1 support for STM32F429 SoC

2016-12-07 Thread M'boumba Cedric Madianga
Signed-off-by: Patrice Chotard 
Signed-off-by: M'boumba Cedric Madianga 
---
 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 
+#include 
 
 / {
clocks {
@@ -337,6 +338,16 @@
slew-rate = <2>;
};
};
+
+   i2c1_pins_b: i2c1@0 {
+   pins1 {
+   pinmux = ;
+   drive-open-drain;
+   };
+   pins2 {
+   pinmux = ;
+   };
+   };
};
 
rcc: rcc@40023810 {
@@ -409,6 +420,18 @@
interrupts = <80>;
clocks = <&rcc 0 38>;
};
+
+   i2c1: i2c@40005400 {
+   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";
+   };
};
 };
 
-- 
1.9.1



[PATCH v4 1/5] dt-bindings: Document the STM32 I2C bindings

2016-12-07 Thread M'boumba Cedric Madianga
This patch adds documentation of device tree bindings for the STM32 I2C
controller.

Signed-off-by: M'boumba Cedric Madianga 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/i2c/i2c-stm32.txt  | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt 
b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
new file mode 100644
index 000..78eaf7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
@@ -0,0 +1,33 @@
+* I2C controller embedded in STMicroelectronics STM32 I2C platform
+
+Required properties :
+- compatible : Must be "st,stm32f4-i2c"
+- reg : Offset and length of the register set for the device
+- interrupts : Must contain the interrupt id for I2C event and then the
+  interrupt id for I2C error.
+- resets: Must contain the phandle to the reset controller.
+- clocks: Must contain the input clock of the I2C instance.
+- A pinctrl state named "default" must be defined to set pins in mode of
+  operation for I2C transfer
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+  the default 100 kHz frequency will be used. As only Normal and Fast modes
+  are supported, possible values are 10 and 40.
+
+Example :
+
+   i2c@40005400 {
+   compatible = "st,stm32f4-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x40005400 0x400>;
+   interrupts = <31>,
+<32>;
+   resets = <&rcc 277>;
+   clocks = <&rcc 0 149>;
+   pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
+   pinctrl-names = "default";
+   };
-- 
1.9.1



Re: [PATCH v3 2/5] i2c: Add STM32F4 I2C driver

2016-11-30 Thread M'boumba Cedric Madianga
Hi,


2016-11-30 17:23 GMT+01:00 Wolfram Sang :
> Hi,
>
>> I was too busy in another project but now I am ready to complete the
>> upstream of the STM32F4 I2C driver.
>
> Nice.
>
>> >> +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;
>> >> +
>> >> + if (freq > STM32F4_I2C_MAX_FREQ)
>> >> + freq = STM32F4_I2C_MAX_FREQ;
>> >> + if (freq < STM32F4_I2C_MIN_FREQ)
>> >> + freq = STM32F4_I2C_MIN_FREQ;
>> >
>> > clamp() to enforce the range?
>> Sorry but what do you mean by "clamp()" ?
>
> The kernel has a clamp() function which would fit this purpose, I think.
Ok I got it. I will fix it in the V4.
Thanks

>
> Regards,
>
>Wolfram
>


  1   2   >