This might help :)
https://github.com/mvduin/u-boot/commit/2c0dd27560f37d01a98f28122d5d7c576885...
Matthijs
Hi Matthijs,
Am 16.02.2017 um 04:43 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
This might help :)
https://github.com/mvduin/u-boot/commit/2c0dd27560f37d01a98f28122d5d7c576885... https://github.com/mvduin/u-boot/commit/2c0dd27560f37d01a98f28122d5d7c5768858bfa
I have looked in the patch - but I am not sure if I understand it completely.
tca642x_reg_write():
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=drivers/gpio/tca642x.c;...
hence, old code does: write ((read() & ~ 0xff ) | configuration_reg) = write (configuration_reg)
new code does: write ((read() & ~ 0 ) | configuration_reg) = write (read() | configuration_reg) write (configuration_reg)
So you leave the existing inputs as inputs while changing the other settings and only make them outputs *after* this sequence. Pins already configured as output are left as they are. And new inputs are set up before changing anything.
Ok, this avoids glitches while switching the output polarity and value.
Is this interpretation right?
BTW: line 161 seems to be redundant.
And while I look at it, we could suggest to optimize out the i2c_read() if mask = 0xff in tca642x_reg_write()...
BR and thanks, Nikolaus
On 16 February 2017 at 07:48, H. Nikolaus Schaller hns@goldelico.com wrote:
So you leave the existing inputs as inputs while changing the other settings and only make them outputs *after* this sequence.
Yes, I make sure that if pins are requested to be inputs that they do high-Z before the output data register is written, and more importantly if pins are requested to be outputs I do this only after the output data register has been written.
Previously all pins configured as "output low" would transition as "high-Z -> output high -> output low" during init, which of course is asking for trouble.
And while I look at it, we could suggest to optimize out the i2c_read() if mask = 0xff in tca642x_reg_write()...
The whole code is really weird, I just decided to touch it as little as possible. He creates wrappers but doesn't use them during init. Pointlessly reads when all you want to do is write. Performs i2c transactions per byte even though you can do all three bytes at once (hence expose them effectively just as 24-bit registers).
Not award-winning code...
Matthijs
Am 16.02.2017 um 08:06 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 16 February 2017 at 07:48, H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> wrote: So you leave the existing inputs as inputs while changing the other settings and only make them outputs *after* this sequence.
Yes, I make sure that if pins are requested to be inputs that they do high-Z before the output data register is written, and more importantly if pins are requested to be outputs I do this only after the output data register has been written.
Previously all pins configured as "output low" would transition as "high-Z -> output high -> output low" during init, which of course is asking for trouble.
Maybe, could you update the commit message to additionally describe this?
I am not sure if we really have a problem with this, but I will merge it into our tree to be on the safe side.
Do you plan to upstream it?
If yes, could you please take care of these patches as well: * http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=044d6e6962e1293e35d59... http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=044d6e6962e1293e35d599cfefb282ed8f510fe4 * http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=f9fdd2df5f9610dca7c42... http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=f9fdd2df5f9610dca7c42062d037c7ffe3d06844 * http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=fcf94fa0fa89b658ab250... http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=fcf94fa0fa89b658ab250888ac8016fd65d4b839 * http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=7d44a68fa8b91a0d2473744d255e3dd9f130b87e http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=7d44a68fa8b91a0d24737... http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=7d44a68fa8b91a0d2473744d255e3dd9f130b87e
They are all related to core u-boot components like your patch (one is not pyra related but am335x).
I ask for help because I don't find time to follow another mailing list and provide/discuss patches there.
And while I look at it, we could suggest to optimize out the i2c_read() if mask = 0xff in tca642x_reg_write()...
The whole code is really weird, I just decided to touch it as little as possible.
Wise decision!
He creates wrappers but doesn't use them during init. Pointlessly reads when all you want to do is write. Performs i2c transactions per byte even though you can do all three bytes at once (hence expose them effectively just as 24-bit registers).
Not award-winning code...
Certainly not... Probably it would be winner for quick&dirty :)
Anyways such optimizations would reduce boot time by less than approx. 250µs. I wouldn't notice a difference :)
BR, Nikolaus
-
H. Nikolaus Schaller -
Matthijs van Duin