Re: [U-Boot] [PATCH v2 0/17] dm: Add I2C support and convert sandbox, tegra
Hi Heiko, On 19 November 2014 13:08, Heiko Schocher h...@denx.de wrote: Hello Masahiro, Am 19.11.2014 09:27, schrieb Masahiro Yamada: Hi Simon, On Tue, 11 Nov 2014 10:46:16 -0700 Simon Glass s...@chromium.org wrote: This series adds 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 This statement implies that platform data will (should) be supported in the future, I think. There was a discussion on the ELCE2014 and I think, I thought such a thread also on the list, if we should only support device tree with DM ... As you know, I have a strong belief that device tree should be left optional. Yes, I think in this direction too ... as I do not know, if all archs ever support DT ... and in the SPL case we should have a memory friendlier option too ... My feeling is that if Linux uses FDT for a platform (e.g. ARM) we should do so in U-Boot. If platform data is supported someday, that's OK. Patches welcome ... I have this on my ToDo list, but find currently no time ... I'm going to play around with a PPC board at some point, so will see what happens there. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/17] dm: Add I2C support and convert sandbox, tegra
Hello Simon, Am 20.11.2014 18:31, schrieb Simon Glass: Hi Heiko, On 19 November 2014 13:08, Heiko Schocher h...@denx.de wrote: Hello Masahiro, Am 19.11.2014 09:27, schrieb Masahiro Yamada: Hi Simon, On Tue, 11 Nov 2014 10:46:16 -0700 Simon Glass s...@chromium.org wrote: This series adds 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 This statement implies that platform data will (should) be supported in the future, I think. There was a discussion on the ELCE2014 and I think, I thought such a thread also on the list, if we should only support device tree with DM ... As you know, I have a strong belief that device tree should be left optional. Yes, I think in this direction too ... as I do not know, if all archs ever support DT ... and in the SPL case we should have a memory friendlier option too ... My feeling is that if Linux uses FDT for a platform (e.g. ARM) we should do so in U-Boot. Yes, but we have architectures without FDT support yet ... and we boot also non linux OSes ... If platform data is supported someday, that's OK. Patches welcome ... I have this on my ToDo list, but find currently no time ... I'm going to play around with a PPC board at some point, so will see what happens there. Great, but powerpc should work with DT too... 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] [PATCH v2 0/17] dm: Add I2C support and convert sandbox, tegra
Hi Simon, On Tue, 11 Nov 2014 10:46:16 -0700 Simon Glass s...@chromium.org wrote: This series adds 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 This statement implies that platform data will (should) be supported in the future, I think. As you know, I have a strong belief that device tree should be left optional. If platform data is supported someday, that's OK. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/17] dm: Add I2C support and convert sandbox, tegra
Hello Masahiro, Am 19.11.2014 09:27, schrieb Masahiro Yamada: Hi Simon, On Tue, 11 Nov 2014 10:46:16 -0700 Simon Glass s...@chromium.org wrote: This series adds 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 This statement implies that platform data will (should) be supported in the future, I think. There was a discussion on the ELCE2014 and I think, I thought such a thread also on the list, if we should only support device tree with DM ... As you know, I have a strong belief that device tree should be left optional. Yes, I think in this direction too ... as I do not know, if all archs ever support DT ... and in the SPL case we should have a memory friendlier option too ... If platform data is supported someday, that's OK. Patches welcome ... I have this on my ToDo list, but find currently no time ... 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] [PATCH v2 0/17] dm: Add I2C support and convert sandbox, tegra
Hello Simon, Am 11.11.2014 18:46, schrieb Simon Glass: This series adds 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, assuming that we want to support this. The following I2C CONFIGs are no-longer needed when driver model is used: CONFIG_SYS_I2C_INIT_BOARD - each I2C bus is inited in its probe() method CONFIG_I2C_MULTI_BUS - we always support multi-bus with driver model CONFIG_SYS_MAX_I2C_BUS- the device tree aliases define available buses CONFIG_SYS_I2C_SPEED - the device tree specifies the speed for each bus CONFIG_SYS_I2C- this is the 'new old' API, now deprecated There are a few SPI patches included here due to a dependency on a new device binding function. This series is available at u-boot-dm/i2c-working. Changes in v2: - Add a suitable commit message - Add new patch to correct handling of aliases with embedded digits - Add new patch to add a function to bind a device by driver name - Add new patches to adjust SPI to use device_bind_driver() - Fix cihp typo - Implement generic I2C devices to allow 'i2c probe' on unknown devices - Return the probed device from i2c_probe() - Set the bus speed after the bus is probed - Add some debugging for generic I2C device binding - Add a 'deblock' method to recover an I2C bus stuck in mid-transaction - Add a helper function to find a chip on a particular bus number - Change alen to int so that it can be -1 (this was a bug) - Call the deblock() method for 'i2c reset' - Update commit message for EEPROM driver - Add a test for automatic binding of generic I2C devices - Add a new asm/test.h header for tests in sandbox - Adjust tegra_i2c_child_pre_probe() to permit generic I2C devices - Correct the compatible strings for I2C buses - Don't init if the speed is 0, since this breaks the controller - Expand coverage to all Tegra boards Simon Glass (17): dm: i2c: Move error reporting into a common function dm: core: Allow access to the device's driver_id data dm: core: Add functions to find parent and OF data dm: fdt: Correct handling of aliases with embedded digits dm: Add a function to bind a device by driver name dm: spi: Correct handling of SPI chip selects in sandbox dm: spi: Use device_bind_driver() instead of our own function 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: Add a simple EEPROM driver dm: i2c: Add tests for I2C dm: i2c: tegra: Convert to driver model arch/arm/cpu/tegra20-common/pmu.c | 21 +- arch/arm/dts/tegra124-jetson-tk1.dts| 1 - arch/arm/dts/tegra124-norrin.dts| 1 - arch/arm/dts/tegra30-tec-ng.dts | 4 + arch/arm/include/asm/arch-tegra/tegra_i2c.h | 2 +- arch/sandbox/dts/sandbox.dts| 17 ++ arch/sandbox/include/asm/test.h | 15 ++ board/avionic-design/common/tamonten-ng.c | 12 +- board/nvidia/cardhu/cardhu.c| 13 +- board/nvidia/common/board.c | 4 - board/nvidia/dalmore/dalmore.c | 21 +- board/nvidia/whistler/whistler.c
Re: [U-Boot] [PATCH v2 0/17] dm: Add I2C support and convert sandbox, tegra
Hi Heiko, On 17 November 2014 06:42, Heiko Schocher h...@denx.de wrote: Hello Simon, Am 11.11.2014 18:46, schrieb Simon Glass: This series adds 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, assuming that we want to support this. The following I2C CONFIGs are no-longer needed when driver model is used: CONFIG_SYS_I2C_INIT_BOARD - each I2C bus is inited in its probe() method CONFIG_I2C_MULTI_BUS - we always support multi-bus with driver model CONFIG_SYS_MAX_I2C_BUS- the device tree aliases define available buses CONFIG_SYS_I2C_SPEED - the device tree specifies the speed for each bus CONFIG_SYS_I2C- this is the 'new old' API, now deprecated There are a few SPI patches included here due to a dependency on a new device binding function. This series is available at u-boot-dm/i2c-working. Changes in v2: - Add a suitable commit message - Add new patch to correct handling of aliases with embedded digits - Add new patch to add a function to bind a device by driver name - Add new patches to adjust SPI to use device_bind_driver() - Fix cihp typo - Implement generic I2C devices to allow 'i2c probe' on unknown devices - Return the probed device from i2c_probe() - Set the bus speed after the bus is probed - Add some debugging for generic I2C device binding - Add a 'deblock' method to recover an I2C bus stuck in mid-transaction - Add a helper function to find a chip on a particular bus number - Change alen to int so that it can be -1 (this was a bug) - Call the deblock() method for 'i2c reset' - Update commit message for EEPROM driver - Add a test for automatic binding of generic I2C devices - Add a new asm/test.h header for tests in sandbox - Adjust tegra_i2c_child_pre_probe() to permit generic I2C devices - Correct the compatible strings for I2C buses - Don't init if the speed is 0, since this breaks the controller - Expand coverage to all Tegra boards Simon Glass (17): dm: i2c: Move error reporting into a common function dm: core: Allow access to the device's driver_id data dm: core: Add functions to find parent and OF data dm: fdt: Correct handling of aliases with embedded digits dm: Add a function to bind a device by driver name dm: spi: Correct handling of SPI chip selects in sandbox dm: spi: Use device_bind_driver() instead of our own function 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: Add a simple EEPROM driver dm: i2c: Add tests for I2C dm: i2c: tegra: Convert to driver model arch/arm/cpu/tegra20-common/pmu.c | 21 +- arch/arm/dts/tegra124-jetson-tk1.dts| 1 - arch/arm/dts/tegra124-norrin.dts| 1 - arch/arm/dts/tegra30-tec-ng.dts | 4 + arch/arm/include/asm/arch-tegra/tegra_i2c.h | 2 +- arch/sandbox/dts/sandbox.dts| 17 ++ arch/sandbox/include/asm/test.h | 15 ++ board/avionic-design/common/tamonten-ng.c | 12 +- board/nvidia/cardhu/cardhu.c
[U-Boot] [PATCH v2 0/17] dm: Add I2C support and convert sandbox, tegra
This series adds 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, assuming that we want to support this. The following I2C CONFIGs are no-longer needed when driver model is used: CONFIG_SYS_I2C_INIT_BOARD - each I2C bus is inited in its probe() method CONFIG_I2C_MULTI_BUS - we always support multi-bus with driver model CONFIG_SYS_MAX_I2C_BUS- the device tree aliases define available buses CONFIG_SYS_I2C_SPEED - the device tree specifies the speed for each bus CONFIG_SYS_I2C- this is the 'new old' API, now deprecated There are a few SPI patches included here due to a dependency on a new device binding function. This series is available at u-boot-dm/i2c-working. Changes in v2: - Add a suitable commit message - Add new patch to correct handling of aliases with embedded digits - Add new patch to add a function to bind a device by driver name - Add new patches to adjust SPI to use device_bind_driver() - Fix cihp typo - Implement generic I2C devices to allow 'i2c probe' on unknown devices - Return the probed device from i2c_probe() - Set the bus speed after the bus is probed - Add some debugging for generic I2C device binding - Add a 'deblock' method to recover an I2C bus stuck in mid-transaction - Add a helper function to find a chip on a particular bus number - Change alen to int so that it can be -1 (this was a bug) - Call the deblock() method for 'i2c reset' - Update commit message for EEPROM driver - Add a test for automatic binding of generic I2C devices - Add a new asm/test.h header for tests in sandbox - Adjust tegra_i2c_child_pre_probe() to permit generic I2C devices - Correct the compatible strings for I2C buses - Don't init if the speed is 0, since this breaks the controller - Expand coverage to all Tegra boards Simon Glass (17): dm: i2c: Move error reporting into a common function dm: core: Allow access to the device's driver_id data dm: core: Add functions to find parent and OF data dm: fdt: Correct handling of aliases with embedded digits dm: Add a function to bind a device by driver name dm: spi: Correct handling of SPI chip selects in sandbox dm: spi: Use device_bind_driver() instead of our own function 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: Add a simple EEPROM driver dm: i2c: Add tests for I2C dm: i2c: tegra: Convert to driver model arch/arm/cpu/tegra20-common/pmu.c | 21 +- arch/arm/dts/tegra124-jetson-tk1.dts| 1 - arch/arm/dts/tegra124-norrin.dts| 1 - arch/arm/dts/tegra30-tec-ng.dts | 4 + arch/arm/include/asm/arch-tegra/tegra_i2c.h | 2 +- arch/sandbox/dts/sandbox.dts| 17 ++ arch/sandbox/include/asm/test.h | 15 ++ board/avionic-design/common/tamonten-ng.c | 12 +- board/nvidia/cardhu/cardhu.c| 13 +- board/nvidia/common/board.c | 4 - board/nvidia/dalmore/dalmore.c | 21 +- board/nvidia/whistler/whistler.c| 29 ++- board/toradex/apalis_t30/apalis_t30.c | 19 +- common/cmd_i2c.c
