i2c: sunxi: Support every i2c controller on each supported platform
Subsystems (4)
v3 cover i2c: sunxi: Support every i2c controller on each supported platform
Changes since v2:
* I2C/TWI busses enable for Cubietruck as well
Changes since v1:
* Kconfig option to enable I2C/TWI controllers 1-4 (when applicable)
* Following patch to enable exposed busses on a few community-supported single-board-computers
This series adds support for every i2c controller found on sun4i/sun5i/sun6i/sun7i/sun8i platforms and shouldn't break support for Marvell platforms (orion5x, kirkwood, armada xp) the driver was originally written for.
Regarding sunxi, I double-checked that this doesn't conflict with VIDEO_LCD_PANEL_I2C.
I would be interested in having this tested on sun8i (A23), since I changed TWI0 muxing (to PH2-PH3 instead of PB0-PB1), according to the user manual and what is being done on the upstream Linux kernel. I2C was either not working before, or it was being muxed correctly by the bootrom, probably to communicate with the AXP, which luckily made it work in U-Boot too, since the I/O base address was already correct.
My use case here is that I'm writing a slave-side bitbang i2c implementation (with an Arduino) for a school project, using a Cubieboard2 as master and U-Boot as POC. However, only TWI1 was available through the expansion pins, hence the need for this series.
PATCH v3 1/3 i2c: mvtwsi: Support for up to 4 different controllers
Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) MVTWSI controller. However, other platforms using MVTWSI may come with more: this is the case on Allwinner (sunxi) platforms, where up to 4 controllers can be found on the same chip.
--- arch/arm/include/asm/arch-sunxi/i2c.h | 2 +- arch/arm/mach-kirkwood/include/mach/config.h | 2 +- drivers/i2c/mvtwsi.c | 124 ++++++++++++++++++++------- include/configs/db-mv784mp-gp.h | 2 +- include/configs/edminiv2.h | 2 +- include/configs/maxbcm.h | 2 +- 6 files changed, 100 insertions(+), 34 deletions(-)
arch/arm/include/asm/arch-sunxi/i2c.h +1 -1
@@ -8,7 +8,7 @@#include <asm/arch/cpu.h> -#define CONFIG_I2C_MVTWSI_BASE SUNXI_TWI0_BASE +#define CONFIG_I2C_MVTWSI_BASE0 SUNXI_TWI0_BASE/* This is abp0-clk on sun4i/5i/7i / abp1-clk on sun6i/sun8i which is 24MHz */ #define CONFIG_SYS_TCLK 24000000
arch/arm/mach-kirkwood/include/mach/config.h +1 -1
@@ -44,7 +44,7 @@#define CONFIG_SYS_INIT_SP_ADDR 0xC8012000#define CONFIG_NR_DRAM_BANKS_MAX 2 -#define CONFIG_I2C_MVTWSI_BASE KW_TWSI_BASE +#define CONFIG_I2C_MVTWSI_BASE0 KW_TWSI_BASE#define MV_UART_CONSOLE_BASE KW_UART0_BASE#define MV_SATA_BASE KW_SATA_BASE#define MV_SATA_PORT0_OFFSET KW_SATA_PORT0_OFFSET
drivers/i2c/mvtwsi.c +95 -29
269 lines not on this page · raw message
include/configs/db-mv784mp-gp.h +1 -1
@@ -37,7 +37,7 @@/* I2C */ #define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_MVTWSI -#define CONFIG_I2C_MVTWSI_BASE MVEBU_TWSI_BASE +#define CONFIG_I2C_MVTWSI_BASE0 MVEBU_TWSI_BASE#define CONFIG_SYS_I2C_SLAVE 0x0#define CONFIG_SYS_I2C_SPEED 100000
include/configs/edminiv2.h +1 -1
@@ -208,7 +208,7 @@#ifdef CONFIG_CMD_I2C #define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_MVTWSI -#define CONFIG_I2C_MVTWSI_BASE ORION5X_TWSI_BASE +#define CONFIG_I2C_MVTWSI_BASE0 ORION5X_TWSI_BASE#define CONFIG_SYS_I2C_SLAVE 0x0#define CONFIG_SYS_I2C_SPEED 100000#endif
include/configs/maxbcm.h +1 -1
@@ -35,7 +35,7 @@/* I2C */ #define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_MVTWSI -#define CONFIG_I2C_MVTWSI_BASE MVEBU_TWSI_BASE +#define CONFIG_I2C_MVTWSI_BASE0 MVEBU_TWSI_BASE#define CONFIG_SYS_I2C_SLAVE 0x0#define CONFIG_SYS_I2C_SPEED 100000
Signature · 1 line
1.9.1
PATCH v3 1/3 i2c: mvtwsi: Support for up to 4 different controllers
Hello Paul,
Am 05.04.2015 09:51, schrieb Paul Kocialkowski:
Quoted 6 lines
Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) MVTWSI controller. However, other platforms using MVTWSI may come with more: this is the case on Allwinner (sunxi) platforms, where up to 4 controllers can be found on the same chip.
Signed-off-by Paul Kocialkowski <[email protected]>
Quoted 8 lines
--- arch/arm/include/asm/arch-sunxi/i2c.h | 2 +- arch/arm/mach-kirkwood/include/mach/config.h | 2 +- drivers/i2c/mvtwsi.c | 124 ++++++++++++++++++++------- include/configs/db-mv784mp-gp.h | 2 +- include/configs/edminiv2.h | 2 +- include/configs/maxbcm.h | 2 +- 6 files changed, 100 insertions(+), 34 deletions(-)
Thanks for your work. No comments from me, beside of the fact, that it would be nice if we could switch to use DM ;-)
@Hans: please pick up the hole series, thanks!
bye,
Heiko
Quoted 357 lines
arch/arm/include/asm/arch-sunxi/i2c.h +1
-1@@ -8,7 +8,7 @@#include <asm/arch/cpu.h> -#define CONFIG_I2C_MVTWSI_BASE SUNXI_TWI0_BASE +#define CONFIG_I2C_MVTWSI_BASE0 SUNXI_TWI0_BASE/* This is abp0-clk on sun4i/5i/7i / abp1-clk on sun6i/sun8i which is 24MHz */ #define CONFIG_SYS_TCLK 24000000arch/arm/mach-kirkwood/include/mach/config.h +1
-1@@ -44,7 +44,7 @@#define CONFIG_SYS_INIT_SP_ADDR 0xC8012000#define CONFIG_NR_DRAM_BANKS_MAX 2 -#define CONFIG_I2C_MVTWSI_BASE KW_TWSI_BASE +#define CONFIG_I2C_MVTWSI_BASE0 KW_TWSI_BASE#define MV_UART_CONSOLE_BASE KW_UART0_BASE#define MV_SATA_BASE KW_SATA_BASE#define MV_SATA_PORT0_OFFSET KW_SATA_PORT0_OFFSETdrivers/i2c/mvtwsi.c +95
-29@@ -14,7 +14,7 @@#include <asm/io.h> /* -* include a file that will provide CONFIG_I2C_MVTWSI_BASE +* include a file that will provide CONFIG_I2C_MVTWSI_BASE* * and possibly other settings */ @@ -91,11 +91,37 @@ struct mvtwsi_registers {#define MVTWSI_STATUS_IDLE 0xF8/* -* The single instance of the controller we'll be dealing with +* MVTWSI controller base */ -static struct mvtwsi_registers *twsi = - (struct mvtwsi_registers *)CONFIG_I2C_MVTWSI_BASE ; +static struct mvtwsi_registers *twsi_get_base (struct i2c_adapter *adap) +{ +switch (adap->hwadapnr) { +case 0 : +return (struct mvtwsi_registers *)CONFIG_I2C_MVTWSI_BASE0 ; +#ifdef CONFIG_I2C_MVTWSI_BASE1 +case 1 : +return (struct mvtwsi_registers *)CONFIG_I2C_MVTWSI_BASE1 ; +#endif +#ifdef CONFIG_I2C_MVTWSI_BASE2 +case 2 : +return (struct mvtwsi_registers *)CONFIG_I2C_MVTWSI_BASE2 ; +#endif +#ifdef CONFIG_I2C_MVTWSI_BASE3 +case 3 : +return (struct mvtwsi_registers *)CONFIG_I2C_MVTWSI_BASE3 ; +#endif +#ifdef CONFIG_I2C_MVTWSI_BASE4 +case 4 : +return (struct mvtwsi_registers *)CONFIG_I2C_MVTWSI_BASE4 ; +#endif +default : +printf ("Missing mvtwsi controller %d base\n" , adap->hwadapnr); +break ; + } + +return NULL ; +}/* * Returned statuses are 0 for success and nonzero otherwise. @@ -117,8 +143,9 @@ static struct mvtwsi_registers *twsi =* Wait for IFLG to raise, or return 'timeout'; then if status is as expected, * return 0 (ok) or return 'wrong status'. */ -static int twsi_wait (int expected_status) +static int twsi_wait (struct i2c_adapter *adap,int expected_status) { +struct mvtwsi_registers *twsi =twsi_get_base (adap);int control, status;int timeout =1000 ;@@ -153,35 +180,40 @@ static u8 twsi_control_flags = MVTWSI_CONTROL_TWSIEN;* Assert the START condition, either in a single I2C transaction * or inside back-to-back ones (repeated starts). */ -static int twsi_start (int expected_status) +static int twsi_start (struct i2c_adapter *adap,int expected_status) { +struct mvtwsi_registers *twsi =twsi_get_base (adap); +/* globally set TWSIEN in case it was not */ twsi_control_flags |=MVTWSI_CONTROL_TWSIEN ;/* assert START */ writel (twsi_control_flags |MVTWSI_CONTROL_START , &twsi->control);/* wait for controller to process START */ -return twsi_wait (expected_status); +return twsi_wait (adap, expected_status); }/* * Send a byte (i2c address or data). */ -static int twsi_send (u8 byte,int expected_status) +static int twsi_send (struct i2c_adapter *adap,u8 byte,int expected_status) { +struct mvtwsi_registers *twsi =twsi_get_base (adap); +/* put byte in data register for sending */ writel (byte, &twsi->data);/* clear any pending interrupt -- that'll cause sending */ writel (twsi_control_flags, &twsi->control);/* wait for controller to receive byte and check ACK */ -return twsi_wait (expected_status); +return twsi_wait (adap, expected_status); }/* * Receive a byte. * Global mvtwsi_control_flags variable says if we should ack or nak. */ -static int twsi_recv (u8 *byte) +static int twsi_recv (struct i2c_adapter *adap,u8 *byte) { +struct mvtwsi_registers *twsi =twsi_get_base (adap);int expected_status, status;/* compute expected status based on ACK bit in global control flags */ @@ -192,7 +224,7 @@ static int twsi_recv(u8 *byte)/* acknowledge *previous state* and launch receive */ writel (twsi_control_flags, &twsi->control);/* wait for controller to receive byte and assert ACK or NAK */ - status =twsi_wait (expected_status); + status =twsi_wait (adap, expected_status);/* if we did receive expected byte then store it */ if (status ==0 ) *byte =readl (&twsi->data);@@ -204,8 +236,9 @@ static int twsi_recv(u8 *byte)* Assert the STOP condition. * This is also used to force the bus back in idle (SDA=SCL=1). */ -static int twsi_stop (int status) +static int twsi_stop (struct i2c_adapter *adap,int status) { +struct mvtwsi_registers *twsi =twsi_get_base (adap);int control, stop_status;int timeout =1000 ;@@ -244,6 +277,7 @@ static unsigned int twsi_calc_freq(const int n, const int m)*/ static void twsi_reset (struct i2c_adapter *adap) { +struct mvtwsi_registers *twsi =twsi_get_base (adap);/* ensure controller will be enabled by any twsi*() function */ twsi_control_flags =MVTWSI_CONTROL_TWSIEN ;/* reset controller */ @@ -259,6 +293,7 @@ static void twsi_reset(struct i2c_adapter *adap)static unsigned int twsi_i2c_set_bus_speed (struct i2c_adapter *adap,unsigned int requested_speed) { +struct mvtwsi_registers *twsi =twsi_get_base (adap);unsigned int tmp_speed, highest_speed, n, m;unsigned int baud =0x44 ;/* baudrate at controller reset */ @@ -281,6 +316,8 @@ static unsigned int twsi_i2c_set_bus_speed(struct i2c_adapter *adap,static void twsi_i2c_init (struct i2c_adapter *adap,int speed,int slaveadd) { +struct mvtwsi_registers *twsi =twsi_get_base (adap); +/* reset controller */ twsi_reset (adap);/* set speed */ @@ -289,7 +326,7 @@ static void twsi_i2c_init(struct i2c_adapter *adap, int speed, int slaveadd)writel (slaveadd, &twsi->slave_address);writel (0 , &twsi->xtnd_slave_addr);/* assert STOP but don't care for the result */ - (void )twsi_stop (0 ); + (void )twsi_stop (adap,0 ); }/* @@ -297,7 +334,8 @@ static void twsi_i2c_init(struct i2c_adapter *adap, int speed, int slaveadd)* Common to i2c_probe, i2c_read and i2c_write. * Expected address status will derive from direction bit (bit 0) in addr. */ -static int i2c_begin (int expected_start_status,u8 addr) +static int i2c_begin (struct i2c_adapter *adap,int expected_start_status, +u8 addr) {int status, expected_addr_status;@@ -307,10 +345,10 @@ static int i2c_begin(int expected_start_status, u8 addr)else /* writing */ expected_addr_status =MVTWSI_STATUS_ADDR_W_ACK ;/* assert START */ - status =twsi_start (expected_start_status); + status =twsi_start (adap, expected_start_status);/* send out the address if the start went well */ if (status ==0 ) - status =twsi_send (addr, expected_addr_status); + status =twsi_send (adap, addr, expected_addr_status);/* return ok or status of first failure to caller */ return status; }@@ -325,12 +363,12 @@ static int twsi_i2c_probe(struct i2c_adapter *adap, uchar chip)int status;/* begin i2c read */ - status =i2c_begin (MVTWSI_STATUS_START , (chip <<1 ) |1 ); + status =i2c_begin (adap,MVTWSI_STATUS_START , (chip <<1 ) |1 );/* dummy read was accepted: receive byte but NAK it. */ if (status ==0 ) - status =twsi_recv (&dummy_byte); + status =twsi_recv (adap, &dummy_byte);/* Stop transaction */ -twsi_stop (0 ); +twsi_stop (adap,0 );/* return 0 or status of first failure */ return status; }@@ -351,15 +389,15 @@ static int twsi_i2c_read(struct i2c_adapter *adap, uchar chip, uint addr,int status;/* begin i2c write to send the address bytes */ - status =i2c_begin (MVTWSI_STATUS_START , (chip <<1 )); + status =i2c_begin (adap,MVTWSI_STATUS_START , (chip <<1 ));/* send addr bytes */ while ((status ==0 ) && alen--) - status =twsi_send (addr >> (8 *alen), + status =twsi_send (adap, addr >> (8 *alen),MVTWSI_STATUS_DATA_W_ACK );/* begin i2c read to receive eeprom data bytes */ if (status ==0 ) - status =i2c_begin ( -MVTWSI_STATUS_REPEATED_START , (chip <<1 ) |1 ); + status =i2c_begin (adap,MVTWSI_STATUS_REPEATED_START , + (chip <<1 ) |1 );/* prepare ACK if at least one byte must be received */ if (length >0 ) twsi_control_flags |=MVTWSI_CONTROL_ACK ;@@ -369,10 +407,10 @@ static int twsi_i2c_read(struct i2c_adapter *adap, uchar chip, uint addr,if (length ==0 ) twsi_control_flags &= ~MVTWSI_CONTROL_ACK ;/* read current byte */ - status =twsi_recv (data++); + status =twsi_recv (adap, data++); }/* Stop transaction */ - status =twsi_stop (status); + status =twsi_stop (adap, status);/* return 0 or status of first failure */ return status; }@@ -387,16 +425,16 @@ static int twsi_i2c_write(struct i2c_adapter *adap, uchar chip, uint addr,int status;/* begin i2c write to send the eeprom adress bytes then data bytes */ - status =i2c_begin (MVTWSI_STATUS_START , (chip <<1 )); + status =i2c_begin (adap,MVTWSI_STATUS_START , (chip <<1 ));/* send addr bytes */ while ((status ==0 ) && alen--) - status =twsi_send (addr >> (8 *alen), + status =twsi_send (adap, addr >> (8 *alen),MVTWSI_STATUS_DATA_W_ACK );/* send data bytes */ while ((status ==0 ) && (length-- >0 )) - status =twsi_send (*(data++),MVTWSI_STATUS_DATA_W_ACK ); + status =twsi_send (adap, *(data++),MVTWSI_STATUS_DATA_W_ACK );/* Stop transaction */ - status =twsi_stop (status); + status =twsi_stop (adap, status);/* return 0 or status of first failure */ return status; }@@ -405,3 +443,31 @@ U_BOOT_I2C_ADAP_COMPLETE(twsi0, twsi_i2c_init, twsi_i2c_probe, twsi_i2c_read, twsi_i2c_write, twsi_i2c_set_bus_speed, CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE, 0) +#ifdef CONFIG_I2C_MVTWSI_BASE1 +U_BOOT_I2C_ADAP_COMPLETE (twsi1, twsi_i2c_init, twsi_i2c_probe, + twsi_i2c_read, twsi_i2c_write, + twsi_i2c_set_bus_speed, + CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE, 1) + +#endif +#ifdef CONFIG_I2C_MVTWSI_BASE2 +U_BOOT_I2C_ADAP_COMPLETE (twsi2, twsi_i2c_init, twsi_i2c_probe, + twsi_i2c_read, twsi_i2c_write, + twsi_i2c_set_bus_speed, + CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE, 2) + +#endif +#ifdef CONFIG_I2C_MVTWSI_BASE3 +U_BOOT_I2C_ADAP_COMPLETE (twsi3, twsi_i2c_init, twsi_i2c_probe, + twsi_i2c_read, twsi_i2c_write, + twsi_i2c_set_bus_speed, + CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE, 3) + +#endif +#ifdef CONFIG_I2C_MVTWSI_BASE4 +U_BOOT_I2C_ADAP_COMPLETE (twsi4, twsi_i2c_init, twsi_i2c_probe, + twsi_i2c_read, twsi_i2c_write, + twsi_i2c_set_bus_speed, + CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE, 4) + +#endif include/configs/db-mv784mp-gp.h +1
-1@@ -37,7 +37,7 @@/* I2C */ #define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_MVTWSI -#define CONFIG_I2C_MVTWSI_BASE MVEBU_TWSI_BASE +#define CONFIG_I2C_MVTWSI_BASE0 MVEBU_TWSI_BASE#define CONFIG_SYS_I2C_SLAVE 0x0#define CONFIG_SYS_I2C_SPEED 100000include/configs/edminiv2.h +1
-1@@ -208,7 +208,7 @@#ifdef CONFIG_CMD_I2C #define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_MVTWSI -#define CONFIG_I2C_MVTWSI_BASE ORION5X_TWSI_BASE +#define CONFIG_I2C_MVTWSI_BASE0 ORION5X_TWSI_BASE#define CONFIG_SYS_I2C_SLAVE 0x0#define CONFIG_SYS_I2C_SPEED 100000#endif include/configs/maxbcm.h +1
-1@@ -35,7 +35,7 @@/* I2C */ #define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_MVTWSI -#define CONFIG_I2C_MVTWSI_BASE MVEBU_TWSI_BASE +#define CONFIG_I2C_MVTWSI_BASE0 MVEBU_TWSI_BASE#define CONFIG_SYS_I2C_SLAVE 0x0#define CONFIG_SYS_I2C_SPEED 100000
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
PATCH v3 1/3 i2c: mvtwsi: Support for up to 4 different controllers
Hi,
Quoted 18 lines · Heiko Schocher
Hello Paul,
Am 05.04.2015 09:51, schrieb Paul Kocialkowski:
Quoted 6 lines
Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) MVTWSI controller. However, other platforms using MVTWSI may come with more: this is the case on Allwinner (sunxi) platforms, where up to 4 controllers can be found on the same chip.
Signed-off-by Paul Kocialkowski <[email protected]>Quoted 8 lines
--- arch/arm/include/asm/arch-sunxi/i2c.h | 2 +- arch/arm/mach-kirkwood/include/mach/config.h | 2 +- drivers/i2c/mvtwsi.c | 124 ++++++++++++++++++++------- include/configs/db-mv784mp-gp.h | 2 +- include/configs/edminiv2.h | 2 +- include/configs/maxbcm.h | 2 +- 6 files changed, 100 insertions(+), 34 deletions(-)
Quoted 6 lines
Thanks for your work. No comments from me, beside of the fact, that it would be nice if we could switch to use DM ;-)
Acked-by Heiko Schocher <[email protected]>@Hans: please pick up the hole series, thanks!
Ok will do so as soon as there is a V4 addressing my last review comment.
Regards,
Hans
PATCH v3 1/3 i2c: mvtwsi: Support for up to 4 different controllers
Le mardi 07 avril 2015 ? 08:29 +0200, Hans de Goede a ?crit :
Quoted 24 lines
Hi,
Quoted 21 lines · Heiko Schocher
Hello Paul,
Am 05.04.2015 09:51, schrieb Paul Kocialkowski:
Quoted 6 lines
Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) MVTWSI controller. However, other platforms using MVTWSI may come with more: this is the case on Allwinner (sunxi) platforms, where up to 4 controllers can be found on the same chip.
Signed-off-by Paul Kocialkowski <[email protected]>Quoted 8 lines
--- arch/arm/include/asm/arch-sunxi/i2c.h | 2 +- arch/arm/mach-kirkwood/include/mach/config.h | 2 +- drivers/i2c/mvtwsi.c | 124 ++++++++++++++++++++------- include/configs/db-mv784mp-gp.h | 2 +- include/configs/edminiv2.h | 2 +- include/configs/maxbcm.h | 2 +- 6 files changed, 100 insertions(+), 34 deletions(-)Thanks for your work. No comments from me, beside of the fact, that it would be nice if we could switch to use DM ;-)
Quoted 6 lines
Quoted 3 lines
Acked-by Heiko Schocher <[email protected]>@Hans: please pick up the hole series, thanks!
Ok will do so as soon as there is a V4 addressing my last review comment.
Okay, I'll be submitting v4 soon then. Then it'll be time to take a close look at driver-model and device-tree!
Quoted 3 lines
Regards,
Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150407/d82d14bc/attachment.sig>
PATCH v3 2/3 sunxi: Complete i2c support for each supported platform
In reply to Paul KocialkowskiSunxi platforms come with at least 3 TWI (I2C) controllers and some platforms even have up to 5. This adds support for every controller on each supported platform, which is especially useful when using expansion ports on single-board- computers.
--- arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 7 +++ arch/arm/include/asm/arch-sunxi/gpio.h | 15 +++++- arch/arm/include/asm/arch-sunxi/i2c.h | 13 +++++ board/sunxi/Kconfig | 31 ++++++++++++ board/sunxi/board.c | 75 ++++++++++++++++++++++++++++- 5 files changed, 138 insertions(+), 3 deletions(-)
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h +7 -0
@@ -94,6 +94,13 @@#define SUNXI_TWI0_BASE 0x01c2ac00#define SUNXI_TWI1_BASE 0x01c2b000#define SUNXI_TWI2_BASE 0x01c2b400 +#ifdef CONFIG_MACH_SUN6I +#define SUNXI_TWI3_BASE 0x01c0b800 +#endif +#ifdef CONFIG_MACH_SUN7I +#define SUNXI_TWI3_BASE 0x01c2b800 +#define SUNXI_TWI4_BASE 0x01c2c000 +#endif #define SUNXI_CAN_BASE 0x01c2bc00
arch/arm/include/asm/arch-sunxi/gpio.h +14 -1
@@ -148,7 +148,11 @@ enum sunxi_gpio_number {#define SUN6I_GPA_SDC2 5#define SUN6I_GPA_SDC3 4 -#define SUNXI_GPB_TWI0 2 +#define SUN4I_GPB_TWI0 2 +#define SUN4I_GPB_TWI1 2 +#define SUN5I_GPB_TWI1 2 +#define SUN4I_GPB_TWI2 2 +#define SUN5I_GPB_TWI2 2#define SUN4I_GPB_UART0 2#define SUN5I_GPB_UART0 2
@@ -160,6 +164,7 @@ enum sunxi_gpio_number {#define SUNXI_GPD_LVDS0 3#define SUN5I_GPE_SDC2 3 +#define SUN8I_GPE_TWI2 3#define SUNXI_GPF_SDC0 2#define SUNXI_GPF_UART0 4
@@ -169,12 +174,20 @@ enum sunxi_gpio_number {#define SUN5I_GPG_SDC1 2#define SUN6I_GPG_SDC1 2#define SUN8I_GPG_SDC1 2 +#define SUN6I_GPG_TWI3 2#define SUN5I_GPG_UART1 4#define SUN4I_GPH_SDC1 5 +#define SUN6I_GPH_TWI0 2 +#define SUN8I_GPH_TWI0 2 +#define SUN6I_GPH_TWI1 2 +#define SUN8I_GPH_TWI1 2 +#define SUN6I_GPH_TWI2 2#define SUN6I_GPH_UART0 2#define SUNXI_GPI_SDC3 2 +#define SUN7I_GPI_TWI3 3 +#define SUN7I_GPI_TWI4 3#define SUN6I_GPL0_R_P2WI_SCK 3#define SUN6I_GPL1_R_P2WI_SDA 3
arch/arm/include/asm/arch-sunxi/i2c.h +13 -0
@@ -9,6 +9,19 @@#include <asm/arch/cpu.h> #define CONFIG_I2C_MVTWSI_BASE0 SUNXI_TWI0_BASE +#ifdef CONFIG_I2C1_ENABLE +#define CONFIG_I2C_MVTWSI_BASE1 SUNXI_TWI1_BASE +#endif +#ifdef CONFIG_I2C2_ENABLE +#define CONFIG_I2C_MVTWSI_BASE2 SUNXI_TWI2_BASE +#endif +#ifdef CONFIG_I2C3_ENABLE +#define CONFIG_I2C_MVTWSI_BASE3 SUNXI_TWI3_BASE +#endif +#ifdef CONFIG_I2C4_ENABLE +#define CONFIG_I2C_MVTWSI_BASE4 SUNXI_TWI4_BASE +#endif +/* This is abp0-clk on sun4i/5i/7i / abp1-clk on sun6i/sun8i which is 24MHz */ #define CONFIG_SYS_TCLK 24000000
board/sunxi/Kconfig +31 -0
@@ -269,6 +269,37 @@ config USB2_VBUS_PIN ---help--- See USB1_VBUS_PIN help text. +config I2C1_ENABLE + bool "Enable I2C/TWI controller 1" + default n + ---help--- + This allows enabling I2C/TWI controller 1 by muxing its pins, enabling + its clock and setting up the bus. This is especially useful on devices + with slaves connected to the bus or with pins exposed through e.g. an + expansion port/header. + +config I2C2_ENABLE + bool "Enable I2C/TWI controller 2" + default n + ---help--- + See I2C1_ENABLE help text. + +if MACH_SUN6I || MACH_SUN7I +config I2C3_ENABLE + bool "Enable I2C/TWI controller 3" + default n + ---help--- + See I2C1_ENABLE help text. +endif + +if MACH_SUN7I +config I2C4_ENABLE + bool "Enable I2C/TWI controller 4" + default n + ---help--- + See I2C1_ENABLE help text. +endif + config VIDEO boolean "Enable graphical uboot console on HDMI, LCD or VGA" default y
board/sunxi/board.c +73 -2
82 lines not on this page · raw message
Signature · 1 line
1.9.1
PATCH v3 3/3 sunxi: I2C/TWI configs for a few single-board-computers
In reply to Paul KocialkowskiThis enables the exposed I2C/TWI busses on a few single-board-computers (Olimex and Cubietech).
--- configs/A10-OLinuXino-Lime_defconfig | 2 ++ configs/A10s-OLinuXino-M_defconfig | 2 ++ configs/A13-OLinuXinoM_defconfig | 2 ++ configs/A13-OLinuXino_defconfig | 2 ++ configs/A20-OLinuXino-Lime2_defconfig | 2 ++ configs/A20-OLinuXino-Lime_defconfig | 2 ++ configs/A20-OLinuXino_MICRO_defconfig | 2 ++ configs/Cubieboard2_defconfig | 1 + configs/Cubieboard_defconfig | 1 + configs/Cubietruck_defconfig | 2 ++ 10 files changed, 18 insertions(+)
configs/A10-OLinuXino-Lime_defconfig +2 -0
@@ -1,6 +1,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI" CONFIG_FDTFILE="sun4i-a10-olinuxino-lime.dtb" +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN4I=y
configs/A10s-OLinuXino-M_defconfig +2 -0
@@ -5,6 +5,8 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=1 CONFIG_USB1_VBUS_PIN="PB10" CONFIG_MMC0_CD_PIN="PG1" CONFIG_MMC1_CD_PIN="PG13" +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN5I=y
configs/A13-OLinuXinoM_defconfig +2 -0
@@ -2,6 +2,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=2,USB_EHCI" CONFIG_FDTFILE="sun5i-a13-olinuxino-micro.dtb" CONFIG_USB1_VBUS_PIN="PG11" +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_VIDEO_HDMI=n CONFIG_VIDEO_VGA_VIA_LCD=y CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y
configs/A13-OLinuXino_defconfig +2 -0
@@ -2,6 +2,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=2,AXP209_POWER,USB_EHCI" CONFIG_FDTFILE="sun5i-a13-olinuxino.dtb" CONFIG_USB1_VBUS_PIN="PG11" +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_VIDEO_HDMI=n CONFIG_VIDEO_VGA_VIA_LCD=y CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y
configs/A20-OLinuXino-Lime2_defconfig +2 -0
@@ -4,6 +4,8 @@ CONFIG_FDTFILE="sun7i-a20-olinuxino-lime2.dtb" CONFIG_MMC0_CD_PIN="PH1" CONFIG_USB0_VBUS_PIN="PC17" CONFIG_USB0_VBUS_DET="PH5" +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN7I=y
configs/A20-OLinuXino-Lime_defconfig +2 -0
@@ -1,6 +1,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI" CONFIG_FDTFILE="sun7i-a20-olinuxino-lime.dtb" +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN7I=y
configs/A20-OLinuXino_MICRO_defconfig +2 -0
@@ -2,6 +2,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI" CONFIG_FDTFILE="sun7i-a20-olinuxino-micro.dtb" CONFIG_MMC_SUNXI_SLOT_EXTRA=3 +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_VIDEO_VGA=y CONFIG_MMC0_CD_PIN="PH1" CONFIG_MMC3_CD_PIN="PH11"
configs/Cubieboard2_defconfig +1 -0
@@ -2,6 +2,7 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI" CONFIG_FDTFILE="sun7i-a20-cubieboard2.dtb" CONFIG_MMC0_CD_PIN="PH1" +CONFIG_I2C1_ENABLE=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN7I=y
configs/Cubieboard_defconfig +1 -0
@@ -1,6 +1,7 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI" CONFIG_FDTFILE="sun4i-a10-cubieboard.dtb" +CONFIG_I2C1_ENABLE=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN4I=y
configs/Cubietruck_defconfig +2 -0
@@ -2,6 +2,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPH(12),USB_EHCI" CONFIG_FDTFILE="sun7i-a20-cubietruck.dtb" CONFIG_GMAC_TX_DELAY=1 +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_VIDEO_VGA=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y
Signature · 1 line
1.9.1
v3 cover i2c: sunxi: Support every i2c controller on each supported platform
In reply to Paul KocialkowskiHi,
Quoted 22 lines · Paul Kocialkowski
Changes since v2:
* I2C/TWI busses enable for Cubietruck as wellChanges since v1:
*Kconfigoption to enable I2C/TWI controllers 1-4 (when applicable)
* Following patch to enable exposed busses on a few community-supported single-board-computersThis series adds support for every i2c controller found on sun4i/sun5i/sun6i/sun7i/sun8i platforms and shouldn't break support for Marvell platforms (orion5x, kirkwood, armada xp) the driver was originally written for.
Regarding sunxi, I double-checked that this doesn't conflict with
VIDEO_LCD_PANEL_I2C.I would be interested in having this tested on sun8i (A23), since I changed TWI0 muxing (to PH2-PH3 instead of PB0-PB1), according to the user manual and what is being done on the upstream Linux kernel. I2C was either not working before, or it was being muxed correctly by the bootrom, probably to communicate with the AXP, which luckily made it work in U-Boot too, since the I/O base address was already correct.
Quoted 5 lines
My use case here is that I'm writing a slave-side bitbang i2c implementation (with an Arduino) for a school project, using a Cubieboard2 as master and U-Boot as POC. However, only TWI1 was available through the expansion pins, hence the need for this series.
Thanks for your work on this, may I request one more change ? For sunxi I would like to also see a CONFIG_I2C0_ENABLE, the reason for this is that on sun6i / sun8i we do not really use i2c0 as we use p2wi resp. rsb to talk to the axp pmic there.
This way we will not end up messing with the muxing of the PH14/15 (sun6i) resp. PH2/3 (sun8i) which may be used in some other fashion.
This also means making a small change to the first patch to also make registering of twsi0 #ifdef CONFIG_I2C_MVTWSI_BASE0 .
Can you please make the default for CONFIG_I2C0_ENABLE y on sun4i / sun5i / sun7i and n on others?
Also I'm not entirely convinced that patch 3/3 is a good idea, on the olimex boards which have a i2c eeprom enabling the attached i2c controller makes sense, but on the other boards the i2c pins are really just gpio pins, any daughter board can be connected including one which uses them differently. I believe that in the defconfig the i2c controllers should thus be left off. It is after all a default config, users with a daughter board which they want to use in u-boot can easily change the config after running make foo_defconfig.
Regards,
Hans
v3 cover i2c: sunxi: Support every i2c controller on each supported platform
Hi Hans,
Le dimanche 05 avril 2015 ? 10:44 +0200, Hans de Goede a ?crit :
Quoted 35 lines
Hi,
Quoted 22 lines · Paul Kocialkowski
Changes since v2:
* I2C/TWI busses enable for Cubietruck as wellChanges since v1:
*Kconfigoption to enable I2C/TWI controllers 1-4 (when applicable)
* Following patch to enable exposed busses on a few community-supported single-board-computersThis series adds support for every i2c controller found on sun4i/sun5i/sun6i/sun7i/sun8i platforms and shouldn't break support for Marvell platforms (orion5x, kirkwood, armada xp) the driver was originally written for.
Regarding sunxi, I double-checked that this doesn't conflict with
VIDEO_LCD_PANEL_I2C.I would be interested in having this tested on sun8i (A23), since I changed TWI0 muxing (to PH2-PH3 instead of PB0-PB1), according to the user manual and what is being done on the upstream Linux kernel. I2C was either not working before, or it was being muxed correctly by the bootrom, probably to communicate with the AXP, which luckily made it work in U-Boot too, since the I/O base address was already correct.
Quoted 5 lines
My use case here is that I'm writing a slave-side bitbang i2c implementation (with an Arduino) for a school project, using a Cubieboard2 as master and U-Boot as POC. However, only TWI1 was available through the expansion pins, hence the need for this series.
Thanks for your work on this, may I request one more change ? For sunxi I would like to also see a
CONFIG_I2C0_ENABLE, the reason for this is that on sun6i / sun8i we do not really use i2c0 as we use p2wi resp. rsb to talk to the axp pmic there.
Quoted 8 lines
This way we will not end up messing with the muxing of the PH14/15 (sun6i) resp. PH2/3 (sun8i) which may be used in some other fashion.
This also means making a small change to the first patch to also make registering of twsi0 #ifdef
CONFIG_I2C_MVTWSI_BASE0.Can you please make the default for
CONFIG_I2C0_ENABLEy on sun4i / sun5i / sun7i and n on others?
Ack that, it makes sense to me.
Quoted 7 lines
Also I'm not entirely convinced that patch 3/3 is a good idea, on the olimex boards which have a i2c eeprom enabling the attached i2c controller makes sense, but on the other boards the i2c pins are really just gpio pins, any daughter board can be connected including one which uses them differently. I believe that in the defconfig the i2c controllers should thus be left off. It is after all a default config, users with a daughter board which they want to use in u-boot can easily change the config after running make
foo_defconfig.
I think the right bargain here would be to enable i2c lines that already have something useful for U-Boot attached (e.g. not an accelerometer sensor). I concur to your point otherwise.
Signature · 17 lines
Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150405/dd539239/attachment.sig>
v3 cover i2c: sunxi: Support every i2c controller on each supported platform
Le dimanche 05 avril 2015 ? 22:59 +0200, Paul Kocialkowski a ?crit :
Quoted 4 lines
Hi Hans,
Le dimanche 05 avril 2015 ? 10:44 +0200, Hans de Goede a ?crit :
Quoted 1 line
Hi,
[snip]
Quoted 7 lines
Quoted 7 lines
Thanks for your work on this, may I request one more change ? For sunxi I would like to also see a
CONFIG_I2C0_ENABLE, the reason for this is that on sun6i / sun8i we do not really use i2c0 as we use p2wi resp. rsb to talk to the axp pmic there.This way we will not end up messing with the muxing of the PH14/15 (sun6i) resp. PH2/3 (sun8i) which may be used in some other fashion.
Quoted 7 lines
Quoted 5 lines
This also means making a small change to the first patch to also make registering of twsi0 #ifdef
CONFIG_I2C_MVTWSI_BASE0.Can you please make the default for
CONFIG_I2C0_ENABLEy on sun4i / sun5i / sun7i and n on others?Ack that, it makes sense to me.
Implementing this leads to build errors:drivers/i2c/mvtwsi.c:319:13: attention : ?twsi_i2c_init? defined but not used [-Wunused-function]drivers/i2c/mvtwsi.c:362:12: attention : ?twsi_i2c_probe? defined but not used [-Wunused-function]drivers/i2c/mvtwsi.c:388:12: attention : ?twsi_i2c_read? defined but not used [-Wunused-function]drivers/i2c/mvtwsi.c:424:12: attention : ?twsi_i2c_write? defined but not used [-Wunused-function]
Ways to get rid of those include:
* not building the driver at all when no controller 0 base is defined, which involves moving moving SYS_I2C_MVTWSI to Kconfig and selecting it when at least one i2c controller is selected in the sunxi Kconfig
* having twsi0 enabled on all sunxi devices, as it was before
What do you prefer?
Quoted 11 lines
Quoted 7 lines
Also I'm not entirely convinced that patch 3/3 is a good idea, on the olimex boards which have a i2c eeprom enabling the attached i2c controller makes sense, but on the other boards the i2c pins are really just gpio pins, any daughter board can be connected including one which uses them differently. I believe that in the defconfig the i2c controllers should thus be left off. It is after all a default config, users with a daughter board which they want to use in u-boot can easily change the config after running make
foo_defconfig.I think the right bargain here would be to enable i2c lines that already have something useful for U-Boot attached (e.g. not an accelerometer sensor). I concur to your point otherwise.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150407/99c34871/attachment.sig>
v3 cover i2c: sunxi: Support every i2c controller on each supported platform
Hi,
Quoted 33 lines · Paul Kocialkowski
Le dimanche 05 avril 2015 ? 22:59 +0200, Paul Kocialkowski a ?crit :
Quoted 4 lines
Hi Hans,
Le dimanche 05 avril 2015 ? 10:44 +0200, Hans de Goede a ?crit :
Quoted 1 line
Hi,
[snip]
Quoted 7 lines
Quoted 7 lines
Thanks for your work on this, may I request one more change ? For sunxi I would like to also see a
CONFIG_I2C0_ENABLE, the reason for this is that on sun6i / sun8i we do not really use i2c0 as we use p2wi resp. rsb to talk to the axp pmic there.This way we will not end up messing with the muxing of the PH14/15 (sun6i) resp. PH2/3 (sun8i) which may be used in some other fashion.
Quoted 7 lines
Quoted 5 lines
This also means making a small change to the first patch to also make registering of twsi0 #ifdef
CONFIG_I2C_MVTWSI_BASE0.Can you please make the default for
CONFIG_I2C0_ENABLEy on sun4i / sun5i / sun7i and n on others?Ack that, it makes sense to me.
Implementing this leads to build errors:
drivers/i2c/mvtwsi.c:319:13: attention : ?twsi_i2c_init? defined but not used [-Wunused-function]drivers/i2c/mvtwsi.c:362:12: attention : ?twsi_i2c_probe? defined but not used [-Wunused-function]drivers/i2c/mvtwsi.c:388:12: attention : ?twsi_i2c_read? defined but not used [-Wunused-function]drivers/i2c/mvtwsi.c:424:12: attention : ?twsi_i2c_write? defined but not used [-Wunused-function]
Quoted 7 lines
Ways to get rid of those include:
* not building the driver at all when no controller 0 base is defined, which involves moving movingSYS_I2C_MVTWSItoKconfigand selecting it when at least one i2c controller is selected in the sunxiKconfig
* having twsi0 enabled on all sunxi devices, as it was beforeWhat do you prefer?
I would prefer for the driver to not be build at all then, thank you for working on this.
Regards,
Hans
Quoted 12 lines
Quoted 12 lines
Quoted 8 lines
Also I'm not entirely convinced that patch 3/3 is a good idea, on the olimex boards which have a i2c eeprom enabling the attached i2c controller makes sense, but on the other boards the i2c pins are really just gpio pins, any daughter board can be connected including one which uses them differently. I believe that in the defconfig the i2c controllers should thus be left off. It is after all a default config, users with a daughter board which they want to use in u-boot can easily change the config after running make
foo_defconfig.I think the right bargain here would be to enable i2c lines that already have something useful for U-Boot attached (e.g. not an accelerometer sensor). I concur to your point otherwise.