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
