* [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2014-11-24 9:38 ` Xudong Chen 0 siblings, 0 replies; 32+ messages in thread From: Xudong Chen @ 2014-11-24 9:38 UTC (permalink / raw) To: Mark Rutland, Matthias Brugger, Wolfram Sang Cc: srv_heupstream, Sascha Hauer, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, Russell King, Grant Likely, Xudong Chen, Jean Delvare, Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, linux-i2c, Yingjoe Chen, Eddie Huang, Nathan Chung, YH Chen This series is the third version of Mediatek SoCs I2C controller common bus driver. Compared to the second version, 1. Add comments for clock in dt-bindings file i2c-mt6577.txt. 2. Remove mt8135.dtsi because of the dependency on pinctrl and clock. 3. Encode the feature have-dcm in i2c-mt65xx.c by checking the compatible. This driver is based on 3.18-rc1. MTK I2C HW has some limitation. 1. If the i2c_msg number is more than one, STOP will be issued instead of RS(Repeat Start) between each message. Such as: "START + ADDR + DATA_n + STOP + START + ADDR + DATA_n + STOP ..." 2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD mode the Repeat Start will be issued between 2 messages. In this driver if 2 messages is first write then read, the driver will combine 2 messages using Write-Read mode so the RS will be issued between the 2 messages. Ex: W/R/R, driver will combine first W/R and then R. The data series will be: "START + WriteADDR + DATA + RS + ReadADDR + DATA + STOP + START + ReadADDR + DATA + STOP". 3. Due to HW limitation, in this version the max transfer data length is 255 in one message. If want to transfer more than 255 bytes, HW needs the SW driver to split the data. Take 600 bytes for example, the data need to be divided into 3 parts 255 + 255 + 90. The data series will be: "START + ADDR + DATA_255 + RS + ADDR + DATA_255 + RS + ADDR + DATA_90 + STOP" instead of "START + ADDR + DATA_900 + STOP". We haven't implement this yet, we will do this in the separate patch. MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR bit first, the operation on other registers are still the same. For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support. For example, If want to use I2C4/5/6 pins on MT8135 just need to enable the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add "mediatek,have-pmic" property in the .dts file of each platform. Xudong Chen (2): dt-bindings: Add I2C bindings for mt65xx/mt81xx. I2C: mediatek: Add driver for MediaTek I2C controller .../devicetree/bindings/i2c/i2c-mt6577.txt | 40 ++ drivers/i2c/busses/Kconfig | 9 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-mt65xx.c | 742 +++++++++++++++++++++ 4 files changed, 792 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt create mode 100644 drivers/i2c/busses/i2c-mt65xx.c -- 1.8.1.1.dirty ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2014-11-24 9:38 ` Xudong Chen 0 siblings, 0 replies; 32+ messages in thread From: Xudong Chen @ 2014-11-24 9:38 UTC (permalink / raw) To: linux-arm-kernel This series is the third version of Mediatek SoCs I2C controller common bus driver. Compared to the second version, 1. Add comments for clock in dt-bindings file i2c-mt6577.txt. 2. Remove mt8135.dtsi because of the dependency on pinctrl and clock. 3. Encode the feature have-dcm in i2c-mt65xx.c by checking the compatible. This driver is based on 3.18-rc1. MTK I2C HW has some limitation. 1. If the i2c_msg number is more than one, STOP will be issued instead of RS(Repeat Start) between each message. Such as: "START + ADDR + DATA_n + STOP + START + ADDR + DATA_n + STOP ..." 2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD mode the Repeat Start will be issued between 2 messages. In this driver if 2 messages is first write then read, the driver will combine 2 messages using Write-Read mode so the RS will be issued between the 2 messages. Ex: W/R/R, driver will combine first W/R and then R. The data series will be: "START + WriteADDR + DATA + RS + ReadADDR + DATA + STOP + START + ReadADDR + DATA + STOP". 3. Due to HW limitation, in this version the max transfer data length is 255 in one message. If want to transfer more than 255 bytes, HW needs the SW driver to split the data. Take 600 bytes for example, the data need to be divided into 3 parts 255 + 255 + 90. The data series will be: "START + ADDR + DATA_255 + RS + ADDR + DATA_255 + RS + ADDR + DATA_90 + STOP" instead of "START + ADDR + DATA_900 + STOP". We haven't implement this yet, we will do this in the separate patch. MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR bit first, the operation on other registers are still the same. For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support. For example, If want to use I2C4/5/6 pins on MT8135 just need to enable the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add "mediatek,have-pmic" property in the .dts file of each platform. Xudong Chen (2): dt-bindings: Add I2C bindings for mt65xx/mt81xx. I2C: mediatek: Add driver for MediaTek I2C controller .../devicetree/bindings/i2c/i2c-mt6577.txt | 40 ++ drivers/i2c/busses/Kconfig | 9 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-mt65xx.c | 742 +++++++++++++++++++++ 4 files changed, 792 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt create mode 100644 drivers/i2c/busses/i2c-mt65xx.c -- 1.8.1.1.dirty ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2014-11-24 9:38 ` Xudong Chen 0 siblings, 0 replies; 32+ messages in thread From: Xudong Chen @ 2014-11-24 9:38 UTC (permalink / raw) To: Mark Rutland, Matthias Brugger, Wolfram Sang Cc: srv_heupstream, Sascha Hauer, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, Russell King, Grant Likely, Xudong Chen, Jean Delvare, Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, linux-i2c, Yingjoe Chen, Eddie Huang, Nathan Chung, YH Chen This series is the third version of Mediatek SoCs I2C controller common bus driver. Compared to the second version, 1. Add comments for clock in dt-bindings file i2c-mt6577.txt. 2. Remove mt8135.dtsi because of the dependency on pinctrl and clock. 3. Encode the feature have-dcm in i2c-mt65xx.c by checking the compatible. This driver is based on 3.18-rc1. MTK I2C HW has some limitation. 1. If the i2c_msg number is more than one, STOP will be issued instead of RS(Repeat Start) between each message. Such as: "START + ADDR + DATA_n + STOP + START + ADDR + DATA_n + STOP ..." 2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD mode the Repeat Start will be issued between 2 messages. In this driver if 2 messages is first write then read, the driver will combine 2 messages using Write-Read mode so the RS will be issued between the 2 messages. Ex: W/R/R, driver will combine first W/R and then R. The data series will be: "START + WriteADDR + DATA + RS + ReadADDR + DATA + STOP + START + ReadADDR + DATA + STOP". 3. Due to HW limitation, in this version the max transfer data length is 255 in one message. If want to transfer more than 255 bytes, HW needs the SW driver to split the data. Take 600 bytes for example, the data need to be divided into 3 parts 255 + 255 + 90. The data series will be: "START + ADDR + DATA_255 + RS + ADDR + DATA_255 + RS + ADDR + DATA_90 + STOP" instead of "START + ADDR + DATA_900 + STOP". We haven't implement this yet, we will do this in the separate patch. MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR bit first, the operation on other registers are still the same. For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support. For example, If want to use I2C4/5/6 pins on MT8135 just need to enable the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add "mediatek,have-pmic" property in the .dts file of each platform. Xudong Chen (2): dt-bindings: Add I2C bindings for mt65xx/mt81xx. I2C: mediatek: Add driver for MediaTek I2C controller .../devicetree/bindings/i2c/i2c-mt6577.txt | 40 ++ drivers/i2c/busses/Kconfig | 9 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-mt65xx.c | 742 +++++++++++++++++++++ 4 files changed, 792 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt create mode 100644 drivers/i2c/busses/i2c-mt65xx.c -- 1.8.1.1.dirty ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 1/2] dt-bindings: Add I2C bindings for mt65xx/mt81xx. 2014-11-24 9:38 ` Xudong Chen (?) @ 2014-11-24 9:38 ` Xudong Chen -1 siblings, 0 replies; 32+ messages in thread From: Xudong Chen @ 2014-11-24 9:38 UTC (permalink / raw) To: Mark Rutland, Matthias Brugger, Wolfram Sang Cc: srv_heupstream, Sascha Hauer, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, Russell King, Grant Likely, Xudong Chen, Jean Delvare, Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, linux-i2c, Yingjoe Chen, Eddie Huang, Nathan Chung, YH Chen Add devicetree bindings for Mediatek Soc I2C driver. Signed-off-by: Xudong Chen <xudong.chen@mediatek.com> Change-Id: Iaaba1e8420abfbfb503501310de04ee25ae72e18 --- .../devicetree/bindings/i2c/i2c-mt6577.txt | 40 ++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt new file mode 100644 index 0000000..08f86c7 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt @@ -0,0 +1,40 @@ +* Mediatek's I2C controller + +The Mediatek's I2C controller is used to interface with I2C devices. + +Required properties: + - compatible: value should be either of the following. + (a) "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c. + (b) "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c. + (c) "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c. + (d) "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c. + - reg: physical base address of the controller and dma base, length of memory + mapped region. + - interrupts: interrupt number to the cpu. + - clock-div: the fixed value for frequency divider of clock source in i2c + module. Each IC may be different. + - clocks: clock name from clock manager + - clock-names: Must include "main" and "dma", if enable have-pmic need include + "pmic" extra. + +Optional properties: + - clock-frequency: Frequency in Hz of the bus when transfer, the default value + is 100000. + - mediatek,have-pmic: platform can control i2c form special pmic side. + Only mt6589 and mt8135 support this feature. + - mediatek,use-push-pull: IO config use push-pull mode. + +Example: + + i2c0: i2c@1100d000 { + compatible = "mediatek,mt6577-i2c"; + reg = <0x1100d000 0x70>, + <0x11000300 0x80>; + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_LOW>; + clock-frequency = <100000>; + mediatek,have-pmic; + clock-div = <16>; + clocks = <&i2c0_ck>, <&ap_dma_ck>; + clock-names = "main", "dma"; + }; + -- 1.8.1.1.dirty ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v3 1/2] dt-bindings: Add I2C bindings for mt65xx/mt81xx. @ 2014-11-24 9:38 ` Xudong Chen 0 siblings, 0 replies; 32+ messages in thread From: Xudong Chen @ 2014-11-24 9:38 UTC (permalink / raw) To: linux-arm-kernel Add devicetree bindings for Mediatek Soc I2C driver. Signed-off-by: Xudong Chen <xudong.chen@mediatek.com> Change-Id: Iaaba1e8420abfbfb503501310de04ee25ae72e18 --- .../devicetree/bindings/i2c/i2c-mt6577.txt | 40 ++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt new file mode 100644 index 0000000..08f86c7 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt @@ -0,0 +1,40 @@ +* Mediatek's I2C controller + +The Mediatek's I2C controller is used to interface with I2C devices. + +Required properties: + - compatible: value should be either of the following. + (a) "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c. + (b) "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c. + (c) "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c. + (d) "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c. + - reg: physical base address of the controller and dma base, length of memory + mapped region. + - interrupts: interrupt number to the cpu. + - clock-div: the fixed value for frequency divider of clock source in i2c + module. Each IC may be different. + - clocks: clock name from clock manager + - clock-names: Must include "main" and "dma", if enable have-pmic need include + "pmic" extra. + +Optional properties: + - clock-frequency: Frequency in Hz of the bus when transfer, the default value + is 100000. + - mediatek,have-pmic: platform can control i2c form special pmic side. + Only mt6589 and mt8135 support this feature. + - mediatek,use-push-pull: IO config use push-pull mode. + +Example: + + i2c0: i2c at 1100d000 { + compatible = "mediatek,mt6577-i2c"; + reg = <0x1100d000 0x70>, + <0x11000300 0x80>; + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_LOW>; + clock-frequency = <100000>; + mediatek,have-pmic; + clock-div = <16>; + clocks = <&i2c0_ck>, <&ap_dma_ck>; + clock-names = "main", "dma"; + }; + -- 1.8.1.1.dirty ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v3 1/2] dt-bindings: Add I2C bindings for mt65xx/mt81xx. @ 2014-11-24 9:38 ` Xudong Chen 0 siblings, 0 replies; 32+ messages in thread From: Xudong Chen @ 2014-11-24 9:38 UTC (permalink / raw) To: Mark Rutland, Matthias Brugger, Wolfram Sang Cc: srv_heupstream, Sascha Hauer, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, Russell King, Grant Likely, Xudong Chen, Jean Delvare, Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, linux-i2c, Yingjoe Chen, Eddie Huang, Nathan Chung, YH Chen Add devicetree bindings for Mediatek Soc I2C driver. Signed-off-by: Xudong Chen <xudong.chen@mediatek.com> Change-Id: Iaaba1e8420abfbfb503501310de04ee25ae72e18 --- .../devicetree/bindings/i2c/i2c-mt6577.txt | 40 ++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt new file mode 100644 index 0000000..08f86c7 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt @@ -0,0 +1,40 @@ +* Mediatek's I2C controller + +The Mediatek's I2C controller is used to interface with I2C devices. + +Required properties: + - compatible: value should be either of the following. + (a) "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c. + (b) "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c. + (c) "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c. + (d) "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c. + - reg: physical base address of the controller and dma base, length of memory + mapped region. + - interrupts: interrupt number to the cpu. + - clock-div: the fixed value for frequency divider of clock source in i2c + module. Each IC may be different. + - clocks: clock name from clock manager + - clock-names: Must include "main" and "dma", if enable have-pmic need include + "pmic" extra. + +Optional properties: + - clock-frequency: Frequency in Hz of the bus when transfer, the default value + is 100000. + - mediatek,have-pmic: platform can control i2c form special pmic side. + Only mt6589 and mt8135 support this feature. + - mediatek,use-push-pull: IO config use push-pull mode. + +Example: + + i2c0: i2c@1100d000 { + compatible = "mediatek,mt6577-i2c"; + reg = <0x1100d000 0x70>, + <0x11000300 0x80>; + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_LOW>; + clock-frequency = <100000>; + mediatek,have-pmic; + clock-div = <16>; + clocks = <&i2c0_ck>, <&ap_dma_ck>; + clock-names = "main", "dma"; + }; + -- 1.8.1.1.dirty ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v3 2/2] I2C: mediatek: Add driver for MediaTek I2C controller 2014-11-24 9:38 ` Xudong Chen (?) @ 2014-11-24 9:38 ` Xudong Chen -1 siblings, 0 replies; 32+ messages in thread From: Xudong Chen @ 2014-11-24 9:38 UTC (permalink / raw) To: Mark Rutland, Matthias Brugger, Wolfram Sang Cc: srv_heupstream, Sascha Hauer, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, Russell King, Grant Likely, Xudong Chen, Jean Delvare, Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, linux-i2c, Yingjoe Chen, Eddie Huang, Nathan Chung, YH Chen The mediatek SoCs have I2C controller that handle I2C transfer. This patch include common I2C bus driver. This driver is compatible with I2C controller on mt65xx/mt81xx. Signed-off-by: Xudong Chen <xudong.chen@mediatek.com> Change-Id: Icc17e326b9df46a226d536956e103f17b0382b6e --- drivers/i2c/busses/Kconfig | 9 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-mt65xx.c | 742 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 752 insertions(+) create mode 100644 drivers/i2c/busses/i2c-mt65xx.c diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 917c358..0d7d0a4 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -564,6 +564,15 @@ config I2C_MPC This driver can also be built as a module. If so, the module will be called i2c-mpc. +config I2C_MT65XX + tristate "MediaTek I2C adapter" + depends on ARCH_MEDIATEK + help + This selects the MediaTek(R) Integrated Inter Circuit bus driver + for MT65xx and MT81xx. + If you want to use MediaTek(R) I2C interface, say Y or M here. + If unsure, say N. + config I2C_MV64XXX tristate "Marvell mv64xxx I2C Controller" depends on MV64X60 || PLAT_ORION || ARCH_SUNXI diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index 78d56c5..7a9f0f3 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_I2C_IMX) += i2c-imx.o obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o obj-$(CONFIG_I2C_KEMPLD) += i2c-kempld.o obj-$(CONFIG_I2C_MPC) += i2c-mpc.o +obj-$(CONFIG_I2C_MT65XX) += i2c-mt65xx.o obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o obj-$(CONFIG_I2C_MXS) += i2c-mxs.o obj-$(CONFIG_I2C_NOMADIK) += i2c-nomadik.o diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c new file mode 100644 index 0000000..09d83b9 --- /dev/null +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -0,0 +1,742 @@ +/* + * Copyright (c) 2014 MediaTek Inc. + * Author: Xudong.chen <xudong.chen@mediatek.com> + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/i2c.h> +#include <linux/init.h> +#include <linux/interrupt.h> +#include <linux/sched.h> +#include <linux/delay.h> +#include <linux/errno.h> +#include <linux/err.h> +#include <linux/device.h> +#include <linux/platform_device.h> +#include <linux/wait.h> +#include <linux/mm.h> +#include <linux/dma-mapping.h> +#include <linux/scatterlist.h> +#include <linux/io.h> +#include <linux/of_address.h> +#include <linux/of_irq.h> +#include <linux/clk.h> + +#define I2C_HS_NACKERR (1 << 2) +#define I2C_ACKERR (1 << 1) +#define I2C_TRANSAC_COMP (1 << 0) +#define I2C_TRANSAC_START (1 << 0) +#define I2C_TIMING_STEP_DIV_MASK (0x3f << 0) +#define I2C_TIMING_SAMPLE_COUNT_MASK (0x7 << 0) +#define I2C_TIMING_SAMPLE_DIV_MASK (0x7 << 8) +#define I2C_TIMING_DATA_READ_MASK (0x7 << 12) +#define I2C_DCM_DISABLE 0x0000 +#define I2C_IO_CONFIG_OPEN_DRAIN 0x0003 +#define I2C_IO_CONFIG_PUSH_PULL 0x0000 +#define I2C_SOFT_RST 0x0001 +#define I2C_FIFO_ADDR_CLR 0x0001 +#define I2C_DELAY_LEN 0x0002 +#define I2C_ST_START_CON 0x8001 +#define I2C_FS_START_CON 0x1800 +#define I2C_TIME_CLR_VALUE 0x0000 +#define I2C_TIME_DEFAULT_VALUE 0x0003 +#define I2C_FS_TIME_INIT_VALUE 0x1303 +#define I2C_WRRD_TRANAC_VALUE 0x0002 +#define I2C_RD_TRANAC_VALUE 0x0001 + +#define I2C_DMA_CON_TX 0x0000 +#define I2C_DMA_CON_RX 0x0001 +#define I2C_DMA_START_EN 0x0001 +#define I2C_DMA_INT_FLAG_NONE 0x0000 +#define I2C_DMA_CLR_FLAG 0x0000 + +#define I2C_DEFAUT_SPEED 100000 /* hz */ +#define MAX_FS_MODE_SPEED 400000 +#define MAX_HS_MODE_SPEED 3400000 +#define MAX_DMA_TRANS_SIZE 255 +#define MAX_WRRD_TRANS_SIZE 32 +#define MAX_SAMPLE_CNT_DIV 8 +#define MAX_STEP_CNT_DIV 64 +#define MAX_HS_STEP_CNT_DIV 8 + +#define I2C_CONTROL_RS (0x1 << 1) +#define I2C_CONTROL_DMA_EN (0x1 << 2) +#define I2C_CONTROL_CLK_EXT_EN (0x1 << 3) +#define I2C_CONTROL_DIR_CHANGE (0x1 << 4) +#define I2C_CONTROL_ACKERR_DET_EN (0x1 << 5) +#define I2C_CONTROL_TRANSFER_LEN_CHANGE (0x1 << 6) +#define I2C_CONTROL_WRAPPER (0x1 << 0) + +#define COMPAT_MT6577 (0x1 << 0) +#define COMPAT_MT6589 (0x1 << 1) + +#define I2C_DRV_NAME "mt-i2c" + +enum DMA_REGS_OFFSET { + OFFSET_INT_FLAG = 0x0, + OFFSET_INT_EN = 0x04, + OFFSET_EN = 0x08, + OFFSET_CON = 0x18, + OFFSET_TX_MEM_ADDR = 0x1c, + OFFSET_RX_MEM_ADDR = 0x20, + OFFSET_TX_LEN = 0x24, + OFFSET_RX_LEN = 0x28, +}; + +enum i2c_trans_st_rs { + I2C_TRANS_STOP = 0, + I2C_TRANS_REPEATED_START, +}; + +enum { + FS_MODE, + HS_MODE, +}; + +enum mtk_trans_op { + I2C_MASTER_WR = 1, + I2C_MASTER_RD, + I2C_MASTER_WRRD, +}; + +enum I2C_REGS_OFFSET { + OFFSET_DATA_PORT = 0x0, + OFFSET_SLAVE_ADDR = 0x04, + OFFSET_INTR_MASK = 0x08, + OFFSET_INTR_STAT = 0x0c, + OFFSET_CONTROL = 0x10, + OFFSET_TRANSFER_LEN = 0x14, + OFFSET_TRANSAC_LEN = 0x18, + OFFSET_DELAY_LEN = 0x1c, + OFFSET_TIMING = 0x20, + OFFSET_START = 0x24, + OFFSET_EXT_CONF = 0x28, + OFFSET_FIFO_STAT = 0x30, + OFFSET_FIFO_THRESH = 0x34, + OFFSET_FIFO_ADDR_CLR = 0x38, + OFFSET_IO_CONFIG = 0x40, + OFFSET_RSV_DEBUG = 0x44, + OFFSET_HS = 0x48, + OFFSET_SOFTRESET = 0x50, + OFFSET_DCM_EN = 0x54, + OFFSET_PATH_DIR = 0x60, + OFFSET_DEBUGSTAT = 0x64, + OFFSET_DEBUGCTRL = 0x68, + OFFSET_TRANSFER_LEN_AUX = 0x6c, +}; + +struct mtk_i2c_data { + unsigned int clk_frequency; /* bus speed in Hz */ + unsigned int flags; + unsigned int clk_src_div; +}; + +struct i2c_dma_buf { + u8 *vaddr; + dma_addr_t paddr; +}; + +struct mtk_i2c { + struct i2c_adapter adap; /* i2c host adapter */ + struct device *dev; + wait_queue_head_t wait; /* i2c transfer wait queue */ + /* set in i2c probe */ + void __iomem *base; /* i2c base addr */ + void __iomem *pdmabase; /* dma base address*/ + int irqnr; /* i2c interrupt number */ + struct i2c_dma_buf dma_buf; /* memory alloc for DMA mode */ + struct clk *clk_main; /* main clock for i2c bus */ + struct clk *clk_dma; /* DMA clock for i2c via DMA */ + struct clk *clk_pmic; /* PMIC clock for i2c from PMIC */ + bool have_pmic; /* can use i2c pins form PMIC */ + bool use_push_pull; /* IO config push-pull mode */ + u32 platform_compat; /* platform compatible data */ + /* set when doing the transfer */ + u16 irq_stat; /* interrupt status */ + unsigned int speed_hz; /* The speed in transfer */ + bool trans_stop; /* i2c transfer stop */ + enum mtk_trans_op op; + u16 msg_len; + u8 *msg_buf; /* pointer to msg data */ + u16 msg_aux_len; /* WRRD mode to set AUX_LEN register*/ + u16 addr; /* 7bit slave address, without read/write bit */ + u16 timing_reg; + u16 high_speed_reg; +}; + +static const struct of_device_id mtk_i2c_of_match[] = { + { .compatible = "mediatek,mt6577-i2c", .data = (void *)COMPAT_MT6577 }, + { .compatible = "mediatek,mt6589-i2c", .data = (void *)COMPAT_MT6589 }, + {}, +}; +MODULE_DEVICE_TABLE(of, mtk_i2c_match); + +static inline void i2c_writew(u16 value, struct mtk_i2c *i2c, u8 offset) +{ + writew(value, i2c->base + offset); +} + +static inline u16 i2c_readw(struct mtk_i2c *i2c, u8 offset) +{ + return readw(i2c->base + offset); +} + +static inline void i2c_writel_dma(u32 value, struct mtk_i2c *i2c, u8 offset) +{ + writel(value, i2c->pdmabase + offset); +} + +static int mtk_i2c_clock_enable(struct mtk_i2c *i2c) +{ + int ret; + + ret = clk_prepare_enable(i2c->clk_dma); + if (ret) + return ret; + + ret = clk_prepare_enable(i2c->clk_main); + if (ret) + goto err_main; + + if (i2c->have_pmic) { + ret = clk_prepare_enable(i2c->clk_pmic); + if (ret) + goto err_pmic; + } + return 0; + +err_pmic: + clk_disable_unprepare(i2c->clk_main); +err_main: + clk_disable_unprepare(i2c->clk_dma); + + return ret; +} + +static void mtk_i2c_clock_disable(struct mtk_i2c *i2c) +{ + if (i2c->have_pmic) + clk_disable_unprepare(i2c->clk_pmic); + + clk_disable_unprepare(i2c->clk_main); + clk_disable_unprepare(i2c->clk_dma); +} + +static void free_i2c_dma_bufs(struct mtk_i2c *i2c) +{ + dma_free_coherent(i2c->adap.dev.parent, PAGE_SIZE, + i2c->dma_buf.vaddr, i2c->dma_buf.paddr); +} + +static inline void mtk_i2c_init_hw(struct mtk_i2c *i2c) +{ + i2c_writew(I2C_SOFT_RST, i2c, OFFSET_SOFTRESET); + /* Set ioconfig */ + if (i2c->use_push_pull) + i2c_writew(I2C_IO_CONFIG_PUSH_PULL, i2c, OFFSET_IO_CONFIG); + else + i2c_writew(I2C_IO_CONFIG_OPEN_DRAIN, i2c, OFFSET_IO_CONFIG); + + if (i2c->platform_compat & COMPAT_MT6577) + i2c_writew(I2C_DCM_DISABLE, i2c, OFFSET_DCM_EN); + + i2c_writew(i2c->timing_reg, i2c, OFFSET_TIMING); + i2c_writew(i2c->high_speed_reg, i2c, OFFSET_HS); +} + +/* calculate i2c port speed */ +static int i2c_set_speed(struct mtk_i2c *i2c, unsigned int clk_src_in_hz) +{ + int mode; + unsigned int khz; + unsigned int step_cnt; + unsigned int sample_cnt; + unsigned int sclk; + unsigned int hclk; + unsigned int max_step_cnt; + unsigned int sample_div = MAX_SAMPLE_CNT_DIV; + unsigned int step_div; + unsigned int min_div; + unsigned int best_mul; + unsigned int cnt_mul; + + if (i2c->speed_hz > MAX_HS_MODE_SPEED) { + return -EINVAL; + } else if (i2c->speed_hz > MAX_FS_MODE_SPEED) { + mode = HS_MODE; + max_step_cnt = MAX_HS_STEP_CNT_DIV; + } else { + mode = FS_MODE; + max_step_cnt = MAX_STEP_CNT_DIV; + } + + step_div = max_step_cnt; + /* Find the best combination */ + khz = i2c->speed_hz / 1000; + hclk = clk_src_in_hz / 1000; + min_div = ((hclk >> 1) + khz - 1) / khz; + best_mul = MAX_SAMPLE_CNT_DIV * max_step_cnt; + + for (sample_cnt = 1; sample_cnt <= MAX_SAMPLE_CNT_DIV; sample_cnt++) { + step_cnt = (min_div + sample_cnt - 1) / sample_cnt; + cnt_mul = step_cnt * sample_cnt; + if (step_cnt > max_step_cnt) + continue; + + if (cnt_mul < best_mul) { + best_mul = cnt_mul; + sample_div = sample_cnt; + step_div = step_cnt; + if (best_mul == min_div) + break; + } + } + + sample_cnt = sample_div; + step_cnt = step_div; + sclk = hclk / (2 * sample_cnt * step_cnt); + if (sclk > khz) { + dev_dbg(i2c->dev, "%s mode: unsupported speed (%ldkhz)\n", + (mode == HS_MODE) ? "HS" : "ST/FT", (long int)khz); + return -ENOTSUPP; + } + + step_cnt--; + sample_cnt--; + + if (mode == HS_MODE) { + /* Set the hign speed mode register */ + i2c->timing_reg = I2C_FS_TIME_INIT_VALUE; + i2c->high_speed_reg = I2C_TIME_DEFAULT_VALUE | + (sample_cnt & I2C_TIMING_SAMPLE_COUNT_MASK) << 12 | + (step_cnt & I2C_TIMING_SAMPLE_COUNT_MASK) << 8; + } else { + i2c->timing_reg = + (sample_cnt & I2C_TIMING_SAMPLE_COUNT_MASK) << 8 | + (step_cnt & I2C_TIMING_STEP_DIV_MASK) << 0; + /* Disable the high speed transaction */ + i2c->high_speed_reg = I2C_TIME_CLR_VALUE; + } + + return 0; +} + +static int mtk_i2c_do_transfer(struct mtk_i2c *i2c) +{ + u16 addr_reg; + u16 control_reg; + int tmo = i2c->adap.timeout; + + i2c->trans_stop = false; + i2c->irq_stat = 0; + + /* If use i2c pin from PMIC mt6397 side, need set PATH_DIR first */ + if (i2c->have_pmic) + i2c_writew(I2C_CONTROL_WRAPPER, i2c, OFFSET_PATH_DIR); + + control_reg = I2C_CONTROL_ACKERR_DET_EN | + I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN; + if (i2c->speed_hz > 400000) + control_reg |= I2C_CONTROL_RS; + if (i2c->op == I2C_MASTER_WRRD) + control_reg |= I2C_CONTROL_DIR_CHANGE | I2C_CONTROL_RS; + i2c_writew(control_reg, i2c, OFFSET_CONTROL); + + /* set start condition */ + if (i2c->speed_hz <= 100000) + i2c_writew(I2C_ST_START_CON, i2c, OFFSET_EXT_CONF); + else + i2c_writew(I2C_FS_START_CON, i2c, OFFSET_EXT_CONF); + + if (~control_reg & I2C_CONTROL_RS) + i2c_writew(I2C_DELAY_LEN, i2c, OFFSET_DELAY_LEN); + + addr_reg = i2c->addr << 1; + if (i2c->op == I2C_MASTER_RD) + addr_reg |= 0x1; + i2c_writew(addr_reg, i2c, OFFSET_SLAVE_ADDR); + + /* Clear interrupt status */ + i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP, + i2c, OFFSET_INTR_STAT); + i2c_writew(I2C_FIFO_ADDR_CLR, i2c, OFFSET_FIFO_ADDR_CLR); + + /* Enable interrupt */ + i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP, + i2c, OFFSET_INTR_MASK); + + /* Set transfer and transaction len */ + if (i2c->op == I2C_MASTER_WRRD) { + i2c_writew(i2c->msg_len | (i2c->msg_aux_len) << 8, + i2c, OFFSET_TRANSFER_LEN); + i2c_writew(I2C_WRRD_TRANAC_VALUE, i2c, OFFSET_TRANSAC_LEN); + } else { + i2c_writew(i2c->msg_len, i2c, OFFSET_TRANSFER_LEN); + i2c_writew(I2C_RD_TRANAC_VALUE, i2c, OFFSET_TRANSAC_LEN); + } + + /* Prepare buffer data to start transfer */ + if (i2c->op == I2C_MASTER_RD) { + i2c_writel_dma(I2C_DMA_INT_FLAG_NONE, i2c, OFFSET_INT_FLAG); + i2c_writel_dma(I2C_DMA_CON_RX, i2c, OFFSET_CON); + i2c_writel_dma((u32)i2c->msg_buf, i2c, OFFSET_RX_MEM_ADDR); + i2c_writel_dma(i2c->msg_len, i2c, OFFSET_RX_LEN); + } else if (i2c->op == I2C_MASTER_WR) { + i2c_writel_dma(I2C_DMA_INT_FLAG_NONE, i2c, OFFSET_INT_FLAG); + i2c_writel_dma(I2C_DMA_CON_TX, i2c, OFFSET_CON); + i2c_writel_dma((u32)i2c->msg_buf, i2c, OFFSET_TX_MEM_ADDR); + i2c_writel_dma(i2c->msg_len, i2c, OFFSET_TX_LEN); + } else { + i2c_writel_dma(I2C_DMA_CLR_FLAG, i2c, OFFSET_INT_FLAG); + i2c_writel_dma(I2C_DMA_CLR_FLAG, i2c, OFFSET_CON); + i2c_writel_dma((u32)i2c->msg_buf, i2c, OFFSET_TX_MEM_ADDR); + i2c_writel_dma((u32)i2c->dma_buf.paddr, i2c, + OFFSET_RX_MEM_ADDR); + i2c_writel_dma(i2c->msg_len, i2c, OFFSET_TX_LEN); + i2c_writel_dma(i2c->msg_aux_len, i2c, OFFSET_RX_LEN); + } + + /* flush before sending start */ + mb(); + i2c_writel_dma(I2C_DMA_START_EN, i2c, OFFSET_EN); + i2c_writew(I2C_TRANSAC_START, i2c, OFFSET_START); + + tmo = wait_event_timeout(i2c->wait, i2c->trans_stop, tmo); + if (tmo == 0) { + dev_dbg(i2c->dev, "addr: %x, transfer timeout\n", i2c->addr); + mtk_i2c_init_hw(i2c); + return -ETIMEDOUT; + } + + if (i2c->irq_stat & (I2C_HS_NACKERR | I2C_ACKERR)) { + dev_dbg(i2c->dev, "addr: %x, transfer ACK error\n", i2c->addr); + mtk_i2c_init_hw(i2c); + return -EREMOTEIO; + } + + dev_dbg(i2c->dev, "i2c transfer done.\n"); + + return 0; +} + +static inline void mtk_i2c_copy_to_dma(struct mtk_i2c *i2c, struct i2c_msg *msg) +{ + /* if the operate is write, need to copy the data to DMA memory */ + if (!(msg->flags & I2C_M_RD)) + memcpy(i2c->dma_buf.vaddr, msg->buf, msg->len); +} + +static inline void mtk_i2c_copy_from_dma(struct mtk_i2c *i2c, + struct i2c_msg *msg) +{ + /* if the operate is read, need to copy the data from DMA memory */ + if (msg->flags & I2C_M_RD) + memcpy(msg->buf, i2c->dma_buf.vaddr, msg->len); +} + +/* + * In MTK platform the STOP will be issued after each + * message was transferred which is not flow the clarify + * for i2c_transfer(), several I2C devices tolerate the STOP, + * but some device need Repeat-Start and do not compatible with STOP + * MTK platform has WRRD mode which can write then read with + * Repeat-Start between two message, so we combined two + * messages into one transaction. + * The max read length is 31 + */ +static bool mtk_i2c_should_combine(struct i2c_msg *msg) +{ + struct i2c_msg *next_msg = msg + 1; + + if ((next_msg->len < MAX_WRRD_TRANS_SIZE) && + msg->addr == next_msg->addr && + !(msg->flags & I2C_M_RD) && + (next_msg->flags & I2C_M_RD) == I2C_M_RD) { + return true; + } + + return false; +} + +static int mtk_i2c_transfer(struct i2c_adapter *adap, + struct i2c_msg msgs[], int num) +{ + int ret; + int left_num = num; + struct mtk_i2c *i2c = i2c_get_adapdata(adap); + + ret = mtk_i2c_clock_enable(i2c); + if (ret) + return ret; + + while (left_num--) { + /* In MTK platform the max transfer number is 255 */ + if (msgs->len > MAX_DMA_TRANS_SIZE) { + dev_dbg(i2c->dev, + " message data length is more than 255\n"); + ret = -EINVAL; + goto err_exit; + } + + if (msgs->addr == 0) { + dev_dbg(i2c->dev, " addr is invalid.\n"); + ret = -EINVAL; + goto err_exit; + } + + if (msgs->buf == NULL) { + dev_dbg(i2c->dev, " data buffer is NULL.\n"); + ret = -EINVAL; + goto err_exit; + } + + i2c->addr = msgs->addr; + i2c->msg_len = msgs->len; + i2c->msg_buf = msgs->buf; + + if (msgs->flags & I2C_M_RD) + i2c->op = I2C_MASTER_RD; + else + i2c->op = I2C_MASTER_WR; + + /* combined two messages into one transaction */ + if (left_num >= 1 && mtk_i2c_should_combine(msgs)) { + i2c->msg_aux_len = (msgs + 1)->len; + i2c->op = I2C_MASTER_WRRD; + left_num--; + } + + /* + * always use DMA mode. + * 1st when write need copy the data of message to dma memory + * 2nd when read need copy the DMA data to the message buffer. + * The length should be less than 255. + */ + mtk_i2c_copy_to_dma(i2c, msgs); + i2c->msg_buf = (u8 *)i2c->dma_buf.paddr; + ret = mtk_i2c_do_transfer(i2c); + if (ret < 0) + goto err_exit; + + if (i2c->op == I2C_MASTER_WRRD) + mtk_i2c_copy_from_dma(i2c, msgs + 1); + else + mtk_i2c_copy_from_dma(i2c, msgs); + + msgs++; + + /* after combined two messages so we need ignore one */ + if (left_num > 0 && i2c->op == I2C_MASTER_WRRD) + msgs++; + } + /* the return value is number of executed messages */ + ret = num; + +err_exit: + mtk_i2c_clock_disable(i2c); + return ret; +} + +static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id) +{ + struct mtk_i2c *i2c = dev_id; + + /* Clear interrupt mask */ + i2c_writew(~(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP), + i2c, OFFSET_INTR_MASK); + + i2c->irq_stat = i2c_readw(i2c, OFFSET_INTR_STAT); + i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP, + i2c, OFFSET_INTR_STAT); + i2c->trans_stop = true; + wake_up(&i2c->wait); + + return IRQ_HANDLED; +} + +static u32 mtk_i2c_functionality(struct i2c_adapter *adap) +{ + return I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR | I2C_FUNC_SMBUS_EMUL; +} + +static const struct i2c_algorithm mtk_i2c_algorithm = { + .master_xfer = mtk_i2c_transfer, + .functionality = mtk_i2c_functionality, +}; + +static inline u32 mtk_get_device_prop(struct platform_device *pdev) +{ + const struct of_device_id *match; + + match = of_match_node(mtk_i2c_of_match, pdev->dev.of_node); + return (u32)match->data; +} + +static int mtk_i2c_parse_dt(struct device_node *np, struct mtk_i2c *i2c, + unsigned int *clk_src_div) +{ + i2c->speed_hz = I2C_DEFAUT_SPEED; + of_property_read_u32(np, "clock-frequency", &i2c->speed_hz); + of_property_read_u32(np, "clock-div", clk_src_div); + if (*clk_src_div == 0) + return -EINVAL; + + i2c->have_pmic = of_property_read_bool(np, "mediatek,have-pmic"); + i2c->use_push_pull = + of_property_read_bool(np, "mediatek,use-push-pull"); + + return 0; +} + +static int mtk_i2c_probe(struct platform_device *pdev) +{ + int ret = 0; + struct mtk_i2c *i2c; + unsigned int clk_src_in_hz; + unsigned int clk_src_div; + struct resource *res; + + i2c = devm_kzalloc(&pdev->dev, sizeof(struct mtk_i2c), GFP_KERNEL); + if (i2c == NULL) + return -ENOMEM; + + ret = mtk_i2c_parse_dt(pdev->dev.of_node, i2c, &clk_src_div); + if (ret) + return -EINVAL; + + i2c->platform_compat = mtk_get_device_prop(pdev); + if (i2c->have_pmic && (i2c->platform_compat & COMPAT_MT6577)) + return -EINVAL; + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + + i2c->base = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(i2c->base)) + return PTR_ERR(i2c->base); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 1); + + i2c->pdmabase = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(i2c->pdmabase)) + return PTR_ERR(i2c->pdmabase); + + i2c->irqnr = platform_get_irq(pdev, 0); + if (i2c->irqnr <= 0) + return -EINVAL; + + ret = devm_request_irq(&pdev->dev, i2c->irqnr, mtk_i2c_irq, + IRQF_TRIGGER_NONE, I2C_DRV_NAME, i2c); + if (ret < 0) { + dev_err(&pdev->dev, + "Request I2C IRQ %d fail\n", i2c->irqnr); + return ret; + } + + i2c->adap.dev.of_node = pdev->dev.of_node; + i2c->dev = &i2c->adap.dev; + i2c->adap.dev.parent = &pdev->dev; + i2c->adap.owner = THIS_MODULE; + i2c->adap.algo = &mtk_i2c_algorithm; + i2c->adap.algo_data = NULL; + i2c->adap.timeout = 2 * HZ; + i2c->adap.retries = 1; + + i2c->clk_main = devm_clk_get(&pdev->dev, "main"); + if (IS_ERR(i2c->clk_main)) { + dev_err(&pdev->dev, "cannot get main clock\n"); + return PTR_ERR(i2c->clk_main); + } + + i2c->clk_dma = devm_clk_get(&pdev->dev, "dma"); + if (IS_ERR(i2c->clk_dma)) { + dev_err(&pdev->dev, "cannot get dma clock\n"); + return PTR_ERR(i2c->clk_dma); + } + + if (i2c->have_pmic) { + i2c->clk_pmic = devm_clk_get(&pdev->dev, "pmic"); + if (IS_ERR(i2c->clk_pmic)) { + dev_err(&pdev->dev, "cannot get pmic clock\n"); + return PTR_ERR(i2c->clk_pmic); + } + clk_src_in_hz = clk_get_rate(i2c->clk_pmic) / clk_src_div; + } else { + clk_src_in_hz = clk_get_rate(i2c->clk_main) / clk_src_div; + } + + dev_dbg(&pdev->dev, "clock source %p,clock src frequency %d\n", + i2c->clk_main, clk_src_in_hz); + strlcpy(i2c->adap.name, I2C_DRV_NAME, sizeof(i2c->adap.name)); + init_waitqueue_head(&i2c->wait); + + ret = i2c_set_speed(i2c, clk_src_in_hz); + if (ret) { + dev_err(&pdev->dev, "Failed to set the speed\n"); + return -EINVAL; + } + + ret = mtk_i2c_clock_enable(i2c); + if (ret) { + dev_err(&pdev->dev, "clock enable failed!\n"); + return ret; + } + mtk_i2c_init_hw(i2c); + mtk_i2c_clock_disable(i2c); + + i2c->dma_buf.vaddr = dma_alloc_coherent(&pdev->dev, + PAGE_SIZE, &i2c->dma_buf.paddr, GFP_KERNEL); + if (i2c->dma_buf.vaddr == NULL) { + dev_err(&pdev->dev, "dma_alloc_coherent fail\n"); + return -ENOMEM; + } + + i2c_set_adapdata(&i2c->adap, i2c); + ret = i2c_add_adapter(&i2c->adap); + if (ret) { + dev_err(&pdev->dev, "Failed to add i2c bus to i2c core\n"); + free_i2c_dma_bufs(i2c); + return ret; + } + + platform_set_drvdata(pdev, i2c); + + return 0; +} + +static int mtk_i2c_remove(struct platform_device *pdev) +{ + struct mtk_i2c *i2c = platform_get_drvdata(pdev); + + i2c_del_adapter(&i2c->adap); + free_i2c_dma_bufs(i2c); + platform_set_drvdata(pdev, NULL); + + return 0; +} + +static struct platform_driver mtk_i2c_driver = { + .probe = mtk_i2c_probe, + .remove = mtk_i2c_remove, + .driver = { + .name = I2C_DRV_NAME, + .owner = THIS_MODULE, + .of_match_table = of_match_ptr(mtk_i2c_of_match), + }, +}; + +module_platform_driver(mtk_i2c_driver); + +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("MediaTek I2C Bus Driver"); +MODULE_AUTHOR("Xudong Chen <xudong.chen@mediatek.com>"); -- 1.8.1.1.dirty ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v3 2/2] I2C: mediatek: Add driver for MediaTek I2C controller @ 2014-11-24 9:38 ` Xudong Chen 0 siblings, 0 replies; 32+ messages in thread From: Xudong Chen @ 2014-11-24 9:38 UTC (permalink / raw) To: linux-arm-kernel The mediatek SoCs have I2C controller that handle I2C transfer. This patch include common I2C bus driver. This driver is compatible with I2C controller on mt65xx/mt81xx. Signed-off-by: Xudong Chen <xudong.chen@mediatek.com> Change-Id: Icc17e326b9df46a226d536956e103f17b0382b6e --- drivers/i2c/busses/Kconfig | 9 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-mt65xx.c | 742 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 752 insertions(+) create mode 100644 drivers/i2c/busses/i2c-mt65xx.c diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 917c358..0d7d0a4 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -564,6 +564,15 @@ config I2C_MPC This driver can also be built as a module. If so, the module will be called i2c-mpc. +config I2C_MT65XX + tristate "MediaTek I2C adapter" + depends on ARCH_MEDIATEK + help + This selects the MediaTek(R) Integrated Inter Circuit bus driver + for MT65xx and MT81xx. + If you want to use MediaTek(R) I2C interface, say Y or M here. + If unsure, say N. + config I2C_MV64XXX tristate "Marvell mv64xxx I2C Controller" depends on MV64X60 || PLAT_ORION || ARCH_SUNXI diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index 78d56c5..7a9f0f3 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_I2C_IMX) += i2c-imx.o obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o obj-$(CONFIG_I2C_KEMPLD) += i2c-kempld.o obj-$(CONFIG_I2C_MPC) += i2c-mpc.o +obj-$(CONFIG_I2C_MT65XX) += i2c-mt65xx.o obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o obj-$(CONFIG_I2C_MXS) += i2c-mxs.o obj-$(CONFIG_I2C_NOMADIK) += i2c-nomadik.o diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c new file mode 100644 index 0000000..09d83b9 --- /dev/null +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -0,0 +1,742 @@ +/* + * Copyright (c) 2014 MediaTek Inc. + * Author: Xudong.chen <xudong.chen@mediatek.com> + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/i2c.h> +#include <linux/init.h> +#include <linux/interrupt.h> +#include <linux/sched.h> +#include <linux/delay.h> +#include <linux/errno.h> +#include <linux/err.h> +#include <linux/device.h> +#include <linux/platform_device.h> +#include <linux/wait.h> +#include <linux/mm.h> +#include <linux/dma-mapping.h> +#include <linux/scatterlist.h> +#include <linux/io.h> +#include <linux/of_address.h> +#include <linux/of_irq.h> +#include <linux/clk.h> + +#define I2C_HS_NACKERR (1 << 2) +#define I2C_ACKERR (1 << 1) +#define I2C_TRANSAC_COMP (1 << 0) +#define I2C_TRANSAC_START (1 << 0) +#define I2C_TIMING_STEP_DIV_MASK (0x3f << 0) +#define I2C_TIMING_SAMPLE_COUNT_MASK (0x7 << 0) +#define I2C_TIMING_SAMPLE_DIV_MASK (0x7 << 8) +#define I2C_TIMING_DATA_READ_MASK (0x7 << 12) +#define I2C_DCM_DISABLE 0x0000 +#define I2C_IO_CONFIG_OPEN_DRAIN 0x0003 +#define I2C_IO_CONFIG_PUSH_PULL 0x0000 +#define I2C_SOFT_RST 0x0001 +#define I2C_FIFO_ADDR_CLR 0x0001 +#define I2C_DELAY_LEN 0x0002 +#define I2C_ST_START_CON 0x8001 +#define I2C_FS_START_CON 0x1800 +#define I2C_TIME_CLR_VALUE 0x0000 +#define I2C_TIME_DEFAULT_VALUE 0x0003 +#define I2C_FS_TIME_INIT_VALUE 0x1303 +#define I2C_WRRD_TRANAC_VALUE 0x0002 +#define I2C_RD_TRANAC_VALUE 0x0001 + +#define I2C_DMA_CON_TX 0x0000 +#define I2C_DMA_CON_RX 0x0001 +#define I2C_DMA_START_EN 0x0001 +#define I2C_DMA_INT_FLAG_NONE 0x0000 +#define I2C_DMA_CLR_FLAG 0x0000 + +#define I2C_DEFAUT_SPEED 100000 /* hz */ +#define MAX_FS_MODE_SPEED 400000 +#define MAX_HS_MODE_SPEED 3400000 +#define MAX_DMA_TRANS_SIZE 255 +#define MAX_WRRD_TRANS_SIZE 32 +#define MAX_SAMPLE_CNT_DIV 8 +#define MAX_STEP_CNT_DIV 64 +#define MAX_HS_STEP_CNT_DIV 8 + +#define I2C_CONTROL_RS (0x1 << 1) +#define I2C_CONTROL_DMA_EN (0x1 << 2) +#define I2C_CONTROL_CLK_EXT_EN (0x1 << 3) +#define I2C_CONTROL_DIR_CHANGE (0x1 << 4) +#define I2C_CONTROL_ACKERR_DET_EN (0x1 << 5) +#define I2C_CONTROL_TRANSFER_LEN_CHANGE (0x1 << 6) +#define I2C_CONTROL_WRAPPER (0x1 << 0) + +#define COMPAT_MT6577 (0x1 << 0) +#define COMPAT_MT6589 (0x1 << 1) + +#define I2C_DRV_NAME "mt-i2c" + +enum DMA_REGS_OFFSET { + OFFSET_INT_FLAG = 0x0, + OFFSET_INT_EN = 0x04, + OFFSET_EN = 0x08, + OFFSET_CON = 0x18, + OFFSET_TX_MEM_ADDR = 0x1c, + OFFSET_RX_MEM_ADDR = 0x20, + OFFSET_TX_LEN = 0x24, + OFFSET_RX_LEN = 0x28, +}; + +enum i2c_trans_st_rs { + I2C_TRANS_STOP = 0, + I2C_TRANS_REPEATED_START, +}; + +enum { + FS_MODE, + HS_MODE, +}; + +enum mtk_trans_op { + I2C_MASTER_WR = 1, + I2C_MASTER_RD, + I2C_MASTER_WRRD, +}; + +enum I2C_REGS_OFFSET { + OFFSET_DATA_PORT = 0x0, + OFFSET_SLAVE_ADDR = 0x04, + OFFSET_INTR_MASK = 0x08, + OFFSET_INTR_STAT = 0x0c, + OFFSET_CONTROL = 0x10, + OFFSET_TRANSFER_LEN = 0x14, + OFFSET_TRANSAC_LEN = 0x18, + OFFSET_DELAY_LEN = 0x1c, + OFFSET_TIMING = 0x20, + OFFSET_START = 0x24, + OFFSET_EXT_CONF = 0x28, + OFFSET_FIFO_STAT = 0x30, + OFFSET_FIFO_THRESH = 0x34, + OFFSET_FIFO_ADDR_CLR = 0x38, + OFFSET_IO_CONFIG = 0x40, + OFFSET_RSV_DEBUG = 0x44, + OFFSET_HS = 0x48, + OFFSET_SOFTRESET = 0x50, + OFFSET_DCM_EN = 0x54, + OFFSET_PATH_DIR = 0x60, + OFFSET_DEBUGSTAT = 0x64, + OFFSET_DEBUGCTRL = 0x68, + OFFSET_TRANSFER_LEN_AUX = 0x6c, +}; + +struct mtk_i2c_data { + unsigned int clk_frequency; /* bus speed in Hz */ + unsigned int flags; + unsigned int clk_src_div; +}; + +struct i2c_dma_buf { + u8 *vaddr; + dma_addr_t paddr; +}; + +struct mtk_i2c { + struct i2c_adapter adap; /* i2c host adapter */ + struct device *dev; + wait_queue_head_t wait; /* i2c transfer wait queue */ + /* set in i2c probe */ + void __iomem *base; /* i2c base addr */ + void __iomem *pdmabase; /* dma base address*/ + int irqnr; /* i2c interrupt number */ + struct i2c_dma_buf dma_buf; /* memory alloc for DMA mode */ + struct clk *clk_main; /* main clock for i2c bus */ + struct clk *clk_dma; /* DMA clock for i2c via DMA */ + struct clk *clk_pmic; /* PMIC clock for i2c from PMIC */ + bool have_pmic; /* can use i2c pins form PMIC */ + bool use_push_pull; /* IO config push-pull mode */ + u32 platform_compat; /* platform compatible data */ + /* set when doing the transfer */ + u16 irq_stat; /* interrupt status */ + unsigned int speed_hz; /* The speed in transfer */ + bool trans_stop; /* i2c transfer stop */ + enum mtk_trans_op op; + u16 msg_len; + u8 *msg_buf; /* pointer to msg data */ + u16 msg_aux_len; /* WRRD mode to set AUX_LEN register*/ + u16 addr; /* 7bit slave address, without read/write bit */ + u16 timing_reg; + u16 high_speed_reg; +}; + +static const struct of_device_id mtk_i2c_of_match[] = { + { .compatible = "mediatek,mt6577-i2c", .data = (void *)COMPAT_MT6577 }, + { .compatible = "mediatek,mt6589-i2c", .data = (void *)COMPAT_MT6589 }, + {}, +}; +MODULE_DEVICE_TABLE(of, mtk_i2c_match); + +static inline void i2c_writew(u16 value, struct mtk_i2c *i2c, u8 offset) +{ + writew(value, i2c->base + offset); +} + +static inline u16 i2c_readw(struct mtk_i2c *i2c, u8 offset) +{ + return readw(i2c->base + offset); +} + +static inline void i2c_writel_dma(u32 value, struct mtk_i2c *i2c, u8 offset) +{ + writel(value, i2c->pdmabase + offset); +} + +static int mtk_i2c_clock_enable(struct mtk_i2c *i2c) +{ + int ret; + + ret = clk_prepare_enable(i2c->clk_dma); + if (ret) + return ret; + + ret = clk_prepare_enable(i2c->clk_main); + if (ret) + goto err_main; + + if (i2c->have_pmic) { + ret = clk_prepare_enable(i2c->clk_pmic); + if (ret) + goto err_pmic; + } + return 0; + +err_pmic: + clk_disable_unprepare(i2c->clk_main); +err_main: + clk_disable_unprepare(i2c->clk_dma); + + return ret; +} + +static void mtk_i2c_clock_disable(struct mtk_i2c *i2c) +{ + if (i2c->have_pmic) + clk_disable_unprepare(i2c->clk_pmic); + + clk_disable_unprepare(i2c->clk_main); + clk_disable_unprepare(i2c->clk_dma); +} + +static void free_i2c_dma_bufs(struct mtk_i2c *i2c) +{ + dma_free_coherent(i2c->adap.dev.parent, PAGE_SIZE, + i2c->dma_buf.vaddr, i2c->dma_buf.paddr); +} + +static inline void mtk_i2c_init_hw(struct mtk_i2c *i2c) +{ + i2c_writew(I2C_SOFT_RST, i2c, OFFSET_SOFTRESET); + /* Set ioconfig */ + if (i2c->use_push_pull) + i2c_writew(I2C_IO_CONFIG_PUSH_PULL, i2c, OFFSET_IO_CONFIG); + else + i2c_writew(I2C_IO_CONFIG_OPEN_DRAIN, i2c, OFFSET_IO_CONFIG); + + if (i2c->platform_compat & COMPAT_MT6577) + i2c_writew(I2C_DCM_DISABLE, i2c, OFFSET_DCM_EN); + + i2c_writew(i2c->timing_reg, i2c, OFFSET_TIMING); + i2c_writew(i2c->high_speed_reg, i2c, OFFSET_HS); +} + +/* calculate i2c port speed */ +static int i2c_set_speed(struct mtk_i2c *i2c, unsigned int clk_src_in_hz) +{ + int mode; + unsigned int khz; + unsigned int step_cnt; + unsigned int sample_cnt; + unsigned int sclk; + unsigned int hclk; + unsigned int max_step_cnt; + unsigned int sample_div = MAX_SAMPLE_CNT_DIV; + unsigned int step_div; + unsigned int min_div; + unsigned int best_mul; + unsigned int cnt_mul; + + if (i2c->speed_hz > MAX_HS_MODE_SPEED) { + return -EINVAL; + } else if (i2c->speed_hz > MAX_FS_MODE_SPEED) { + mode = HS_MODE; + max_step_cnt = MAX_HS_STEP_CNT_DIV; + } else { + mode = FS_MODE; + max_step_cnt = MAX_STEP_CNT_DIV; + } + + step_div = max_step_cnt; + /* Find the best combination */ + khz = i2c->speed_hz / 1000; + hclk = clk_src_in_hz / 1000; + min_div = ((hclk >> 1) + khz - 1) / khz; + best_mul = MAX_SAMPLE_CNT_DIV * max_step_cnt; + + for (sample_cnt = 1; sample_cnt <= MAX_SAMPLE_CNT_DIV; sample_cnt++) { + step_cnt = (min_div + sample_cnt - 1) / sample_cnt; + cnt_mul = step_cnt * sample_cnt; + if (step_cnt > max_step_cnt) + continue; + + if (cnt_mul < best_mul) { + best_mul = cnt_mul; + sample_div = sample_cnt; + step_div = step_cnt; + if (best_mul == min_div) + break; + } + } + + sample_cnt = sample_div; + step_cnt = step_div; + sclk = hclk / (2 * sample_cnt * step_cnt); + if (sclk > khz) { + dev_dbg(i2c->dev, "%s mode: unsupported speed (%ldkhz)\n", + (mode == HS_MODE) ? "HS" : "ST/FT", (long int)khz); + return -ENOTSUPP; + } + + step_cnt--; + sample_cnt--; + + if (mode == HS_MODE) { + /* Set the hign speed mode register */ + i2c->timing_reg = I2C_FS_TIME_INIT_VALUE; + i2c->high_speed_reg = I2C_TIME_DEFAULT_VALUE | + (sample_cnt & I2C_TIMING_SAMPLE_COUNT_MASK) << 12 | + (step_cnt & I2C_TIMING_SAMPLE_COUNT_MASK) << 8; + } else { + i2c->timing_reg = + (sample_cnt & I2C_TIMING_SAMPLE_COUNT_MASK) << 8 | + (step_cnt & I2C_TIMING_STEP_DIV_MASK) << 0; + /* Disable the high speed transaction */ + i2c->high_speed_reg = I2C_TIME_CLR_VALUE; + } + + return 0; +} + +static int mtk_i2c_do_transfer(struct mtk_i2c *i2c) +{ + u16 addr_reg; + u16 control_reg; + int tmo = i2c->adap.timeout; + + i2c->trans_stop = false; + i2c->irq_stat = 0; + + /* If use i2c pin from PMIC mt6397 side, need set PATH_DIR first */ + if (i2c->have_pmic) + i2c_writew(I2C_CONTROL_WRAPPER, i2c, OFFSET_PATH_DIR); + + control_reg = I2C_CONTROL_ACKERR_DET_EN | + I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN; + if (i2c->speed_hz > 400000) + control_reg |= I2C_CONTROL_RS; + if (i2c->op == I2C_MASTER_WRRD) + control_reg |= I2C_CONTROL_DIR_CHANGE | I2C_CONTROL_RS; + i2c_writew(control_reg, i2c, OFFSET_CONTROL); + + /* set start condition */ + if (i2c->speed_hz <= 100000) + i2c_writew(I2C_ST_START_CON, i2c, OFFSET_EXT_CONF); + else + i2c_writew(I2C_FS_START_CON, i2c, OFFSET_EXT_CONF); + + if (~control_reg & I2C_CONTROL_RS) + i2c_writew(I2C_DELAY_LEN, i2c, OFFSET_DELAY_LEN); + + addr_reg = i2c->addr << 1; + if (i2c->op == I2C_MASTER_RD) + addr_reg |= 0x1; + i2c_writew(addr_reg, i2c, OFFSET_SLAVE_ADDR); + + /* Clear interrupt status */ + i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP, + i2c, OFFSET_INTR_STAT); + i2c_writew(I2C_FIFO_ADDR_CLR, i2c, OFFSET_FIFO_ADDR_CLR); + + /* Enable interrupt */ + i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP, + i2c, OFFSET_INTR_MASK); + + /* Set transfer and transaction len */ + if (i2c->op == I2C_MASTER_WRRD) { + i2c_writew(i2c->msg_len | (i2c->msg_aux_len) << 8, + i2c, OFFSET_TRANSFER_LEN); + i2c_writew(I2C_WRRD_TRANAC_VALUE, i2c, OFFSET_TRANSAC_LEN); + } else { + i2c_writew(i2c->msg_len, i2c, OFFSET_TRANSFER_LEN); + i2c_writew(I2C_RD_TRANAC_VALUE, i2c, OFFSET_TRANSAC_LEN); + } + + /* Prepare buffer data to start transfer */ + if (i2c->op == I2C_MASTER_RD) { + i2c_writel_dma(I2C_DMA_INT_FLAG_NONE, i2c, OFFSET_INT_FLAG); + i2c_writel_dma(I2C_DMA_CON_RX, i2c, OFFSET_CON); + i2c_writel_dma((u32)i2c->msg_buf, i2c, OFFSET_RX_MEM_ADDR); + i2c_writel_dma(i2c->msg_len, i2c, OFFSET_RX_LEN); + } else if (i2c->op == I2C_MASTER_WR) { + i2c_writel_dma(I2C_DMA_INT_FLAG_NONE, i2c, OFFSET_INT_FLAG); + i2c_writel_dma(I2C_DMA_CON_TX, i2c, OFFSET_CON); + i2c_writel_dma((u32)i2c->msg_buf, i2c, OFFSET_TX_MEM_ADDR); + i2c_writel_dma(i2c->msg_len, i2c, OFFSET_TX_LEN); + } else { + i2c_writel_dma(I2C_DMA_CLR_FLAG, i2c, OFFSET_INT_FLAG); + i2c_writel_dma(I2C_DMA_CLR_FLAG, i2c, OFFSET_CON); + i2c_writel_dma((u32)i2c->msg_buf, i2c, OFFSET_TX_MEM_ADDR); + i2c_writel_dma((u32)i2c->dma_buf.paddr, i2c, + OFFSET_RX_MEM_ADDR); + i2c_writel_dma(i2c->msg_len, i2c, OFFSET_TX_LEN); + i2c_writel_dma(i2c->msg_aux_len, i2c, OFFSET_RX_LEN); + } + + /* flush before sending start */ + mb(); + i2c_writel_dma(I2C_DMA_START_EN, i2c, OFFSET_EN); + i2c_writew(I2C_TRANSAC_START, i2c, OFFSET_START); + + tmo = wait_event_timeout(i2c->wait, i2c->trans_stop, tmo); + if (tmo == 0) { + dev_dbg(i2c->dev, "addr: %x, transfer timeout\n", i2c->addr); + mtk_i2c_init_hw(i2c); + return -ETIMEDOUT; + } + + if (i2c->irq_stat & (I2C_HS_NACKERR | I2C_ACKERR)) { + dev_dbg(i2c->dev, "addr: %x, transfer ACK error\n", i2c->addr); + mtk_i2c_init_hw(i2c); + return -EREMOTEIO; + } + + dev_dbg(i2c->dev, "i2c transfer done.\n"); + + return 0; +} + +static inline void mtk_i2c_copy_to_dma(struct mtk_i2c *i2c, struct i2c_msg *msg) +{ + /* if the operate is write, need to copy the data to DMA memory */ + if (!(msg->flags & I2C_M_RD)) + memcpy(i2c->dma_buf.vaddr, msg->buf, msg->len); +} + +static inline void mtk_i2c_copy_from_dma(struct mtk_i2c *i2c, + struct i2c_msg *msg) +{ + /* if the operate is read, need to copy the data from DMA memory */ + if (msg->flags & I2C_M_RD) + memcpy(msg->buf, i2c->dma_buf.vaddr, msg->len); +} + +/* + * In MTK platform the STOP will be issued after each + * message was transferred which is not flow the clarify + * for i2c_transfer(), several I2C devices tolerate the STOP, + * but some device need Repeat-Start and do not compatible with STOP + * MTK platform has WRRD mode which can write then read with + * Repeat-Start between two message, so we combined two + * messages into one transaction. + * The max read length is 31 + */ +static bool mtk_i2c_should_combine(struct i2c_msg *msg) +{ + struct i2c_msg *next_msg = msg + 1; + + if ((next_msg->len < MAX_WRRD_TRANS_SIZE) && + msg->addr == next_msg->addr && + !(msg->flags & I2C_M_RD) && + (next_msg->flags & I2C_M_RD) == I2C_M_RD) { + return true; + } + + return false; +} + +static int mtk_i2c_transfer(struct i2c_adapter *adap, + struct i2c_msg msgs[], int num) +{ + int ret; + int left_num = num; + struct mtk_i2c *i2c = i2c_get_adapdata(adap); + + ret = mtk_i2c_clock_enable(i2c); + if (ret) + return ret; + + while (left_num--) { + /* In MTK platform the max transfer number is 255 */ + if (msgs->len > MAX_DMA_TRANS_SIZE) { + dev_dbg(i2c->dev, + " message data length is more than 255\n"); + ret = -EINVAL; + goto err_exit; + } + + if (msgs->addr == 0) { + dev_dbg(i2c->dev, " addr is invalid.\n"); + ret = -EINVAL; + goto err_exit; + } + + if (msgs->buf == NULL) { + dev_dbg(i2c->dev, " data buffer is NULL.\n"); + ret = -EINVAL; + goto err_exit; + } + + i2c->addr = msgs->addr; + i2c->msg_len = msgs->len; + i2c->msg_buf = msgs->buf; + + if (msgs->flags & I2C_M_RD) + i2c->op = I2C_MASTER_RD; + else + i2c->op = I2C_MASTER_WR; + + /* combined two messages into one transaction */ + if (left_num >= 1 && mtk_i2c_should_combine(msgs)) { + i2c->msg_aux_len = (msgs + 1)->len; + i2c->op = I2C_MASTER_WRRD; + left_num--; + } + + /* + * always use DMA mode. + * 1st when write need copy the data of message to dma memory + * 2nd when read need copy the DMA data to the message buffer. + * The length should be less than 255. + */ + mtk_i2c_copy_to_dma(i2c, msgs); + i2c->msg_buf = (u8 *)i2c->dma_buf.paddr; + ret = mtk_i2c_do_transfer(i2c); + if (ret < 0) + goto err_exit; + + if (i2c->op == I2C_MASTER_WRRD) + mtk_i2c_copy_from_dma(i2c, msgs + 1); + else + mtk_i2c_copy_from_dma(i2c, msgs); + + msgs++; + + /* after combined two messages so we need ignore one */ + if (left_num > 0 && i2c->op == I2C_MASTER_WRRD) + msgs++; + } + /* the return value is number of executed messages */ + ret = num; + +err_exit: + mtk_i2c_clock_disable(i2c); + return ret; +} + +static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id) +{ + struct mtk_i2c *i2c = dev_id; + + /* Clear interrupt mask */ + i2c_writew(~(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP), + i2c, OFFSET_INTR_MASK); + + i2c->irq_stat = i2c_readw(i2c, OFFSET_INTR_STAT); + i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP, + i2c, OFFSET_INTR_STAT); + i2c->trans_stop = true; + wake_up(&i2c->wait); + + return IRQ_HANDLED; +} + +static u32 mtk_i2c_functionality(struct i2c_adapter *adap) +{ + return I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR | I2C_FUNC_SMBUS_EMUL; +} + +static const struct i2c_algorithm mtk_i2c_algorithm = { + .master_xfer = mtk_i2c_transfer, + .functionality = mtk_i2c_functionality, +}; + +static inline u32 mtk_get_device_prop(struct platform_device *pdev) +{ + const struct of_device_id *match; + + match = of_match_node(mtk_i2c_of_match, pdev->dev.of_node); + return (u32)match->data; +} + +static int mtk_i2c_parse_dt(struct device_node *np, struct mtk_i2c *i2c, + unsigned int *clk_src_div) +{ + i2c->speed_hz = I2C_DEFAUT_SPEED; + of_property_read_u32(np, "clock-frequency", &i2c->speed_hz); + of_property_read_u32(np, "clock-div", clk_src_div); + if (*clk_src_div == 0) + return -EINVAL; + + i2c->have_pmic = of_property_read_bool(np, "mediatek,have-pmic"); + i2c->use_push_pull = + of_property_read_bool(np, "mediatek,use-push-pull"); + + return 0; +} + +static int mtk_i2c_probe(struct platform_device *pdev) +{ + int ret = 0; + struct mtk_i2c *i2c; + unsigned int clk_src_in_hz; + unsigned int clk_src_div; + struct resource *res; + + i2c = devm_kzalloc(&pdev->dev, sizeof(struct mtk_i2c), GFP_KERNEL); + if (i2c == NULL) + return -ENOMEM; + + ret = mtk_i2c_parse_dt(pdev->dev.of_node, i2c, &clk_src_div); + if (ret) + return -EINVAL; + + i2c->platform_compat = mtk_get_device_prop(pdev); + if (i2c->have_pmic && (i2c->platform_compat & COMPAT_MT6577)) + return -EINVAL; + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + + i2c->base = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(i2c->base)) + return PTR_ERR(i2c->base); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 1); + + i2c->pdmabase = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(i2c->pdmabase)) + return PTR_ERR(i2c->pdmabase); + + i2c->irqnr = platform_get_irq(pdev, 0); + if (i2c->irqnr <= 0) + return -EINVAL; + + ret = devm_request_irq(&pdev->dev, i2c->irqnr, mtk_i2c_irq, + IRQF_TRIGGER_NONE, I2C_DRV_NAME, i2c); + if (ret < 0) { + dev_err(&pdev->dev, + "Request I2C IRQ %d fail\n", i2c->irqnr); + return ret; + } + + i2c->adap.dev.of_node = pdev->dev.of_node; + i2c->dev = &i2c->adap.dev; + i2c->adap.dev.parent = &pdev->dev; + i2c->adap.owner = THIS_MODULE; + i2c->adap.algo = &mtk_i2c_algorithm; + i2c->adap.algo_data = NULL; + i2c->adap.timeout = 2 * HZ; + i2c->adap.retries = 1; + + i2c->clk_main = devm_clk_get(&pdev->dev, "main"); + if (IS_ERR(i2c->clk_main)) { + dev_err(&pdev->dev, "cannot get main clock\n"); + return PTR_ERR(i2c->clk_main); + } + + i2c->clk_dma = devm_clk_get(&pdev->dev, "dma"); + if (IS_ERR(i2c->clk_dma)) { + dev_err(&pdev->dev, "cannot get dma clock\n"); + return PTR_ERR(i2c->clk_dma); + } + + if (i2c->have_pmic) { + i2c->clk_pmic = devm_clk_get(&pdev->dev, "pmic"); + if (IS_ERR(i2c->clk_pmic)) { + dev_err(&pdev->dev, "cannot get pmic clock\n"); + return PTR_ERR(i2c->clk_pmic); + } + clk_src_in_hz = clk_get_rate(i2c->clk_pmic) / clk_src_div; + } else { + clk_src_in_hz = clk_get_rate(i2c->clk_main) / clk_src_div; + } + + dev_dbg(&pdev->dev, "clock source %p,clock src frequency %d\n", + i2c->clk_main, clk_src_in_hz); + strlcpy(i2c->adap.name, I2C_DRV_NAME, sizeof(i2c->adap.name)); + init_waitqueue_head(&i2c->wait); + + ret = i2c_set_speed(i2c, clk_src_in_hz); + if (ret) { + dev_err(&pdev->dev, "Failed to set the speed\n"); + return -EINVAL; + } + + ret = mtk_i2c_clock_enable(i2c); + if (ret) { + dev_err(&pdev->dev, "clock enable failed!\n"); + return ret; + } + mtk_i2c_init_hw(i2c); + mtk_i2c_clock_disable(i2c); + + i2c->dma_buf.vaddr = dma_alloc_coherent(&pdev->dev, + PAGE_SIZE, &i2c->dma_buf.paddr, GFP_KERNEL); + if (i2c->dma_buf.vaddr == NULL) { + dev_err(&pdev->dev, "dma_alloc_coherent fail\n"); + return -ENOMEM; + } + + i2c_set_adapdata(&i2c->adap, i2c); + ret = i2c_add_adapter(&i2c->adap); + if (ret) { + dev_err(&pdev->dev, "Failed to add i2c bus to i2c core\n"); + free_i2c_dma_bufs(i2c); + return ret; + } + + platform_set_drvdata(pdev, i2c); + + return 0; +} + +static int mtk_i2c_remove(struct platform_device *pdev) +{ + struct mtk_i2c *i2c = platform_get_drvdata(pdev); + + i2c_del_adapter(&i2c->adap); + free_i2c_dma_bufs(i2c); + platform_set_drvdata(pdev, NULL); + + return 0; +} + +static struct platform_driver mtk_i2c_driver = { + .probe = mtk_i2c_probe, + .remove = mtk_i2c_remove, + .driver = { + .name = I2C_DRV_NAME, + .owner = THIS_MODULE, + .of_match_table = of_match_ptr(mtk_i2c_of_match), + }, +}; + +module_platform_driver(mtk_i2c_driver); + +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("MediaTek I2C Bus Driver"); +MODULE_AUTHOR("Xudong Chen <xudong.chen@mediatek.com>"); -- 1.8.1.1.dirty ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v3 2/2] I2C: mediatek: Add driver for MediaTek I2C controller @ 2014-11-24 9:38 ` Xudong Chen 0 siblings, 0 replies; 32+ messages in thread From: Xudong Chen @ 2014-11-24 9:38 UTC (permalink / raw) To: Mark Rutland, Matthias Brugger, Wolfram Sang Cc: srv_heupstream, Sascha Hauer, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, Russell King, Grant Likely, Xudong Chen, Jean Delvare, Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, linux-i2c, Yingjoe Chen, Eddie Huang, Nathan Chung, YH Chen The mediatek SoCs have I2C controller that handle I2C transfer. This patch include common I2C bus driver. This driver is compatible with I2C controller on mt65xx/mt81xx. Signed-off-by: Xudong Chen <xudong.chen@mediatek.com> Change-Id: Icc17e326b9df46a226d536956e103f17b0382b6e --- drivers/i2c/busses/Kconfig | 9 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-mt65xx.c | 742 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 752 insertions(+) create mode 100644 drivers/i2c/busses/i2c-mt65xx.c diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 917c358..0d7d0a4 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -564,6 +564,15 @@ config I2C_MPC This driver can also be built as a module. If so, the module will be called i2c-mpc. +config I2C_MT65XX + tristate "MediaTek I2C adapter" + depends on ARCH_MEDIATEK + help + This selects the MediaTek(R) Integrated Inter Circuit bus driver + for MT65xx and MT81xx. + If you want to use MediaTek(R) I2C interface, say Y or M here. + If unsure, say N. + config I2C_MV64XXX tristate "Marvell mv64xxx I2C Controller" depends on MV64X60 || PLAT_ORION || ARCH_SUNXI diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index 78d56c5..7a9f0f3 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_I2C_IMX) += i2c-imx.o obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o obj-$(CONFIG_I2C_KEMPLD) += i2c-kempld.o obj-$(CONFIG_I2C_MPC) += i2c-mpc.o +obj-$(CONFIG_I2C_MT65XX) += i2c-mt65xx.o obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o obj-$(CONFIG_I2C_MXS) += i2c-mxs.o obj-$(CONFIG_I2C_NOMADIK) += i2c-nomadik.o diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c new file mode 100644 index 0000000..09d83b9 --- /dev/null +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -0,0 +1,742 @@ +/* + * Copyright (c) 2014 MediaTek Inc. + * Author: Xudong.chen <xudong.chen@mediatek.com> + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/i2c.h> +#include <linux/init.h> +#include <linux/interrupt.h> +#include <linux/sched.h> +#include <linux/delay.h> +#include <linux/errno.h> +#include <linux/err.h> +#include <linux/device.h> +#include <linux/platform_device.h> +#include <linux/wait.h> +#include <linux/mm.h> +#include <linux/dma-mapping.h> +#include <linux/scatterlist.h> +#include <linux/io.h> +#include <linux/of_address.h> +#include <linux/of_irq.h> +#include <linux/clk.h> + +#define I2C_HS_NACKERR (1 << 2) +#define I2C_ACKERR (1 << 1) +#define I2C_TRANSAC_COMP (1 << 0) +#define I2C_TRANSAC_START (1 << 0) +#define I2C_TIMING_STEP_DIV_MASK (0x3f << 0) +#define I2C_TIMING_SAMPLE_COUNT_MASK (0x7 << 0) +#define I2C_TIMING_SAMPLE_DIV_MASK (0x7 << 8) +#define I2C_TIMING_DATA_READ_MASK (0x7 << 12) +#define I2C_DCM_DISABLE 0x0000 +#define I2C_IO_CONFIG_OPEN_DRAIN 0x0003 +#define I2C_IO_CONFIG_PUSH_PULL 0x0000 +#define I2C_SOFT_RST 0x0001 +#define I2C_FIFO_ADDR_CLR 0x0001 +#define I2C_DELAY_LEN 0x0002 +#define I2C_ST_START_CON 0x8001 +#define I2C_FS_START_CON 0x1800 +#define I2C_TIME_CLR_VALUE 0x0000 +#define I2C_TIME_DEFAULT_VALUE 0x0003 +#define I2C_FS_TIME_INIT_VALUE 0x1303 +#define I2C_WRRD_TRANAC_VALUE 0x0002 +#define I2C_RD_TRANAC_VALUE 0x0001 + +#define I2C_DMA_CON_TX 0x0000 +#define I2C_DMA_CON_RX 0x0001 +#define I2C_DMA_START_EN 0x0001 +#define I2C_DMA_INT_FLAG_NONE 0x0000 +#define I2C_DMA_CLR_FLAG 0x0000 + +#define I2C_DEFAUT_SPEED 100000 /* hz */ +#define MAX_FS_MODE_SPEED 400000 +#define MAX_HS_MODE_SPEED 3400000 +#define MAX_DMA_TRANS_SIZE 255 +#define MAX_WRRD_TRANS_SIZE 32 +#define MAX_SAMPLE_CNT_DIV 8 +#define MAX_STEP_CNT_DIV 64 +#define MAX_HS_STEP_CNT_DIV 8 + +#define I2C_CONTROL_RS (0x1 << 1) +#define I2C_CONTROL_DMA_EN (0x1 << 2) +#define I2C_CONTROL_CLK_EXT_EN (0x1 << 3) +#define I2C_CONTROL_DIR_CHANGE (0x1 << 4) +#define I2C_CONTROL_ACKERR_DET_EN (0x1 << 5) +#define I2C_CONTROL_TRANSFER_LEN_CHANGE (0x1 << 6) +#define I2C_CONTROL_WRAPPER (0x1 << 0) + +#define COMPAT_MT6577 (0x1 << 0) +#define COMPAT_MT6589 (0x1 << 1) + +#define I2C_DRV_NAME "mt-i2c" + +enum DMA_REGS_OFFSET { + OFFSET_INT_FLAG = 0x0, + OFFSET_INT_EN = 0x04, + OFFSET_EN = 0x08, + OFFSET_CON = 0x18, + OFFSET_TX_MEM_ADDR = 0x1c, + OFFSET_RX_MEM_ADDR = 0x20, + OFFSET_TX_LEN = 0x24, + OFFSET_RX_LEN = 0x28, +}; + +enum i2c_trans_st_rs { + I2C_TRANS_STOP = 0, + I2C_TRANS_REPEATED_START, +}; + +enum { + FS_MODE, + HS_MODE, +}; + +enum mtk_trans_op { + I2C_MASTER_WR = 1, + I2C_MASTER_RD, + I2C_MASTER_WRRD, +}; + +enum I2C_REGS_OFFSET { + OFFSET_DATA_PORT = 0x0, + OFFSET_SLAVE_ADDR = 0x04, + OFFSET_INTR_MASK = 0x08, + OFFSET_INTR_STAT = 0x0c, + OFFSET_CONTROL = 0x10, + OFFSET_TRANSFER_LEN = 0x14, + OFFSET_TRANSAC_LEN = 0x18, + OFFSET_DELAY_LEN = 0x1c, + OFFSET_TIMING = 0x20, + OFFSET_START = 0x24, + OFFSET_EXT_CONF = 0x28, + OFFSET_FIFO_STAT = 0x30, + OFFSET_FIFO_THRESH = 0x34, + OFFSET_FIFO_ADDR_CLR = 0x38, + OFFSET_IO_CONFIG = 0x40, + OFFSET_RSV_DEBUG = 0x44, + OFFSET_HS = 0x48, + OFFSET_SOFTRESET = 0x50, + OFFSET_DCM_EN = 0x54, + OFFSET_PATH_DIR = 0x60, + OFFSET_DEBUGSTAT = 0x64, + OFFSET_DEBUGCTRL = 0x68, + OFFSET_TRANSFER_LEN_AUX = 0x6c, +}; + +struct mtk_i2c_data { + unsigned int clk_frequency; /* bus speed in Hz */ + unsigned int flags; + unsigned int clk_src_div; +}; + +struct i2c_dma_buf { + u8 *vaddr; + dma_addr_t paddr; +}; + +struct mtk_i2c { + struct i2c_adapter adap; /* i2c host adapter */ + struct device *dev; + wait_queue_head_t wait; /* i2c transfer wait queue */ + /* set in i2c probe */ + void __iomem *base; /* i2c base addr */ + void __iomem *pdmabase; /* dma base address*/ + int irqnr; /* i2c interrupt number */ + struct i2c_dma_buf dma_buf; /* memory alloc for DMA mode */ + struct clk *clk_main; /* main clock for i2c bus */ + struct clk *clk_dma; /* DMA clock for i2c via DMA */ + struct clk *clk_pmic; /* PMIC clock for i2c from PMIC */ + bool have_pmic; /* can use i2c pins form PMIC */ + bool use_push_pull; /* IO config push-pull mode */ + u32 platform_compat; /* platform compatible data */ + /* set when doing the transfer */ + u16 irq_stat; /* interrupt status */ + unsigned int speed_hz; /* The speed in transfer */ + bool trans_stop; /* i2c transfer stop */ + enum mtk_trans_op op; + u16 msg_len; + u8 *msg_buf; /* pointer to msg data */ + u16 msg_aux_len; /* WRRD mode to set AUX_LEN register*/ + u16 addr; /* 7bit slave address, without read/write bit */ + u16 timing_reg; + u16 high_speed_reg; +}; + +static const struct of_device_id mtk_i2c_of_match[] = { + { .compatible = "mediatek,mt6577-i2c", .data = (void *)COMPAT_MT6577 }, + { .compatible = "mediatek,mt6589-i2c", .data = (void *)COMPAT_MT6589 }, + {}, +}; +MODULE_DEVICE_TABLE(of, mtk_i2c_match); + +static inline void i2c_writew(u16 value, struct mtk_i2c *i2c, u8 offset) +{ + writew(value, i2c->base + offset); +} + +static inline u16 i2c_readw(struct mtk_i2c *i2c, u8 offset) +{ + return readw(i2c->base + offset); +} + +static inline void i2c_writel_dma(u32 value, struct mtk_i2c *i2c, u8 offset) +{ + writel(value, i2c->pdmabase + offset); +} + +static int mtk_i2c_clock_enable(struct mtk_i2c *i2c) +{ + int ret; + + ret = clk_prepare_enable(i2c->clk_dma); + if (ret) + return ret; + + ret = clk_prepare_enable(i2c->clk_main); + if (ret) + goto err_main; + + if (i2c->have_pmic) { + ret = clk_prepare_enable(i2c->clk_pmic); + if (ret) + goto err_pmic; + } + return 0; + +err_pmic: + clk_disable_unprepare(i2c->clk_main); +err_main: + clk_disable_unprepare(i2c->clk_dma); + + return ret; +} + +static void mtk_i2c_clock_disable(struct mtk_i2c *i2c) +{ + if (i2c->have_pmic) + clk_disable_unprepare(i2c->clk_pmic); + + clk_disable_unprepare(i2c->clk_main); + clk_disable_unprepare(i2c->clk_dma); +} + +static void free_i2c_dma_bufs(struct mtk_i2c *i2c) +{ + dma_free_coherent(i2c->adap.dev.parent, PAGE_SIZE, + i2c->dma_buf.vaddr, i2c->dma_buf.paddr); +} + +static inline void mtk_i2c_init_hw(struct mtk_i2c *i2c) +{ + i2c_writew(I2C_SOFT_RST, i2c, OFFSET_SOFTRESET); + /* Set ioconfig */ + if (i2c->use_push_pull) + i2c_writew(I2C_IO_CONFIG_PUSH_PULL, i2c, OFFSET_IO_CONFIG); + else + i2c_writew(I2C_IO_CONFIG_OPEN_DRAIN, i2c, OFFSET_IO_CONFIG); + + if (i2c->platform_compat & COMPAT_MT6577) + i2c_writew(I2C_DCM_DISABLE, i2c, OFFSET_DCM_EN); + + i2c_writew(i2c->timing_reg, i2c, OFFSET_TIMING); + i2c_writew(i2c->high_speed_reg, i2c, OFFSET_HS); +} + +/* calculate i2c port speed */ +static int i2c_set_speed(struct mtk_i2c *i2c, unsigned int clk_src_in_hz) +{ + int mode; + unsigned int khz; + unsigned int step_cnt; + unsigned int sample_cnt; + unsigned int sclk; + unsigned int hclk; + unsigned int max_step_cnt; + unsigned int sample_div = MAX_SAMPLE_CNT_DIV; + unsigned int step_div; + unsigned int min_div; + unsigned int best_mul; + unsigned int cnt_mul; + + if (i2c->speed_hz > MAX_HS_MODE_SPEED) { + return -EINVAL; + } else if (i2c->speed_hz > MAX_FS_MODE_SPEED) { + mode = HS_MODE; + max_step_cnt = MAX_HS_STEP_CNT_DIV; + } else { + mode = FS_MODE; + max_step_cnt = MAX_STEP_CNT_DIV; + } + + step_div = max_step_cnt; + /* Find the best combination */ + khz = i2c->speed_hz / 1000; + hclk = clk_src_in_hz / 1000; + min_div = ((hclk >> 1) + khz - 1) / khz; + best_mul = MAX_SAMPLE_CNT_DIV * max_step_cnt; + + for (sample_cnt = 1; sample_cnt <= MAX_SAMPLE_CNT_DIV; sample_cnt++) { + step_cnt = (min_div + sample_cnt - 1) / sample_cnt; + cnt_mul = step_cnt * sample_cnt; + if (step_cnt > max_step_cnt) + continue; + + if (cnt_mul < best_mul) { + best_mul = cnt_mul; + sample_div = sample_cnt; + step_div = step_cnt; + if (best_mul == min_div) + break; + } + } + + sample_cnt = sample_div; + step_cnt = step_div; + sclk = hclk / (2 * sample_cnt * step_cnt); + if (sclk > khz) { + dev_dbg(i2c->dev, "%s mode: unsupported speed (%ldkhz)\n", + (mode == HS_MODE) ? "HS" : "ST/FT", (long int)khz); + return -ENOTSUPP; + } + + step_cnt--; + sample_cnt--; + + if (mode == HS_MODE) { + /* Set the hign speed mode register */ + i2c->timing_reg = I2C_FS_TIME_INIT_VALUE; + i2c->high_speed_reg = I2C_TIME_DEFAULT_VALUE | + (sample_cnt & I2C_TIMING_SAMPLE_COUNT_MASK) << 12 | + (step_cnt & I2C_TIMING_SAMPLE_COUNT_MASK) << 8; + } else { + i2c->timing_reg = + (sample_cnt & I2C_TIMING_SAMPLE_COUNT_MASK) << 8 | + (step_cnt & I2C_TIMING_STEP_DIV_MASK) << 0; + /* Disable the high speed transaction */ + i2c->high_speed_reg = I2C_TIME_CLR_VALUE; + } + + return 0; +} + +static int mtk_i2c_do_transfer(struct mtk_i2c *i2c) +{ + u16 addr_reg; + u16 control_reg; + int tmo = i2c->adap.timeout; + + i2c->trans_stop = false; + i2c->irq_stat = 0; + + /* If use i2c pin from PMIC mt6397 side, need set PATH_DIR first */ + if (i2c->have_pmic) + i2c_writew(I2C_CONTROL_WRAPPER, i2c, OFFSET_PATH_DIR); + + control_reg = I2C_CONTROL_ACKERR_DET_EN | + I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN; + if (i2c->speed_hz > 400000) + control_reg |= I2C_CONTROL_RS; + if (i2c->op == I2C_MASTER_WRRD) + control_reg |= I2C_CONTROL_DIR_CHANGE | I2C_CONTROL_RS; + i2c_writew(control_reg, i2c, OFFSET_CONTROL); + + /* set start condition */ + if (i2c->speed_hz <= 100000) + i2c_writew(I2C_ST_START_CON, i2c, OFFSET_EXT_CONF); + else + i2c_writew(I2C_FS_START_CON, i2c, OFFSET_EXT_CONF); + + if (~control_reg & I2C_CONTROL_RS) + i2c_writew(I2C_DELAY_LEN, i2c, OFFSET_DELAY_LEN); + + addr_reg = i2c->addr << 1; + if (i2c->op == I2C_MASTER_RD) + addr_reg |= 0x1; + i2c_writew(addr_reg, i2c, OFFSET_SLAVE_ADDR); + + /* Clear interrupt status */ + i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP, + i2c, OFFSET_INTR_STAT); + i2c_writew(I2C_FIFO_ADDR_CLR, i2c, OFFSET_FIFO_ADDR_CLR); + + /* Enable interrupt */ + i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP, + i2c, OFFSET_INTR_MASK); + + /* Set transfer and transaction len */ + if (i2c->op == I2C_MASTER_WRRD) { + i2c_writew(i2c->msg_len | (i2c->msg_aux_len) << 8, + i2c, OFFSET_TRANSFER_LEN); + i2c_writew(I2C_WRRD_TRANAC_VALUE, i2c, OFFSET_TRANSAC_LEN); + } else { + i2c_writew(i2c->msg_len, i2c, OFFSET_TRANSFER_LEN); + i2c_writew(I2C_RD_TRANAC_VALUE, i2c, OFFSET_TRANSAC_LEN); + } + + /* Prepare buffer data to start transfer */ + if (i2c->op == I2C_MASTER_RD) { + i2c_writel_dma(I2C_DMA_INT_FLAG_NONE, i2c, OFFSET_INT_FLAG); + i2c_writel_dma(I2C_DMA_CON_RX, i2c, OFFSET_CON); + i2c_writel_dma((u32)i2c->msg_buf, i2c, OFFSET_RX_MEM_ADDR); + i2c_writel_dma(i2c->msg_len, i2c, OFFSET_RX_LEN); + } else if (i2c->op == I2C_MASTER_WR) { + i2c_writel_dma(I2C_DMA_INT_FLAG_NONE, i2c, OFFSET_INT_FLAG); + i2c_writel_dma(I2C_DMA_CON_TX, i2c, OFFSET_CON); + i2c_writel_dma((u32)i2c->msg_buf, i2c, OFFSET_TX_MEM_ADDR); + i2c_writel_dma(i2c->msg_len, i2c, OFFSET_TX_LEN); + } else { + i2c_writel_dma(I2C_DMA_CLR_FLAG, i2c, OFFSET_INT_FLAG); + i2c_writel_dma(I2C_DMA_CLR_FLAG, i2c, OFFSET_CON); + i2c_writel_dma((u32)i2c->msg_buf, i2c, OFFSET_TX_MEM_ADDR); + i2c_writel_dma((u32)i2c->dma_buf.paddr, i2c, + OFFSET_RX_MEM_ADDR); + i2c_writel_dma(i2c->msg_len, i2c, OFFSET_TX_LEN); + i2c_writel_dma(i2c->msg_aux_len, i2c, OFFSET_RX_LEN); + } + + /* flush before sending start */ + mb(); + i2c_writel_dma(I2C_DMA_START_EN, i2c, OFFSET_EN); + i2c_writew(I2C_TRANSAC_START, i2c, OFFSET_START); + + tmo = wait_event_timeout(i2c->wait, i2c->trans_stop, tmo); + if (tmo == 0) { + dev_dbg(i2c->dev, "addr: %x, transfer timeout\n", i2c->addr); + mtk_i2c_init_hw(i2c); + return -ETIMEDOUT; + } + + if (i2c->irq_stat & (I2C_HS_NACKERR | I2C_ACKERR)) { + dev_dbg(i2c->dev, "addr: %x, transfer ACK error\n", i2c->addr); + mtk_i2c_init_hw(i2c); + return -EREMOTEIO; + } + + dev_dbg(i2c->dev, "i2c transfer done.\n"); + + return 0; +} + +static inline void mtk_i2c_copy_to_dma(struct mtk_i2c *i2c, struct i2c_msg *msg) +{ + /* if the operate is write, need to copy the data to DMA memory */ + if (!(msg->flags & I2C_M_RD)) + memcpy(i2c->dma_buf.vaddr, msg->buf, msg->len); +} + +static inline void mtk_i2c_copy_from_dma(struct mtk_i2c *i2c, + struct i2c_msg *msg) +{ + /* if the operate is read, need to copy the data from DMA memory */ + if (msg->flags & I2C_M_RD) + memcpy(msg->buf, i2c->dma_buf.vaddr, msg->len); +} + +/* + * In MTK platform the STOP will be issued after each + * message was transferred which is not flow the clarify + * for i2c_transfer(), several I2C devices tolerate the STOP, + * but some device need Repeat-Start and do not compatible with STOP + * MTK platform has WRRD mode which can write then read with + * Repeat-Start between two message, so we combined two + * messages into one transaction. + * The max read length is 31 + */ +static bool mtk_i2c_should_combine(struct i2c_msg *msg) +{ + struct i2c_msg *next_msg = msg + 1; + + if ((next_msg->len < MAX_WRRD_TRANS_SIZE) && + msg->addr == next_msg->addr && + !(msg->flags & I2C_M_RD) && + (next_msg->flags & I2C_M_RD) == I2C_M_RD) { + return true; + } + + return false; +} + +static int mtk_i2c_transfer(struct i2c_adapter *adap, + struct i2c_msg msgs[], int num) +{ + int ret; + int left_num = num; + struct mtk_i2c *i2c = i2c_get_adapdata(adap); + + ret = mtk_i2c_clock_enable(i2c); + if (ret) + return ret; + + while (left_num--) { + /* In MTK platform the max transfer number is 255 */ + if (msgs->len > MAX_DMA_TRANS_SIZE) { + dev_dbg(i2c->dev, + " message data length is more than 255\n"); + ret = -EINVAL; + goto err_exit; + } + + if (msgs->addr == 0) { + dev_dbg(i2c->dev, " addr is invalid.\n"); + ret = -EINVAL; + goto err_exit; + } + + if (msgs->buf == NULL) { + dev_dbg(i2c->dev, " data buffer is NULL.\n"); + ret = -EINVAL; + goto err_exit; + } + + i2c->addr = msgs->addr; + i2c->msg_len = msgs->len; + i2c->msg_buf = msgs->buf; + + if (msgs->flags & I2C_M_RD) + i2c->op = I2C_MASTER_RD; + else + i2c->op = I2C_MASTER_WR; + + /* combined two messages into one transaction */ + if (left_num >= 1 && mtk_i2c_should_combine(msgs)) { + i2c->msg_aux_len = (msgs + 1)->len; + i2c->op = I2C_MASTER_WRRD; + left_num--; + } + + /* + * always use DMA mode. + * 1st when write need copy the data of message to dma memory + * 2nd when read need copy the DMA data to the message buffer. + * The length should be less than 255. + */ + mtk_i2c_copy_to_dma(i2c, msgs); + i2c->msg_buf = (u8 *)i2c->dma_buf.paddr; + ret = mtk_i2c_do_transfer(i2c); + if (ret < 0) + goto err_exit; + + if (i2c->op == I2C_MASTER_WRRD) + mtk_i2c_copy_from_dma(i2c, msgs + 1); + else + mtk_i2c_copy_from_dma(i2c, msgs); + + msgs++; + + /* after combined two messages so we need ignore one */ + if (left_num > 0 && i2c->op == I2C_MASTER_WRRD) + msgs++; + } + /* the return value is number of executed messages */ + ret = num; + +err_exit: + mtk_i2c_clock_disable(i2c); + return ret; +} + +static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id) +{ + struct mtk_i2c *i2c = dev_id; + + /* Clear interrupt mask */ + i2c_writew(~(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP), + i2c, OFFSET_INTR_MASK); + + i2c->irq_stat = i2c_readw(i2c, OFFSET_INTR_STAT); + i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP, + i2c, OFFSET_INTR_STAT); + i2c->trans_stop = true; + wake_up(&i2c->wait); + + return IRQ_HANDLED; +} + +static u32 mtk_i2c_functionality(struct i2c_adapter *adap) +{ + return I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR | I2C_FUNC_SMBUS_EMUL; +} + +static const struct i2c_algorithm mtk_i2c_algorithm = { + .master_xfer = mtk_i2c_transfer, + .functionality = mtk_i2c_functionality, +}; + +static inline u32 mtk_get_device_prop(struct platform_device *pdev) +{ + const struct of_device_id *match; + + match = of_match_node(mtk_i2c_of_match, pdev->dev.of_node); + return (u32)match->data; +} + +static int mtk_i2c_parse_dt(struct device_node *np, struct mtk_i2c *i2c, + unsigned int *clk_src_div) +{ + i2c->speed_hz = I2C_DEFAUT_SPEED; + of_property_read_u32(np, "clock-frequency", &i2c->speed_hz); + of_property_read_u32(np, "clock-div", clk_src_div); + if (*clk_src_div == 0) + return -EINVAL; + + i2c->have_pmic = of_property_read_bool(np, "mediatek,have-pmic"); + i2c->use_push_pull = + of_property_read_bool(np, "mediatek,use-push-pull"); + + return 0; +} + +static int mtk_i2c_probe(struct platform_device *pdev) +{ + int ret = 0; + struct mtk_i2c *i2c; + unsigned int clk_src_in_hz; + unsigned int clk_src_div; + struct resource *res; + + i2c = devm_kzalloc(&pdev->dev, sizeof(struct mtk_i2c), GFP_KERNEL); + if (i2c == NULL) + return -ENOMEM; + + ret = mtk_i2c_parse_dt(pdev->dev.of_node, i2c, &clk_src_div); + if (ret) + return -EINVAL; + + i2c->platform_compat = mtk_get_device_prop(pdev); + if (i2c->have_pmic && (i2c->platform_compat & COMPAT_MT6577)) + return -EINVAL; + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + + i2c->base = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(i2c->base)) + return PTR_ERR(i2c->base); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 1); + + i2c->pdmabase = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(i2c->pdmabase)) + return PTR_ERR(i2c->pdmabase); + + i2c->irqnr = platform_get_irq(pdev, 0); + if (i2c->irqnr <= 0) + return -EINVAL; + + ret = devm_request_irq(&pdev->dev, i2c->irqnr, mtk_i2c_irq, + IRQF_TRIGGER_NONE, I2C_DRV_NAME, i2c); + if (ret < 0) { + dev_err(&pdev->dev, + "Request I2C IRQ %d fail\n", i2c->irqnr); + return ret; + } + + i2c->adap.dev.of_node = pdev->dev.of_node; + i2c->dev = &i2c->adap.dev; + i2c->adap.dev.parent = &pdev->dev; + i2c->adap.owner = THIS_MODULE; + i2c->adap.algo = &mtk_i2c_algorithm; + i2c->adap.algo_data = NULL; + i2c->adap.timeout = 2 * HZ; + i2c->adap.retries = 1; + + i2c->clk_main = devm_clk_get(&pdev->dev, "main"); + if (IS_ERR(i2c->clk_main)) { + dev_err(&pdev->dev, "cannot get main clock\n"); + return PTR_ERR(i2c->clk_main); + } + + i2c->clk_dma = devm_clk_get(&pdev->dev, "dma"); + if (IS_ERR(i2c->clk_dma)) { + dev_err(&pdev->dev, "cannot get dma clock\n"); + return PTR_ERR(i2c->clk_dma); + } + + if (i2c->have_pmic) { + i2c->clk_pmic = devm_clk_get(&pdev->dev, "pmic"); + if (IS_ERR(i2c->clk_pmic)) { + dev_err(&pdev->dev, "cannot get pmic clock\n"); + return PTR_ERR(i2c->clk_pmic); + } + clk_src_in_hz = clk_get_rate(i2c->clk_pmic) / clk_src_div; + } else { + clk_src_in_hz = clk_get_rate(i2c->clk_main) / clk_src_div; + } + + dev_dbg(&pdev->dev, "clock source %p,clock src frequency %d\n", + i2c->clk_main, clk_src_in_hz); + strlcpy(i2c->adap.name, I2C_DRV_NAME, sizeof(i2c->adap.name)); + init_waitqueue_head(&i2c->wait); + + ret = i2c_set_speed(i2c, clk_src_in_hz); + if (ret) { + dev_err(&pdev->dev, "Failed to set the speed\n"); + return -EINVAL; + } + + ret = mtk_i2c_clock_enable(i2c); + if (ret) { + dev_err(&pdev->dev, "clock enable failed!\n"); + return ret; + } + mtk_i2c_init_hw(i2c); + mtk_i2c_clock_disable(i2c); + + i2c->dma_buf.vaddr = dma_alloc_coherent(&pdev->dev, + PAGE_SIZE, &i2c->dma_buf.paddr, GFP_KERNEL); + if (i2c->dma_buf.vaddr == NULL) { + dev_err(&pdev->dev, "dma_alloc_coherent fail\n"); + return -ENOMEM; + } + + i2c_set_adapdata(&i2c->adap, i2c); + ret = i2c_add_adapter(&i2c->adap); + if (ret) { + dev_err(&pdev->dev, "Failed to add i2c bus to i2c core\n"); + free_i2c_dma_bufs(i2c); + return ret; + } + + platform_set_drvdata(pdev, i2c); + + return 0; +} + +static int mtk_i2c_remove(struct platform_device *pdev) +{ + struct mtk_i2c *i2c = platform_get_drvdata(pdev); + + i2c_del_adapter(&i2c->adap); + free_i2c_dma_bufs(i2c); + platform_set_drvdata(pdev, NULL); + + return 0; +} + +static struct platform_driver mtk_i2c_driver = { + .probe = mtk_i2c_probe, + .remove = mtk_i2c_remove, + .driver = { + .name = I2C_DRV_NAME, + .owner = THIS_MODULE, + .of_match_table = of_match_ptr(mtk_i2c_of_match), + }, +}; + +module_platform_driver(mtk_i2c_driver); + +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("MediaTek I2C Bus Driver"); +MODULE_AUTHOR("Xudong Chen <xudong.chen@mediatek.com>"); -- 1.8.1.1.dirty ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2014-11-24 12:15 ` Wolfram Sang 0 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2014-11-24 12:15 UTC (permalink / raw) To: Xudong Chen Cc: Mark Rutland, Matthias Brugger, srv_heupstream, Sascha Hauer, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, Russell King, Grant Likely, Jean Delvare, Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, linux-i2c, Yingjoe Chen, Eddie Huang, Nathan Chung, YH Chen [-- Attachment #1: Type: text/plain, Size: 2895 bytes --] Hi, some very high level remarks: On Mon, Nov 24, 2014 at 05:38:46PM +0800, Xudong Chen wrote: > This series is the third version of Mediatek SoCs I2C controller common > bus driver. > Compared to the second version, > 1. Add comments for clock in dt-bindings file i2c-mt6577.txt. > 2. Remove mt8135.dtsi because of the dependency on pinctrl and clock. > 3. Encode the feature have-dcm in i2c-mt65xx.c by checking the compatible. > > This driver is based on 3.18-rc1. > > MTK I2C HW has some limitation. > 1. If the i2c_msg number is more than one, STOP will be issued instead of > RS(Repeat Start) between each message. > Such as: "START + ADDR + DATA_n + STOP + START + ADDR + DATA_n + STOP ..." > > 2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD > mode the Repeat Start will be issued between 2 messages. > In this driver if 2 messages is first write then read, the driver will > combine 2 messages using Write-Read mode so the RS will be issued between > the 2 messages. > Ex: W/R/R, driver will combine first W/R and then R. > The data series will be: > "START + WriteADDR + DATA + RS + ReadADDR + DATA + STOP + START + ReadADDR + > DATA + STOP". I think there are now 3 drivers in my queue which are not fully I2C compatible but more supporting the very minimum to, say, read an eeprom. I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to think about ways how to communicate deficiencies like "only 255 byte" or "only WRRD messages" to users of that I2C controller. This is most likely not happening before 3.19. But assistance is very welcome. > 3. Due to HW limitation, in this version the max transfer data length is 255 > in one message. If want to transfer more than 255 bytes, HW needs the SW > driver to split the data. Take 600 bytes for example, the data need to be > divided into 3 parts 255 + 255 + 90. The data series will be: > "START + ADDR + DATA_255 + RS + ADDR + DATA_255 + RS + ADDR + DATA_90 + STOP" > instead of "START + ADDR + DATA_900 + STOP". > We haven't implement this yet, we will do this in the separate patch. I don't like this idea. If somebody wants to send 1 message with 600 bytes and we can't do this, we should simply say so. Sending 3 messages is not the same. > MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c > registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR > bit first, the operation on other registers are still the same. > For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support. > For example, If want to use I2C4/5/6 pins on MT8135 just need to enable > the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add > "mediatek,have-pmic" property in the .dts file of each platform. What about Sascha's idea of using a pinctrl driver? Thanks, Wolfram [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2014-11-24 12:15 ` Wolfram Sang 0 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2014-11-24 12:15 UTC (permalink / raw) To: linux-arm-kernel Hi, some very high level remarks: On Mon, Nov 24, 2014 at 05:38:46PM +0800, Xudong Chen wrote: > This series is the third version of Mediatek SoCs I2C controller common > bus driver. > Compared to the second version, > 1. Add comments for clock in dt-bindings file i2c-mt6577.txt. > 2. Remove mt8135.dtsi because of the dependency on pinctrl and clock. > 3. Encode the feature have-dcm in i2c-mt65xx.c by checking the compatible. > > This driver is based on 3.18-rc1. > > MTK I2C HW has some limitation. > 1. If the i2c_msg number is more than one, STOP will be issued instead of > RS(Repeat Start) between each message. > Such as: "START + ADDR + DATA_n + STOP + START + ADDR + DATA_n + STOP ..." > > 2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD > mode the Repeat Start will be issued between 2 messages. > In this driver if 2 messages is first write then read, the driver will > combine 2 messages using Write-Read mode so the RS will be issued between > the 2 messages. > Ex: W/R/R, driver will combine first W/R and then R. > The data series will be: > "START + WriteADDR + DATA + RS + ReadADDR + DATA + STOP + START + ReadADDR + > DATA + STOP". I think there are now 3 drivers in my queue which are not fully I2C compatible but more supporting the very minimum to, say, read an eeprom. I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to think about ways how to communicate deficiencies like "only 255 byte" or "only WRRD messages" to users of that I2C controller. This is most likely not happening before 3.19. But assistance is very welcome. > 3. Due to HW limitation, in this version the max transfer data length is 255 > in one message. If want to transfer more than 255 bytes, HW needs the SW > driver to split the data. Take 600 bytes for example, the data need to be > divided into 3 parts 255 + 255 + 90. The data series will be: > "START + ADDR + DATA_255 + RS + ADDR + DATA_255 + RS + ADDR + DATA_90 + STOP" > instead of "START + ADDR + DATA_900 + STOP". > We haven't implement this yet, we will do this in the separate patch. I don't like this idea. If somebody wants to send 1 message with 600 bytes and we can't do this, we should simply say so. Sending 3 messages is not the same. > MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c > registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR > bit first, the operation on other registers are still the same. > For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support. > For example, If want to use I2C4/5/6 pins on MT8135 just need to enable > the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add > "mediatek,have-pmic" property in the .dts file of each platform. What about Sascha's idea of using a pinctrl driver? Thanks, Wolfram -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/9684d875/attachment.sig> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2014-11-24 12:15 ` Wolfram Sang 0 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2014-11-24 12:15 UTC (permalink / raw) To: Xudong Chen Cc: Mark Rutland, Matthias Brugger, srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Sascha Hauer, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, Russell King, Grant Likely, Jean Delvare, Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Yingjoe Chen, Eddie Huang, Nathan Chung, YH Chen [-- Attachment #1: Type: text/plain, Size: 2895 bytes --] Hi, some very high level remarks: On Mon, Nov 24, 2014 at 05:38:46PM +0800, Xudong Chen wrote: > This series is the third version of Mediatek SoCs I2C controller common > bus driver. > Compared to the second version, > 1. Add comments for clock in dt-bindings file i2c-mt6577.txt. > 2. Remove mt8135.dtsi because of the dependency on pinctrl and clock. > 3. Encode the feature have-dcm in i2c-mt65xx.c by checking the compatible. > > This driver is based on 3.18-rc1. > > MTK I2C HW has some limitation. > 1. If the i2c_msg number is more than one, STOP will be issued instead of > RS(Repeat Start) between each message. > Such as: "START + ADDR + DATA_n + STOP + START + ADDR + DATA_n + STOP ..." > > 2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD > mode the Repeat Start will be issued between 2 messages. > In this driver if 2 messages is first write then read, the driver will > combine 2 messages using Write-Read mode so the RS will be issued between > the 2 messages. > Ex: W/R/R, driver will combine first W/R and then R. > The data series will be: > "START + WriteADDR + DATA + RS + ReadADDR + DATA + STOP + START + ReadADDR + > DATA + STOP". I think there are now 3 drivers in my queue which are not fully I2C compatible but more supporting the very minimum to, say, read an eeprom. I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to think about ways how to communicate deficiencies like "only 255 byte" or "only WRRD messages" to users of that I2C controller. This is most likely not happening before 3.19. But assistance is very welcome. > 3. Due to HW limitation, in this version the max transfer data length is 255 > in one message. If want to transfer more than 255 bytes, HW needs the SW > driver to split the data. Take 600 bytes for example, the data need to be > divided into 3 parts 255 + 255 + 90. The data series will be: > "START + ADDR + DATA_255 + RS + ADDR + DATA_255 + RS + ADDR + DATA_90 + STOP" > instead of "START + ADDR + DATA_900 + STOP". > We haven't implement this yet, we will do this in the separate patch. I don't like this idea. If somebody wants to send 1 message with 600 bytes and we can't do this, we should simply say so. Sending 3 messages is not the same. > MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c > registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR > bit first, the operation on other registers are still the same. > For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support. > For example, If want to use I2C4/5/6 pins on MT8135 just need to enable > the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add > "mediatek,have-pmic" property in the .dts file of each platform. What about Sascha's idea of using a pinctrl driver? Thanks, Wolfram [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller 2014-11-24 12:15 ` Wolfram Sang (?) @ 2014-11-27 14:00 ` Yingjoe Chen -1 siblings, 0 replies; 32+ messages in thread From: Yingjoe Chen @ 2014-11-27 14:00 UTC (permalink / raw) To: Wolfram Sang Cc: Xudong Chen, Mark Rutland, Matthias Brugger, srv_heupstream, Sascha Hauer, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, Russell King, Grant Likely, Jean Delvare, Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, linux-i2c, Eddie Huang, Nathan Chung, YH Chen, Linus Walleij Hi, On Mon, 2014-11-24 at 13:15 +0100, Wolfram Sang wrote: > Hi, > > some very high level remarks: > > On Mon, Nov 24, 2014 at 05:38:46PM +0800, Xudong Chen wrote: > > This series is the third version of Mediatek SoCs I2C controller common > > bus driver. > > Compared to the second version, > > 1. Add comments for clock in dt-bindings file i2c-mt6577.txt. > > 2. Remove mt8135.dtsi because of the dependency on pinctrl and clock. > > 3. Encode the feature have-dcm in i2c-mt65xx.c by checking the compatible. > > > > This driver is based on 3.18-rc1. > > > > MTK I2C HW has some limitation. > > 1. If the i2c_msg number is more than one, STOP will be issued instead of > > RS(Repeat Start) between each message. > > Such as: "START + ADDR + DATA_n + STOP + START + ADDR + DATA_n + STOP ..." > > > > 2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD > > mode the Repeat Start will be issued between 2 messages. > > In this driver if 2 messages is first write then read, the driver will > > combine 2 messages using Write-Read mode so the RS will be issued between > > the 2 messages. > > Ex: W/R/R, driver will combine first W/R and then R. > > The data series will be: > > "START + WriteADDR + DATA + RS + ReadADDR + DATA + STOP + START + ReadADDR + > > DATA + STOP". > > I think there are now 3 drivers in my queue which are not fully I2C > compatible but more supporting the very minimum to, say, read an eeprom. > I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to > think about ways how to communicate deficiencies like "only 255 byte" or > "only WRRD messages" to users of that I2C controller. This is most > likely not happening before 3.19. But assistance is very welcome. Let's us know what we could help :) > > 3. Due to HW limitation, in this version the max transfer data length is 255 > > in one message. If want to transfer more than 255 bytes, HW needs the SW > > driver to split the data. Take 600 bytes for example, the data need to be > > divided into 3 parts 255 + 255 + 90. The data series will be: > > "START + ADDR + DATA_255 + RS + ADDR + DATA_255 + RS + ADDR + DATA_90 + STOP" > > instead of "START + ADDR + DATA_900 + STOP". > > We haven't implement this yet, we will do this in the separate patch. > > I don't like this idea. If somebody wants to send 1 message with 600 > bytes and we can't do this, we should simply say so. Sending 3 messages > is not the same. Agreed. I think this should only happen when we know the device can support that. However, from our experience, many i2c devices do support it. Do you think it is OK to add a flag in i2c_msg(eg, I2C_M_ALLOW_SPLIT) and only do message split when this flag is on? > > MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c > > registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR > > bit first, the operation on other registers are still the same. > > For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support. > > For example, If want to use I2C4/5/6 pins on MT8135 just need to enable > > the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add > > "mediatek,have-pmic" property in the .dts file of each platform. > > What about Sascha's idea of using a pinctrl driver? We are working on mt6397 pmic pinctrl driver. It depends on mt8135 pinctrl driver [1] and pmic pwrap driver [2]. There are some discussion about pinctrl bindings, we'll send pmic pinctrl driver when that is settled. Just to make it clear, the pinctrl driver only handle pin mux, we still need to set mediatek,have-pmic to send i2c data through pmic. Joe.C [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/301417.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/302984.html ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2014-11-27 14:00 ` Yingjoe Chen 0 siblings, 0 replies; 32+ messages in thread From: Yingjoe Chen @ 2014-11-27 14:00 UTC (permalink / raw) To: linux-arm-kernel Hi, On Mon, 2014-11-24 at 13:15 +0100, Wolfram Sang wrote: > Hi, > > some very high level remarks: > > On Mon, Nov 24, 2014 at 05:38:46PM +0800, Xudong Chen wrote: > > This series is the third version of Mediatek SoCs I2C controller common > > bus driver. > > Compared to the second version, > > 1. Add comments for clock in dt-bindings file i2c-mt6577.txt. > > 2. Remove mt8135.dtsi because of the dependency on pinctrl and clock. > > 3. Encode the feature have-dcm in i2c-mt65xx.c by checking the compatible. > > > > This driver is based on 3.18-rc1. > > > > MTK I2C HW has some limitation. > > 1. If the i2c_msg number is more than one, STOP will be issued instead of > > RS(Repeat Start) between each message. > > Such as: "START + ADDR + DATA_n + STOP + START + ADDR + DATA_n + STOP ..." > > > > 2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD > > mode the Repeat Start will be issued between 2 messages. > > In this driver if 2 messages is first write then read, the driver will > > combine 2 messages using Write-Read mode so the RS will be issued between > > the 2 messages. > > Ex: W/R/R, driver will combine first W/R and then R. > > The data series will be: > > "START + WriteADDR + DATA + RS + ReadADDR + DATA + STOP + START + ReadADDR + > > DATA + STOP". > > I think there are now 3 drivers in my queue which are not fully I2C > compatible but more supporting the very minimum to, say, read an eeprom. > I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to > think about ways how to communicate deficiencies like "only 255 byte" or > "only WRRD messages" to users of that I2C controller. This is most > likely not happening before 3.19. But assistance is very welcome. Let's us know what we could help :) > > 3. Due to HW limitation, in this version the max transfer data length is 255 > > in one message. If want to transfer more than 255 bytes, HW needs the SW > > driver to split the data. Take 600 bytes for example, the data need to be > > divided into 3 parts 255 + 255 + 90. The data series will be: > > "START + ADDR + DATA_255 + RS + ADDR + DATA_255 + RS + ADDR + DATA_90 + STOP" > > instead of "START + ADDR + DATA_900 + STOP". > > We haven't implement this yet, we will do this in the separate patch. > > I don't like this idea. If somebody wants to send 1 message with 600 > bytes and we can't do this, we should simply say so. Sending 3 messages > is not the same. Agreed. I think this should only happen when we know the device can support that. However, from our experience, many i2c devices do support it. Do you think it is OK to add a flag in i2c_msg(eg, I2C_M_ALLOW_SPLIT) and only do message split when this flag is on? > > MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c > > registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR > > bit first, the operation on other registers are still the same. > > For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support. > > For example, If want to use I2C4/5/6 pins on MT8135 just need to enable > > the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add > > "mediatek,have-pmic" property in the .dts file of each platform. > > What about Sascha's idea of using a pinctrl driver? We are working on mt6397 pmic pinctrl driver. It depends on mt8135 pinctrl driver [1] and pmic pwrap driver [2]. There are some discussion about pinctrl bindings, we'll send pmic pinctrl driver when that is settled. Just to make it clear, the pinctrl driver only handle pin mux, we still need to set mediatek,have-pmic to send i2c data through pmic. Joe.C [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/301417.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/302984.html ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2014-11-27 14:00 ` Yingjoe Chen 0 siblings, 0 replies; 32+ messages in thread From: Yingjoe Chen @ 2014-11-27 14:00 UTC (permalink / raw) To: Wolfram Sang Cc: Xudong Chen, Mark Rutland, Matthias Brugger, srv_heupstream, Sascha Hauer, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, Russell King, Grant Likely, Jean Delvare, Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, linux-i2c, Eddie Huang, Nathan Chung, YH Chen, Linus Walleij Hi, On Mon, 2014-11-24 at 13:15 +0100, Wolfram Sang wrote: > Hi, > > some very high level remarks: > > On Mon, Nov 24, 2014 at 05:38:46PM +0800, Xudong Chen wrote: > > This series is the third version of Mediatek SoCs I2C controller common > > bus driver. > > Compared to the second version, > > 1. Add comments for clock in dt-bindings file i2c-mt6577.txt. > > 2. Remove mt8135.dtsi because of the dependency on pinctrl and clock. > > 3. Encode the feature have-dcm in i2c-mt65xx.c by checking the compatible. > > > > This driver is based on 3.18-rc1. > > > > MTK I2C HW has some limitation. > > 1. If the i2c_msg number is more than one, STOP will be issued instead of > > RS(Repeat Start) between each message. > > Such as: "START + ADDR + DATA_n + STOP + START + ADDR + DATA_n + STOP ..." > > > > 2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD > > mode the Repeat Start will be issued between 2 messages. > > In this driver if 2 messages is first write then read, the driver will > > combine 2 messages using Write-Read mode so the RS will be issued between > > the 2 messages. > > Ex: W/R/R, driver will combine first W/R and then R. > > The data series will be: > > "START + WriteADDR + DATA + RS + ReadADDR + DATA + STOP + START + ReadADDR + > > DATA + STOP". > > I think there are now 3 drivers in my queue which are not fully I2C > compatible but more supporting the very minimum to, say, read an eeprom. > I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to > think about ways how to communicate deficiencies like "only 255 byte" or > "only WRRD messages" to users of that I2C controller. This is most > likely not happening before 3.19. But assistance is very welcome. Let's us know what we could help :) > > 3. Due to HW limitation, in this version the max transfer data length is 255 > > in one message. If want to transfer more than 255 bytes, HW needs the SW > > driver to split the data. Take 600 bytes for example, the data need to be > > divided into 3 parts 255 + 255 + 90. The data series will be: > > "START + ADDR + DATA_255 + RS + ADDR + DATA_255 + RS + ADDR + DATA_90 + STOP" > > instead of "START + ADDR + DATA_900 + STOP". > > We haven't implement this yet, we will do this in the separate patch. > > I don't like this idea. If somebody wants to send 1 message with 600 > bytes and we can't do this, we should simply say so. Sending 3 messages > is not the same. Agreed. I think this should only happen when we know the device can support that. However, from our experience, many i2c devices do support it. Do you think it is OK to add a flag in i2c_msg(eg, I2C_M_ALLOW_SPLIT) and only do message split when this flag is on? > > MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c > > registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR > > bit first, the operation on other registers are still the same. > > For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support. > > For example, If want to use I2C4/5/6 pins on MT8135 just need to enable > > the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add > > "mediatek,have-pmic" property in the .dts file of each platform. > > What about Sascha's idea of using a pinctrl driver? We are working on mt6397 pmic pinctrl driver. It depends on mt8135 pinctrl driver [1] and pmic pwrap driver [2]. There are some discussion about pinctrl bindings, we'll send pmic pinctrl driver when that is settled. Just to make it clear, the pinctrl driver only handle pin mux, we still need to set mediatek,have-pmic to send i2c data through pmic. Joe.C [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/301417.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/302984.html ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller 2014-11-27 14:00 ` Yingjoe Chen (?) @ 2014-11-27 16:45 ` Wolfram Sang -1 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2014-11-27 16:45 UTC (permalink / raw) To: Yingjoe Chen Cc: Xudong Chen, Mark Rutland, Matthias Brugger, srv_heupstream, Sascha Hauer, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, Russell King, Grant Likely, Jean Delvare, Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, linux-i2c, Eddie Huang, Nathan Chung, YH Chen, Linus Walleij [-- Attachment #1: Type: text/plain, Size: 1832 bytes --] > > I think there are now 3 drivers in my queue which are not fully I2C > > compatible but more supporting the very minimum to, say, read an eeprom. > > I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to > > think about ways how to communicate deficiencies like "only 255 byte" or > > "only WRRD messages" to users of that I2C controller. This is most > > likely not happening before 3.19. But assistance is very welcome. > > Let's us know what we could help :) I'll put you on CC once I have a draft. Then review, test, comment. That would help, thanks! > > I don't like this idea. If somebody wants to send 1 message with 600 > > bytes and we can't do this, we should simply say so. Sending 3 messages > > is not the same. > > Agreed. I think this should only happen when we know the device can > support that. > However, from our experience, many i2c devices do support it. Do you > think it is OK to add a flag in i2c_msg(eg, I2C_M_ALLOW_SPLIT) and only > do message split when this flag is on? I think we only should report the error and the calling i2c client driver should decide what to do. It will have better knowledge on how to split the message and do this on its own. > > What about Sascha's idea of using a pinctrl driver? > > We are working on mt6397 pmic pinctrl driver. It depends on mt8135 > pinctrl driver [1] and pmic pwrap driver [2]. There are some discussion > about pinctrl bindings, we'll send pmic pinctrl driver when that is > settled. > > Just to make it clear, the pinctrl driver only handle pin mux, we still > need to set mediatek,have-pmic to send i2c data through pmic. I have to admit that I don't know this level of detail yet. I might see Sascha tomorrow, maybe we'll have a chance to talk about it. Thanks, Wolfram [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2014-11-27 16:45 ` Wolfram Sang 0 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2014-11-27 16:45 UTC (permalink / raw) To: linux-arm-kernel > > I think there are now 3 drivers in my queue which are not fully I2C > > compatible but more supporting the very minimum to, say, read an eeprom. > > I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to > > think about ways how to communicate deficiencies like "only 255 byte" or > > "only WRRD messages" to users of that I2C controller. This is most > > likely not happening before 3.19. But assistance is very welcome. > > Let's us know what we could help :) I'll put you on CC once I have a draft. Then review, test, comment. That would help, thanks! > > I don't like this idea. If somebody wants to send 1 message with 600 > > bytes and we can't do this, we should simply say so. Sending 3 messages > > is not the same. > > Agreed. I think this should only happen when we know the device can > support that. > However, from our experience, many i2c devices do support it. Do you > think it is OK to add a flag in i2c_msg(eg, I2C_M_ALLOW_SPLIT) and only > do message split when this flag is on? I think we only should report the error and the calling i2c client driver should decide what to do. It will have better knowledge on how to split the message and do this on its own. > > What about Sascha's idea of using a pinctrl driver? > > We are working on mt6397 pmic pinctrl driver. It depends on mt8135 > pinctrl driver [1] and pmic pwrap driver [2]. There are some discussion > about pinctrl bindings, we'll send pmic pinctrl driver when that is > settled. > > Just to make it clear, the pinctrl driver only handle pin mux, we still > need to set mediatek,have-pmic to send i2c data through pmic. I have to admit that I don't know this level of detail yet. I might see Sascha tomorrow, maybe we'll have a chance to talk about it. Thanks, Wolfram -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141127/8bd8cc48/attachment-0001.sig> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2014-11-27 16:45 ` Wolfram Sang 0 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2014-11-27 16:45 UTC (permalink / raw) To: Yingjoe Chen Cc: Xudong Chen, Mark Rutland, Matthias Brugger, srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Sascha Hauer, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, Russell King, Grant Likely, Jean Delvare, Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Eddie Huang, Nathan Chung, YH Chen, Linus Walleij [-- Attachment #1: Type: text/plain, Size: 1832 bytes --] > > I think there are now 3 drivers in my queue which are not fully I2C > > compatible but more supporting the very minimum to, say, read an eeprom. > > I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to > > think about ways how to communicate deficiencies like "only 255 byte" or > > "only WRRD messages" to users of that I2C controller. This is most > > likely not happening before 3.19. But assistance is very welcome. > > Let's us know what we could help :) I'll put you on CC once I have a draft. Then review, test, comment. That would help, thanks! > > I don't like this idea. If somebody wants to send 1 message with 600 > > bytes and we can't do this, we should simply say so. Sending 3 messages > > is not the same. > > Agreed. I think this should only happen when we know the device can > support that. > However, from our experience, many i2c devices do support it. Do you > think it is OK to add a flag in i2c_msg(eg, I2C_M_ALLOW_SPLIT) and only > do message split when this flag is on? I think we only should report the error and the calling i2c client driver should decide what to do. It will have better knowledge on how to split the message and do this on its own. > > What about Sascha's idea of using a pinctrl driver? > > We are working on mt6397 pmic pinctrl driver. It depends on mt8135 > pinctrl driver [1] and pmic pwrap driver [2]. There are some discussion > about pinctrl bindings, we'll send pmic pinctrl driver when that is > settled. > > Just to make it clear, the pinctrl driver only handle pin mux, we still > need to set mediatek,have-pmic to send i2c data through pmic. I have to admit that I don't know this level of detail yet. I might see Sascha tomorrow, maybe we'll have a chance to talk about it. Thanks, Wolfram [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller 2014-11-27 16:45 ` Wolfram Sang (?) @ 2014-12-12 2:40 ` Yingjoe Chen -1 siblings, 0 replies; 32+ messages in thread From: Yingjoe Chen @ 2014-12-12 2:40 UTC (permalink / raw) To: Wolfram Sang Cc: Liguo Zhang, Xudong Chen, Mark Rutland, Russell King, Pawel Moll, srv_heupstream, Ian Campbell, Linus Walleij, YH Chen, linux-kernel, Grant Likely, devicetree, Rob Herring, Arnd Bergmann, linux-arm-kernel, Sascha Hauer, Kumar Gala, Matthias Brugger, Nathan Chung, Eddie Huang, Jean Delvare, linux-i2c On Thu, 2014-11-27 at 17:45 +0100, Wolfram Sang wrote: > > > I think there are now 3 drivers in my queue which are not fully I2C > > > compatible but more supporting the very minimum to, say, read an eeprom. > > > I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to > > > think about ways how to communicate deficiencies like "only 255 byte" or > > > "only WRRD messages" to users of that I2C controller. This is most > > > likely not happening before 3.19. But assistance is very welcome. Hi Wolfram, We've started upstream work for MT8173[1]. We've fixed these issues for new SoC, and we believe it is fully I2C compatible now. We'll add mt8173 support to this driver, so this driver will support both fully I2C compatible SoC and the current one. Joe.C [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309847.html ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2014-12-12 2:40 ` Yingjoe Chen 0 siblings, 0 replies; 32+ messages in thread From: Yingjoe Chen @ 2014-12-12 2:40 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2014-11-27 at 17:45 +0100, Wolfram Sang wrote: > > > I think there are now 3 drivers in my queue which are not fully I2C > > > compatible but more supporting the very minimum to, say, read an eeprom. > > > I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to > > > think about ways how to communicate deficiencies like "only 255 byte" or > > > "only WRRD messages" to users of that I2C controller. This is most > > > likely not happening before 3.19. But assistance is very welcome. Hi Wolfram, We've started upstream work for MT8173[1]. We've fixed these issues for new SoC, and we believe it is fully I2C compatible now. We'll add mt8173 support to this driver, so this driver will support both fully I2C compatible SoC and the current one. Joe.C [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309847.html ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2014-12-12 2:40 ` Yingjoe Chen 0 siblings, 0 replies; 32+ messages in thread From: Yingjoe Chen @ 2014-12-12 2:40 UTC (permalink / raw) To: Wolfram Sang Cc: Mark Rutland, Linus Walleij, linux-i2c, Jean Delvare, Xudong Chen, Russell King, Arnd Bergmann, YH Chen, Liguo Zhang, Nathan Chung, Grant Likely, devicetree, Pawel Moll, Ian Campbell, Rob Herring, Matthias Brugger, Eddie Huang, linux-arm-kernel, srv_heupstream, linux-kernel, Sascha Hauer, Kumar Gala On Thu, 2014-11-27 at 17:45 +0100, Wolfram Sang wrote: > > > I think there are now 3 drivers in my queue which are not fully I2C > > > compatible but more supporting the very minimum to, say, read an eeprom. > > > I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to > > > think about ways how to communicate deficiencies like "only 255 byte" or > > > "only WRRD messages" to users of that I2C controller. This is most > > > likely not happening before 3.19. But assistance is very welcome. Hi Wolfram, We've started upstream work for MT8173[1]. We've fixed these issues for new SoC, and we believe it is fully I2C compatible now. We'll add mt8173 support to this driver, so this driver will support both fully I2C compatible SoC and the current one. Joe.C [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309847.html ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller 2014-12-12 2:40 ` Yingjoe Chen (?) @ 2015-01-06 13:37 ` Wolfram Sang -1 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2015-01-06 13:37 UTC (permalink / raw) To: Yingjoe Chen Cc: Liguo Zhang, Xudong Chen, Mark Rutland, Russell King, Pawel Moll, srv_heupstream, Ian Campbell, Linus Walleij, YH Chen, linux-kernel, Grant Likely, devicetree, Rob Herring, Arnd Bergmann, linux-arm-kernel, Sascha Hauer, Kumar Gala, Matthias Brugger, Nathan Chung, Eddie Huang, Jean Delvare, linux-i2c [-- Attachment #1: Type: text/plain, Size: 494 bytes --] > We've started upstream work for MT8173[1]. > > We've fixed these issues for new SoC, and we believe it is fully I2C > compatible now. We'll add mt8173 support to this driver, so this driver > will support both fully I2C compatible SoC and the current one. From what you tell, I'd rather add the MT8173 support incrementally. Let's get first the limited support properly implemented, then add another controller. I'll send out my draft for describing the quirks later today. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2015-01-06 13:37 ` Wolfram Sang 0 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2015-01-06 13:37 UTC (permalink / raw) To: linux-arm-kernel > We've started upstream work for MT8173[1]. > > We've fixed these issues for new SoC, and we believe it is fully I2C > compatible now. We'll add mt8173 support to this driver, so this driver > will support both fully I2C compatible SoC and the current one. >From what you tell, I'd rather add the MT8173 support incrementally. Let's get first the limited support properly implemented, then add another controller. I'll send out my draft for describing the quirks later today. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150106/7564d3c5/attachment-0001.sig> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2015-01-06 13:37 ` Wolfram Sang 0 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2015-01-06 13:37 UTC (permalink / raw) To: Yingjoe Chen Cc: Mark Rutland, Linus Walleij, linux-i2c, Jean Delvare, Xudong Chen, Russell King, Arnd Bergmann, YH Chen, Liguo Zhang, Nathan Chung, Grant Likely, devicetree, Pawel Moll, Ian Campbell, Rob Herring, Matthias Brugger, Eddie Huang, linux-arm-kernel, srv_heupstream, linux-kernel, Sascha Hauer, Kumar Gala [-- Attachment #1.1: Type: text/plain, Size: 494 bytes --] > We've started upstream work for MT8173[1]. > > We've fixed these issues for new SoC, and we believe it is fully I2C > compatible now. We'll add mt8173 support to this driver, so this driver > will support both fully I2C compatible SoC and the current one. From what you tell, I'd rather add the MT8173 support incrementally. Let's get first the limited support properly implemented, then add another controller. I'll send out my draft for describing the quirks later today. [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller 2015-01-06 13:37 ` Wolfram Sang (?) @ 2015-01-13 9:57 ` Wolfram Sang -1 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2015-01-13 9:57 UTC (permalink / raw) To: Yingjoe Chen Cc: Liguo Zhang, Xudong Chen, Mark Rutland, Russell King, Pawel Moll, srv_heupstream, Ian Campbell, Linus Walleij, YH Chen, linux-kernel, Grant Likely, devicetree, Rob Herring, Arnd Bergmann, linux-arm-kernel, Sascha Hauer, Kumar Gala, Matthias Brugger, Nathan Chung, Eddie Huang, Jean Delvare, linux-i2c [-- Attachment #1: Type: text/plain, Size: 626 bytes --] On Tue, Jan 06, 2015 at 02:37:53PM +0100, Wolfram Sang wrote: > > > We've started upstream work for MT8173[1]. > > > > We've fixed these issues for new SoC, and we believe it is fully I2C > > compatible now. We'll add mt8173 support to this driver, so this driver > > will support both fully I2C compatible SoC and the current one. > > From what you tell, I'd rather add the MT8173 support incrementally. > Let's get first the limited support properly implemented, then add > another controller. > > I'll send out my draft for describing the quirks later today. What do you think about my two proposals? [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2015-01-13 9:57 ` Wolfram Sang 0 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2015-01-13 9:57 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jan 06, 2015 at 02:37:53PM +0100, Wolfram Sang wrote: > > > We've started upstream work for MT8173[1]. > > > > We've fixed these issues for new SoC, and we believe it is fully I2C > > compatible now. We'll add mt8173 support to this driver, so this driver > > will support both fully I2C compatible SoC and the current one. > > From what you tell, I'd rather add the MT8173 support incrementally. > Let's get first the limited support properly implemented, then add > another controller. > > I'll send out my draft for describing the quirks later today. What do you think about my two proposals? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150113/a96017f0/attachment.sig> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2015-01-13 9:57 ` Wolfram Sang 0 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2015-01-13 9:57 UTC (permalink / raw) To: Yingjoe Chen Cc: Liguo Zhang, Xudong Chen, Mark Rutland, Russell King, Pawel Moll, srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Ian Campbell, Linus Walleij, YH Chen, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sascha Hauer, Kumar Gala, Matthias Brugger, Nathan Chung, Eddie Huang, Jean Delvare, linux-i2c-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 626 bytes --] On Tue, Jan 06, 2015 at 02:37:53PM +0100, Wolfram Sang wrote: > > > We've started upstream work for MT8173[1]. > > > > We've fixed these issues for new SoC, and we believe it is fully I2C > > compatible now. We'll add mt8173 support to this driver, so this driver > > will support both fully I2C compatible SoC and the current one. > > From what you tell, I'd rather add the MT8173 support incrementally. > Let's get first the limited support properly implemented, then add > another controller. > > I'll send out my draft for describing the quirks later today. What do you think about my two proposals? [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller 2015-01-13 9:57 ` Wolfram Sang (?) @ 2015-01-13 15:15 ` Yingjoe Chen -1 siblings, 0 replies; 32+ messages in thread From: Yingjoe Chen @ 2015-01-13 15:15 UTC (permalink / raw) To: Wolfram Sang Cc: Mark Rutland, Linus Walleij, linux-i2c, Jean Delvare, Xudong Chen, Russell King, Arnd Bergmann, YH Chen, Liguo Zhang, Nathan Chung, Grant Likely, devicetree, Pawel Moll, Ian Campbell, Rob Herring, Matthias Brugger, Eddie Huang, linux-arm-kernel, srv_heupstream, linux-kernel, Sascha Hauer, Kumar Gala On Tue, 2015-01-13 at 10:57 +0100, Wolfram Sang wrote: > On Tue, Jan 06, 2015 at 02:37:53PM +0100, Wolfram Sang wrote: > > > > > We've started upstream work for MT8173[1]. > > > > > > We've fixed these issues for new SoC, and we believe it is fully I2C > > > compatible now. We'll add mt8173 support to this driver, so this driver > > > will support both fully I2C compatible SoC and the current one. > > > > From what you tell, I'd rather add the MT8173 support incrementally. > > Let's get first the limited support properly implemented, then add > > another controller. > > > > I'll send out my draft for describing the quirks later today. > > What do you think about my two proposals? I think the quirks can describe our HW limitation without issue. We are porting our i2c driver base on that. Will let you know the test result. Thanks Joe.C ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2015-01-13 15:15 ` Yingjoe Chen 0 siblings, 0 replies; 32+ messages in thread From: Yingjoe Chen @ 2015-01-13 15:15 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2015-01-13 at 10:57 +0100, Wolfram Sang wrote: > On Tue, Jan 06, 2015 at 02:37:53PM +0100, Wolfram Sang wrote: > > > > > We've started upstream work for MT8173[1]. > > > > > > We've fixed these issues for new SoC, and we believe it is fully I2C > > > compatible now. We'll add mt8173 support to this driver, so this driver > > > will support both fully I2C compatible SoC and the current one. > > > > From what you tell, I'd rather add the MT8173 support incrementally. > > Let's get first the limited support properly implemented, then add > > another controller. > > > > I'll send out my draft for describing the quirks later today. > > What do you think about my two proposals? I think the quirks can describe our HW limitation without issue. We are porting our i2c driver base on that. Will let you know the test result. Thanks Joe.C ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2015-01-13 15:15 ` Yingjoe Chen 0 siblings, 0 replies; 32+ messages in thread From: Yingjoe Chen @ 2015-01-13 15:15 UTC (permalink / raw) To: Wolfram Sang Cc: Mark Rutland, Linus Walleij, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Jean Delvare, Xudong Chen, Russell King, Arnd Bergmann, YH Chen, Liguo Zhang, Nathan Chung, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Ian Campbell, Rob Herring, Matthias Brugger, Eddie Huang, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer, Kumar Gala On Tue, 2015-01-13 at 10:57 +0100, Wolfram Sang wrote: > On Tue, Jan 06, 2015 at 02:37:53PM +0100, Wolfram Sang wrote: > > > > > We've started upstream work for MT8173[1]. > > > > > > We've fixed these issues for new SoC, and we believe it is fully I2C > > > compatible now. We'll add mt8173 support to this driver, so this driver > > > will support both fully I2C compatible SoC and the current one. > > > > From what you tell, I'd rather add the MT8173 support incrementally. > > Let's get first the limited support properly implemented, then add > > another controller. > > > > I'll send out my draft for describing the quirks later today. > > What do you think about my two proposals? I think the quirks can describe our HW limitation without issue. We are porting our i2c driver base on that. Will let you know the test result. Thanks Joe.C ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller 2015-01-13 15:15 ` Yingjoe Chen @ 2015-01-13 15:23 ` Wolfram Sang -1 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2015-01-13 15:23 UTC (permalink / raw) To: Yingjoe Chen Cc: Mark Rutland, Linus Walleij, linux-i2c, Jean Delvare, Xudong Chen, Russell King, Arnd Bergmann, YH Chen, Liguo Zhang, Nathan Chung, Grant Likely, devicetree, Pawel Moll, Ian Campbell, Rob Herring, Matthias Brugger, Eddie Huang, linux-arm-kernel, srv_heupstream, linux-kernel, Sascha Hauer, Kumar Gala [-- Attachment #1: Type: text/plain, Size: 190 bytes --] > I think the quirks can describe our HW limitation without issue. > We are porting our i2c driver base on that. Will let you know the test > result. Great news, thanks for the update :) [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller @ 2015-01-13 15:23 ` Wolfram Sang 0 siblings, 0 replies; 32+ messages in thread From: Wolfram Sang @ 2015-01-13 15:23 UTC (permalink / raw) To: linux-arm-kernel > I think the quirks can describe our HW limitation without issue. > We are porting our i2c driver base on that. Will let you know the test > result. Great news, thanks for the update :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150113/12d4d1df/attachment.sig> ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2015-01-13 15:23 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-11-24 9:38 [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek I2C controller Xudong Chen 2014-11-24 9:38 ` Xudong Chen 2014-11-24 9:38 ` Xudong Chen 2014-11-24 9:38 ` [PATCH v3 1/2] dt-bindings: Add I2C bindings for mt65xx/mt81xx Xudong Chen 2014-11-24 9:38 ` Xudong Chen 2014-11-24 9:38 ` Xudong Chen 2014-11-24 9:38 ` [PATCH v3 2/2] I2C: mediatek: Add driver for MediaTek I2C controller Xudong Chen 2014-11-24 9:38 ` Xudong Chen 2014-11-24 9:38 ` Xudong Chen 2014-11-24 12:15 ` [PATCH v3 0/2] ARM: mediatek: Add driver for Mediatek " Wolfram Sang 2014-11-24 12:15 ` Wolfram Sang 2014-11-24 12:15 ` Wolfram Sang 2014-11-27 14:00 ` Yingjoe Chen 2014-11-27 14:00 ` Yingjoe Chen 2014-11-27 14:00 ` Yingjoe Chen 2014-11-27 16:45 ` Wolfram Sang 2014-11-27 16:45 ` Wolfram Sang 2014-11-27 16:45 ` Wolfram Sang 2014-12-12 2:40 ` Yingjoe Chen 2014-12-12 2:40 ` Yingjoe Chen 2014-12-12 2:40 ` Yingjoe Chen 2015-01-06 13:37 ` Wolfram Sang 2015-01-06 13:37 ` Wolfram Sang 2015-01-06 13:37 ` Wolfram Sang 2015-01-13 9:57 ` Wolfram Sang 2015-01-13 9:57 ` Wolfram Sang 2015-01-13 9:57 ` Wolfram Sang 2015-01-13 15:15 ` Yingjoe Chen 2015-01-13 15:15 ` Yingjoe Chen 2015-01-13 15:15 ` Yingjoe Chen 2015-01-13 15:23 ` Wolfram Sang 2015-01-13 15:23 ` Wolfram Sang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.