Hello Simon,
Am 27.08.2014 21:10, schrieb Simon Glass:
Hi Thierry,
On 27 August 2014 05:41, Thierry Reding<thierry.red...@gmail.com> wrote:
On Wed, Aug 27, 2014 at 11:56:41AM +0200, Heiko Schocher wrote:
Hello Thierry,
Am 27.08.2014 10:51, schrieb Thierry Reding:
On Wed, Aug 27, 2014 at 09:07:58AM +0200, Heiko Schocher wrote:
Hello Thierry,
Am 27.08.2014 08:21, schrieb Thierry Reding:
On Wed, Aug 27, 2014 at 07:21:51AM +0200, Heiko Schocher wrote:
Hello Thierry,
Am 26.08.2014 17:34, schrieb Thierry Reding:
From: Thierry Reding<tred...@nvidia.com>
This API operates on I2C adapters or I2C clients (a new type of object
which is a bad idea ...
that refers to a particular slave connected to an adapter). This is
useful to avoid having to call i2c_set_bus_num() whenever a device is
being accessed.
But thats the supose of i2c_set_bus_num()! ... if you use an i2c bus,
you must check before every access, if you are on it, if not, you must
switch back to it...
That's not what code does today. Everybody calls i2c_set_bus_num() once
and then does a bunch of transactions on that bus. Given that U-Boot
Yes, sadly. This has historical reasons ...
doesn't run multithreaded this works. If you're really concerned about
Yes, U-Boot is singlethread only.
this being a problem, then it should be solved at a different level. It
could be part of i2c_client for example, so that i2c_client_read() and
i2c_client_write() would always perform this step. Burdening users with
Exactly, thats right, and this is a goal from the CONFIG_SYS_I2C API!
But why do you introduce i2c_client_read/write and do not add this step
to i2c_read/write?
- convert all i2c drivers, which are not yet converted to CONFIG_SYS_I2C
(get also rid od CONFIG_HARD_I2C)
- add busnumber to i2c_read/write API and make i2c_set_bus_num() static ...
and fix all i2c_read/write() calls in U-Boot code ...
I don't think adding a bus number as parameter is useful. Why not just
use the I2C adapter directly? That way we don't have to keep looking it
up in an array every time.
You again just talk from i2c_adapter ... why you ignore i2c muxes?
A bus is not only an i2c adapter ...
I know. I keep saying i2c_adapter because in the rough sketch that I
have in mind for how this could work eventually, an mux is just another
special kind of i2c_adapter.
Currently we have two "versions" of i2c_adapter:
In a system without muxes, you can say: i2c bus == i2c adapter
but in a system with muxes we have: i2c bus == i2c_bus_hose
i2c commands use also a "bus number" starting from 0 ... the bus number
has historical reasons... we could change this ...
But if we introduce a new API, please with mux functionallity ...
Hmm.. thinking about it ... if you want to introduce a new API, please
start with using the DM for I2C!
I can look into it, but it sounds like a task way beyond what I have
time for right now.
I can help if you are interested. I have patches for SPI at
u-boot-dm.git (branch working) and would like to have I2C. They are
sort-of similar so it might not be to hard to convert Tegra I2C over.
The concept of a 'current' bus is broken IMO. Maybe the command line
should have this concept, and maintain a 'current hose' or whatever.
But drives and other code should specific what they need with each
transaction. With DM that will likely be automatic.
That sounds great! I vote for using DM.
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
