[U-Boot-Users] Proposal to add "ispeed" (I2C speed) command

[U-Boot-Users] Proposal to add "ispeed" (I2C speed) command

[listmember at orkun.us]

We have some instrumentation hanging on I2C bus. I would like to introduce
a new u-boot command ispeed to set the i2c speed so fast devices would not
be constrained to the lowest denominator speed.

If desired we can make be conditionally included if CONFIG_CMD_ISPEED
(suggestions?) so it would not take space when it is not needed (or
desired) on a particular board. The proposed syntax would be.

ispeed {i2c bus speed}

Since u-boot uses hex: 100kHz => 186A0, 400kHz => 61A80

I would also set an environment variable in ispeed command indicating
current i2c speed ("i2cspeed") so it could be used in scripts.

Looking for your comments?

Best regards,
Tolunay

[U-Boot-Users] Proposal to add "ispeed" (I2C speed) command

[Stephan Linz]

Hi Tolunay,

Am Mittwoch,  3. M?rz 2004 18:36 schrieb listmember at orkun.us:
> We have some instrumentation hanging on I2C bus. I would like to introduce
> a new u-boot command ispeed to set the i2c speed so fast devices would not
> be constrained to the lowest denominator speed.

Makes sense, but why do you need measuring datas in context of a bootloader ?

>
> If desired we can make be conditionally included if CONFIG_CMD_ISPEED
> (suggestions?) so it would not take space when it is not needed (or
> desired) on a particular board. The proposed syntax would be.
>
> ispeed {i2c bus speed}
>
> Since u-boot uses hex: 100kHz => 186A0, 400kHz => 61A80

Hm, I think you should expand the command syntax -- ex.:

ispeed [i2c_bus_speed_in_hz]


Without a argument 'ispeed' gets back the current setting.

With an argument 'ispeed' converts the given string to ulong and setup the 
new speed. The argument can be a decimal integer, because simple_strtoul() 
from lib_generic/vsprintf.c understands base option 10.

> I would also set an environment variable in ispeed command indicating
> current i2c speed ("i2cspeed") so it could be used in scripts.

Is it really needed ... I don't think so. You can read back the current 
setting with 'ispeed' and save the result into a environment variable of 
your choice. So you can use it again in another or the same script.


Best Regards,
Stephan Linz

[U-Boot-Users] Proposal to add "ispeed" (I2C speed) command

[listmember at orkun.us]

> Makes sense, but why do you need measuring datas in context of a
> bootloader ?

Well, it is not meant to be full time use. Sort of quick diagnostics and
to do some random device/register access by a technician or to check the
configuration, upload new config etc..

> Hm, I think you should expand the command syntax -- ex.:
>
> ispeed [i2c_bus_speed_in_hz]
>
>
> Without a argument 'ispeed' gets back the current setting.

Good idea.

>> I would also set an environment variable in ispeed command indicating
>> current i2c speed ("i2cspeed") so it could be used in scripts.
>
> Is it really needed ... I don't think so. You can read back the current
> setting with 'ispeed' and save the result into a environment variable of
> your choice. So you can use it again in another or the same script.

This is probably not needed if the output can be saved in a variable in
u-boot. Can you do so using standard u-boot scripting instead of hush?

I am not going to insist much on this. It seemed to be a good idea and we
certainly have a case to use it here (folks here are developing an ASIC
with I2C interface). It might be useful for some people to have the
convenience to switch the i2c speed but I also recognized it might not be
useful for everyone so I proposed to make it conditional.

Best regards,
Tolunay

[U-Boot-Users] Proposal to add "ispeed" (I2C speed) command

[Wolfgang Denk]

In message <20504.216.110.51.8.1078415909.squirrel@www.orkun.us> you wrote:
> > Makes sense, but why do you need measuring datas in context of a
> > bootloader ?
> 
> Well, it is not meant to be full time use. Sort of quick diagnostics and
> to do some random device/register access by a technician or to check the
> configuration, upload new config etc..

Such code should not go into the normal distribution, then. Just wrte
a small standalone application for your hardware tests  -  there  you
can do whatever you want to do.

> This is probably not needed if the output can be saved in a variable in
> u-boot. Can you do so using standard u-boot scripting instead of hush?

No, you cannot. There is no eval command in U-Boot version of hush.

> convenience to switch the i2c speed but I also recognized it might not be
> useful for everyone so I proposed to make it conditional.

IMHO it's not even useful if made conditional. I consider  it  either
risky  (if  you  try to increase the I2C speed above the speed of the
slowest device on the bus) or useless (if you  slow  down  the  speed
without need).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
You can observe a lot just by watching.                  - Yogi Berra

[U-Boot-Users] Proposal to add "ispeed" (I2C speed) command

[Wolfgang Denk]

In message <11176.216.110.51.8.1078335375.squirrel@www.orkun.us> you wrote:
> We have some instrumentation hanging on I2C bus. I would like to introduce
> a new u-boot command ispeed to set the i2c speed so fast devices would not
> be constrained to the lowest denominator speed.

I don't understand why such a command might be needed.

Just configure the I2C clock for the maximum  allowable  speed  right
from the beginning.

> I would also set an environment variable in ispeed command indicating
> current i2c speed ("i2cspeed") so it could be used in scripts.

What is that good for? Why would you need to change speed?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
If a train station is a place where a train stops,
                                           then what's a workstation?

[U-Boot-Users] Proposal to add "ispeed" (I2C speed) command

[Stephan Linz]

Am Donnerstag,  4. M?rz 2004 10:11 schrieb Wolfgang Denk:
> What is that good for? Why would you need to change speed?

This 'could' be usefull to speed up the i2c communication if there are more 
than one i2c devices with significant differences between the clock timing; 
ex. 27C32 (100kHz at 3.3V) and LM75 (400kHz). Tolunay has spoken about like 
this. But right I see now reason to do so, too. U-Boot has to be a boot 
loader not a performant operator...


Best Regards,
Stephan Linz

[U-Boot-Users] Proposal to add "ispeed" (I2C speed) command

[Wolfgang Denk]

In message <04030413332001.12732@pcj86> you wrote:
> 
> This 'could' be usefull to speed up the i2c communication if there are more 
> than one i2c devices with significant differences between the clock timing; 
> ex. 27C32 (100kHz at 3.3V) and LM75 (400kHz). Tolunay has spoken about like 
> this. But right I see now reason to do so, too. U-Boot has to be a boot 
> loader not a performant operator...

Do you think it is legal to clock the I2C bus at 400 kHz  when  there
are  devices  on  the bus that are spec'ed only for 100 kHz? I may be
wrong, but such an idea sounds awfully risky to me.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"An open mind has but one disadvantage: it collects dirt."
                                                    - a saying at RPI

[U-Boot-Users] Proposal to add "ispeed" (I2C speed) command

[Stephan Linz]

Am Donnerstag,  4. M?rz 2004 14:21 schrieb Wolfgang Denk:
> In message <04030413332001.12732@pcj86> you wrote:
> > This 'could' be usefull to speed up the i2c communication if there are
> > more than one i2c devices with significant differences between the clock
> > timing; ex. 27C32 (100kHz at 3.3V) and LM75 (400kHz). Tolunay has spoken
> > about like this. But right I see now reason to do so, too. U-Boot has to
                             ^^^^^^^^^
OOPS, this was a small but fine typing error, should be:

" ... But right I see _NO_ reason to do so, too. ... "


(that's life)

> > be a boot loader not a performant operator...
>
> Do you think it is legal to clock the I2C bus at 400 kHz  when  there
> are  devices  on  the bus that are spec'ed only for 100 kHz? I may be
> wrong, but such an idea sounds awfully risky to me.

You're right, see above :-)


Best Regards,
Stephan Linz

[U-Boot-Users] Proposal to add "ispeed" (I2C speed) command

[listmember at orkun.us]

> Just configure the I2C clock for the maximum  allowable  speed  right
> from the beginning.

You can have 100khz and 400khz capable devices accessible to the master.
You can run everything at 100khz but you will not be taking full
advantange of 400khz devices.

Philips AN10216-01 (I2C Manual) Dated March 24, 2003, Page 24 describes
how a system can run both 100kHz devices and 400kHz devices on the same
bus and access 400kHz devices at 400kHz using I2C bus repeater such as
PCA9515.

I understand this might not be useful for everyone so that is why I
proposed to make it an optional command that is compiled in only if
CONFIG_I2C_ISPEED is defined.

Best regards,
Tolunay

[U-Boot-Users] Proposal to add "ispeed" (I2C speed) command

[Wolfgang Denk]

In message <20641.216.110.51.8.1078416617.squirrel@www.orkun.us> you wrote:
> > Just configure the I2C clock for the maximum  allowable  speed  right
> > from the beginning.
> 
> You can have 100khz and 400khz capable devices accessible to the master.
> You can run everything at 100khz but you will not be taking full
> advantange of 400khz devices.

Rigth. But on such a system you cannot run the bus at 400 kHz as this
would be out of spec for the 100 kHz devices.

> Philips AN10216-01 (I2C Manual) Dated March 24, 2003, Page 24 describes
> how a system can run both 100kHz devices and 400kHz devices on the same
> bus and access 400kHz devices at 400kHz using I2C bus repeater such as
> PCA9515.
> 
> I understand this might not be useful for everyone so that is why I
> proposed to make it an optional command that is compiled in only if
> CONFIG_I2C_ISPEED is defined.

I don't think this is useful.

What exactly are you trying to do that the speed makes any difference
for you? Remember, this is a boot loader, not an operating system.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Conquest is easy. Control is not.
	-- Kirk, "Mirror, Mirror", stardate unknown