Dear Timur,
In message 49483DD7.5080908@freescale.com you wrote:
I think it's a kludge because you have to set the current device before you can access it. It seems ridiculous that you have to do this:
i2c_set_bus_num(x) i2c_write(...)
when you could do this:
i2c_write(x, ...)
That's your argument. The other side's argument is that it's overhead (note that I do not use such a strong term as "ridiculous" as you did) to add a bus number argument to each and every board, where only a tiny fraction of them will ever have mnore than one I2C bus used.
So there is arguments bor both implementations, and it was decided to implement the first approach.
We've been trhough this before, it makes little sense that yous tir this up again.
Really? Where exactly does such a thing happen?
Well, I can't find a real example, but here's something close. Take a look at function pib_init() in mpc8568mds.c. This function needs to talk to the 2nd I2C bus. It has no idea who called it, so it has no idea what the current I2C bus is. Therefore, it has to save and restore it.
IUt has to set it, yes. But there is no need to restore it, because there are no nested I2C calls.
This situation could happen anywhere.
It could, if you intentionally create such a case. In real life, it never happens. Or can trivially be avoided.
It's not a bug. Function X does I2C operations, and function Y also does I2C operations, but on a different device. If function X calls function Y, then Y needs to save and restore the current bus number. You will never get rid of this requirement as long as you have the concept of a current I2C bus number.
There are no examples for such code. And I cannot see where it would be necessary.
So you're still going to need i2c_get_bus_num() and i2c_set_bus_num(), and you're still going to have code like this:
bus = i2c_get_bus_num(); i2c_set_bus_num(x); i2c_write(...) i2c_set_bus_num(bus);
Nope. This is not necessary.
I repeat: there are no nested I2C calls.
That's full in line with the design philosophy that we are strictly single tasking. There are no multiple tasks using the same driver or bus.
In that case, I have no interest in working on this new I2C design. You guys obviously have everything under control, so good luck.
C'me on. Don't act like a prima donna.
Best regards,
Wolfgang Denk