This is the mail archive of the
mailing list for the eCos project.
[Bug 1001397] I2C driver for Kinetic microcontrollers
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-bugs at ecos dot sourceware dot org
- Date: Wed, 26 Dec 2012 15:06:03 +0000
- Subject: [Bug 1001397] I2C driver for Kinetic microcontrollers
- Auto-submitted: auto-generated
- References: <email@example.com/>
Please do not reply to this email. Use the web interface provided at:
--- Comment #32 from Ilija Kocho <firstname.lastname@example.org> 2012-12-26 15:05:59 GMT ---
(In reply to comment #31)
> I think that looping on bus ready is probably ok if there is a SMBus like
> timeout of 25ms to 30ms, and as long as the scheduler can break in switch
> tasks. If the wait can't be interrupted by the scheduler it is more problematic
> when the bus is stuck.
I2C thread normally shall be pre-empted by threads with higher priority than
itself. With current code this implies that I2C thread has to run with
relatively low priority. Probably it would be better if the priority is
(dynamically) decreased during spinning.
> A worst case scenario might have a task for ALERTB and one for telemetry. The
> second master hogs the bus and the first master is having trouble getting in.
> The the ALERTB comes along and needs immediate service. The ALERTB task may
> flip a GPIO bit and kill power, or it may wait for the timeout and then attempt
> to use the bus.
> All that matters to me is that it the driver waits for the bus to be free,
> times out, and allows a higher priority task do its job while waiting. I would
> not want it to just return because the bus is busy and force me to write my own
> timeout. And I would not want it to hang forever if a second master was beating
> the bus to death.
Timeout may be useful in general and it can be added as well.
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.