[PATCH linux dev-4.7 v2] drivers/fsi: Add delay before sampling input on SDA

Christopher Bostic cbostic at linux.vnet.ibm.com
Tue Mar 21 00:49:41 AEDT 2017

On 3/20/17 12:33 AM, Jeremy Kerr wrote:
> Hi Chris,
>> During high cpu loads the SDA in line can shift relative to the
>> clock signal which can corrupt the received input data.  Slow
>> down the time to sample input to account for this.
> This looks much better than the previous patch, but do you know why high
> CPU loads affect this? All of the GPIO interactions are performed with
> the single spinlock held, so CPU load should have no bearing on the
> timing of the bit-banging - the driver has exclusive use of the CPU
> during a FSI transaction.
> Can you elaborate on the symptoms of this?
Hi Jeremy,

Yes that's true, cpu load shouldn't be a factor in this case then. The 
failure mode is during the sampling of input data during the slave 
response phase of the command.  CRC received does not match the CRC 
calculated due to bit flips
related to sampling/clocking timing issues.  This problem only appears 
when hostboot is accessing the BMC.  Increasing delay does correct the 
issue.  I don't have a good explanation for why this timing behavior 
occurs given its not cpu load related.
> One thing that looks a little suspicious to me is that you're running
> the clock during the echo delay time, so you're potentially feeding
> random data to the slave...
> Cheers,
The echo delay in the driver clocks '1's on the line so as long as the 
echo_delay() utility is used there is no risk of random data in this 
phase.   Clocking during this phase also gives the slave more clocks to 
process the newly sent command so the entire time for processing a 
single command and generating a response takes less follow on clocks.

> Jeremy

More information about the openbmc mailing list