[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.
Thanks,
Chris
>
> Jeremy
>
More information about the openbmc
mailing list