From: Bertrik Sikken <bertrik_at_sikken.nl>
Date: Tue, 15 Jun 2010 23:51:57 +0200

On 15-6-2010 11:33, Rob Purchase wrote:
> On 15/06/2010 11:17, pouly amaury wrote:
>>
>> You convinced me that finally think that I should (or someone else !)
>> rewrite it in assembly to avoid any further problem. Any one against
>> that ?
>
> This version seems to work correctly:
>
> static inline void delay_loop(void)
> {
> asm volatile (" mov %[freq], %[freq], asr#22 \n\t"
> "1: subs %[freq], %[freq], #1 \n\t"
> " bne 1b"
> : : [freq] "r" (cpu_frequency) : "memory");
> }
>
> By "correctly" I mean:
>
> - it doesn't get optimized away using our default compiler flags
> - it seems to generate the same code with both GCC versions
> - the PMU driver works (with CPU boosted and unboosted)
> - the touchscreen driver does not "lose" about 10% of presses
> (this happens since r26850...)
>
> I've tested this with the EABI compiler and all seems well. Once I've
> committed it we can re-enable EABI for this target and we can all be
> happy again :)

I don't mean to say that you shouldn't apply this fix.

But, as far as I understand, this delay applies to an i2c driver and
generally i2c devices should be fairly tolerant to clock variations.
The fact that the correct functioning seems so sensitive to i2c
delays suggests to me that maybe something else is wrong.
For example, could there be a problem in the bit-banged i2c
implementation itself?

Kind regards,
Bertrik
Received on 2010-06-15