Re: [U-Boot] [RFC PATCH 0/12] RFC: dm: Add I2C support
Hi Heiko, On 10 November 2014 00:16, Heiko Schocher h...@denx.de wrote: Hello Simon, sorry for the long delay... Am 13.10.2014 07:39, schrieb Simon Glass: (Note this is RFC since the uclass interface needs discussion and also because only sandbox is implemented so far. But I thought it best to get this out there as soon as I wrote it as it may influence the PMIC library, etc.) This series is an initial attempt to add I2C support to driver model. It has become apparent that this is a high priority as it is widely used. It follows along to some extent from the SPI conversion. Several changes are made from the original I2C implementations. Firstly It is not necessary to specify the chip address with every call, since each chip knows its own address - it is stored in struct dm_i2c_chip which is attached to each chip on the I2C bus. However, this information *is* passed to the driver since I presume most drivers need it and it would be cumbersome to look up in every call. Secondly there is no concept of a 'current' I2C bus so all associated logic is removed. With driver model i2c_set_bus_num() and i2c_get_bus_num() are not available. Since the chip device specifies both the bus and the chip address, there is no need for this concept. It also causes problems when one driver changes the current bus and forgets to change it back. Thirdly initialisation is handled by driver model's normal probe() method on each device so there should be no need for i2c_init_all(), i2c_init(), i2c_init_board(), i2c_board_late_init() and board_i2c_init(). Great! I2C muxes are not yet supported. To support these we will need to maintain state of the current mux settings to avoid resetting every mux every time. Probably we need to add a sandbox I2C mux driver to permit testing of this. This can probably be done later. Currently only the keymile boards really use i2c muxes, so I am fine with doing this in a second step. Platform data is not yet supported either, only device tree. The U_BOOT_I2C_MKENT_COMPLETE() and U_BOOT_I2C_ADAP_COMPLETE() macros are not used. Also struct i2c_adapter is not defined anymore. This will need to be addressed, perhaps as part of converting over a board that does not use device tree. Ok for this in the first step... The question raised if we only would support Device tree with DM ... so maybe we do not need to do this step. I am not really sure, if we should really support Device Tree only with DM, because: - do all archs switch to Device Tree in the near future? - in SPL we have really on some SoCs small memory (like I just work on some AT91 boards which have 4k only!) To get DM with Device Tree into 4k is a big challenge ... so in my opinion, it would be good to have the possibility of Platform data ... so we prevent to make dirty hacks for the SPL case (I hope) ... This series is available at u-boot-dm/i2c-working. Thanks for your great work. I looked through your patchset and have no real objection against it ... To the i2c deblocking subject ... we should add at least the deblock() in struct dm_i2c_ops and call it do_i2c_reset if defined ... beside of this, you can add my Acked-by: Heiko Schocher h...@denx.de to the hole series. Thanks for reviewing this. I have added the deblock() method and also the generic I2C support (allows you to use a device on the command line without it having a proper driver). There are a few changes so if you have time to take another look I will definitely add your Acked-by. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/12] RFC: dm: Add I2C support
Hello Simon, sorry for the long delay... Am 13.10.2014 07:39, schrieb Simon Glass: (Note this is RFC since the uclass interface needs discussion and also because only sandbox is implemented so far. But I thought it best to get this out there as soon as I wrote it as it may influence the PMIC library, etc.) This series is an initial attempt to add I2C support to driver model. It has become apparent that this is a high priority as it is widely used. It follows along to some extent from the SPI conversion. Several changes are made from the original I2C implementations. Firstly It is not necessary to specify the chip address with every call, since each chip knows its own address - it is stored in struct dm_i2c_chip which is attached to each chip on the I2C bus. However, this information *is* passed to the driver since I presume most drivers need it and it would be cumbersome to look up in every call. Secondly there is no concept of a 'current' I2C bus so all associated logic is removed. With driver model i2c_set_bus_num() and i2c_get_bus_num() are not available. Since the chip device specifies both the bus and the chip address, there is no need for this concept. It also causes problems when one driver changes the current bus and forgets to change it back. Thirdly initialisation is handled by driver model's normal probe() method on each device so there should be no need for i2c_init_all(), i2c_init(), i2c_init_board(), i2c_board_late_init() and board_i2c_init(). Great! I2C muxes are not yet supported. To support these we will need to maintain state of the current mux settings to avoid resetting every mux every time. Probably we need to add a sandbox I2C mux driver to permit testing of this. This can probably be done later. Currently only the keymile boards really use i2c muxes, so I am fine with doing this in a second step. Platform data is not yet supported either, only device tree. The U_BOOT_I2C_MKENT_COMPLETE() and U_BOOT_I2C_ADAP_COMPLETE() macros are not used. Also struct i2c_adapter is not defined anymore. This will need to be addressed, perhaps as part of converting over a board that does not use device tree. Ok for this in the first step... The question raised if we only would support Device tree with DM ... so maybe we do not need to do this step. I am not really sure, if we should really support Device Tree only with DM, because: - do all archs switch to Device Tree in the near future? - in SPL we have really on some SoCs small memory (like I just work on some AT91 boards which have 4k only!) To get DM with Device Tree into 4k is a big challenge ... so in my opinion, it would be good to have the possibility of Platform data ... so we prevent to make dirty hacks for the SPL case (I hope) ... This series is available at u-boot-dm/i2c-working. Thanks for your great work. I looked through your patchset and have no real objection against it ... To the i2c deblocking subject ... we should add at least the deblock() in struct dm_i2c_ops and call it do_i2c_reset if defined ... beside of this, you can add my Acked-by: Heiko Schocher h...@denx.de to the hole series. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/12] RFC: dm: Add I2C support
Hello Tom, Am 24.10.2014 17:03, schrieb Tom Rini: On Sun, Oct 12, 2014 at 11:39:26PM -0600, Simon Glass wrote: (Note this is RFC since the uclass interface needs discussion and also because only sandbox is implemented so far. But I thought it best to get this out there as soon as I wrote it as it may influence the PMIC library, etc.) This series is an initial attempt to add I2C support to driver model. It has become apparent that this is a high priority as it is widely used. It follows along to some extent from the SPI conversion. Several changes are made from the original I2C implementations. Firstly It is not necessary to specify the chip address with every call, since each chip knows its own address - it is stored in struct dm_i2c_chip which is attached to each chip on the I2C bus. However, this information *is* passed to the driver since I presume most drivers need it and it would be cumbersome to look up in every call. Secondly there is no concept of a 'current' I2C bus so all associated logic is removed. With driver model i2c_set_bus_num() and i2c_get_bus_num() are not available. Since the chip device specifies both the bus and the chip address, there is no need for this concept. It also causes problems when one driver changes the current bus and forgets to change it back. Thirdly initialisation is handled by driver model's normal probe() method on each device so there should be no need for i2c_init_all(), i2c_init(), i2c_init_board(), i2c_board_late_init() and board_i2c_init(). I2C muxes are not yet supported. To support these we will need to maintain state of the current mux settings to avoid resetting every mux every time. Probably we need to add a sandbox I2C mux driver to permit testing of this. This can probably be done later. Platform data is not yet supported either, only device tree. The U_BOOT_I2C_MKENT_COMPLETE() and U_BOOT_I2C_ADAP_COMPLETE() macros are not used. Also struct i2c_adapter is not defined anymore. This will need to be addressed, perhaps as part of converting over a board that does not use device tree. This series is available at u-boot-dm/i2c-working. Nothing jumped out at me. Heiko? Looking in this patches soon... sorry for the delay. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/12] RFC: dm: Add I2C support
On Sun, Oct 12, 2014 at 11:39:26PM -0600, Simon Glass wrote: (Note this is RFC since the uclass interface needs discussion and also because only sandbox is implemented so far. But I thought it best to get this out there as soon as I wrote it as it may influence the PMIC library, etc.) This series is an initial attempt to add I2C support to driver model. It has become apparent that this is a high priority as it is widely used. It follows along to some extent from the SPI conversion. Several changes are made from the original I2C implementations. Firstly It is not necessary to specify the chip address with every call, since each chip knows its own address - it is stored in struct dm_i2c_chip which is attached to each chip on the I2C bus. However, this information *is* passed to the driver since I presume most drivers need it and it would be cumbersome to look up in every call. Secondly there is no concept of a 'current' I2C bus so all associated logic is removed. With driver model i2c_set_bus_num() and i2c_get_bus_num() are not available. Since the chip device specifies both the bus and the chip address, there is no need for this concept. It also causes problems when one driver changes the current bus and forgets to change it back. Thirdly initialisation is handled by driver model's normal probe() method on each device so there should be no need for i2c_init_all(), i2c_init(), i2c_init_board(), i2c_board_late_init() and board_i2c_init(). I2C muxes are not yet supported. To support these we will need to maintain state of the current mux settings to avoid resetting every mux every time. Probably we need to add a sandbox I2C mux driver to permit testing of this. This can probably be done later. Platform data is not yet supported either, only device tree. The U_BOOT_I2C_MKENT_COMPLETE() and U_BOOT_I2C_ADAP_COMPLETE() macros are not used. Also struct i2c_adapter is not defined anymore. This will need to be addressed, perhaps as part of converting over a board that does not use device tree. This series is available at u-boot-dm/i2c-working. Nothing jumped out at me. Heiko? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 0/12] RFC: dm: Add I2C support
(Note this is RFC since the uclass interface needs discussion and also because only sandbox is implemented so far. But I thought it best to get this out there as soon as I wrote it as it may influence the PMIC library, etc.) This series is an initial attempt to add I2C support to driver model. It has become apparent that this is a high priority as it is widely used. It follows along to some extent from the SPI conversion. Several changes are made from the original I2C implementations. Firstly It is not necessary to specify the chip address with every call, since each chip knows its own address - it is stored in struct dm_i2c_chip which is attached to each chip on the I2C bus. However, this information *is* passed to the driver since I presume most drivers need it and it would be cumbersome to look up in every call. Secondly there is no concept of a 'current' I2C bus so all associated logic is removed. With driver model i2c_set_bus_num() and i2c_get_bus_num() are not available. Since the chip device specifies both the bus and the chip address, there is no need for this concept. It also causes problems when one driver changes the current bus and forgets to change it back. Thirdly initialisation is handled by driver model's normal probe() method on each device so there should be no need for i2c_init_all(), i2c_init(), i2c_init_board(), i2c_board_late_init() and board_i2c_init(). I2C muxes are not yet supported. To support these we will need to maintain state of the current mux settings to avoid resetting every mux every time. Probably we need to add a sandbox I2C mux driver to permit testing of this. This can probably be done later. Platform data is not yet supported either, only device tree. The U_BOOT_I2C_MKENT_COMPLETE() and U_BOOT_I2C_ADAP_COMPLETE() macros are not used. Also struct i2c_adapter is not defined anymore. This will need to be addressed, perhaps as part of converting over a board that does not use device tree. This series is available at u-boot-dm/i2c-working. Simon Glass (12): dm: core: Allow access to the device's driver_id data dm: core: Add functions to find parent and OF data dm: i2c: Add a uclass for I2C dm: i2c: Implement driver model support in the i2c command dm: i2c: Add I2C emulation driver for sandbox dm: i2c: Add a sandbox I2C driver dm: i2c: Add an I2C EEPROM simulator dm: i2c: config: Enable I2C for sandbox using driver model dm: i2c: dts: Add an I2C bus for sandbox dm: WIP: EEPROM driver dm: i2c: Add tests for I2C dm: i2c: tegra: Convert to driver model for I2C for seaboard arch/arm/cpu/tegra20-common/pmu.c | 21 +- arch/arm/include/asm/arch-tegra/tegra_i2c.h | 2 +- arch/sandbox/dts/sandbox.dts| 17 ++ board/nvidia/common/board.c | 4 - common/cmd_i2c.c| 312 +++ drivers/core/device.c | 10 + drivers/core/lists.c| 17 +- drivers/i2c/Makefile| 2 + drivers/i2c/i2c-emul-uclass.c | 14 ++ drivers/i2c/i2c-uclass.c| 177 drivers/i2c/sandbox_i2c.c | 148 + drivers/i2c/tegra_i2c.c | 313 ++-- drivers/misc/Makefile | 4 + drivers/misc/i2c_eeprom.c | 51 + drivers/misc/i2c_eeprom_emul.c | 108 ++ drivers/power/tps6586x.c| 27 +-- include/config_fallbacks.h | 6 + include/configs/cardhu.h| 2 - include/configs/colibri_t30.h | 2 - include/configs/sandbox.h | 6 + include/configs/seaboard.h | 3 - include/configs/tegra-common.h | 1 + include/configs/tegra20-common.h| 3 - include/dm/device.h | 19 ++ include/dm/uclass-id.h | 3 + include/i2c.h | 252 ++ include/i2c_eeprom.h| 19 ++ include/tps6586x.h | 2 +- test/dm/Makefile| 1 + test/dm/i2c.c | 100 + test/dm/test.dts| 17 ++ 31 files changed, 1373 insertions(+), 290 deletions(-) create mode 100644 drivers/i2c/i2c-emul-uclass.c create mode 100644 drivers/i2c/i2c-uclass.c create mode 100644 drivers/i2c/sandbox_i2c.c create mode 100644 drivers/misc/i2c_eeprom.c create mode 100644 drivers/misc/i2c_eeprom_emul.c create mode 100644 include/i2c_eeprom.h create mode 100644 test/dm/i2c.c -- 2.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
