Re: peak_pci: TX Frame Loss

[Stephane Grosjean <s.grosjean@peak-system.com>]

Hi Andri,

So, you mean that, for example, the below sequence (extract from _xmit()):

                 priv->write_reg(priv, SJA1000_FI, fi);
                 priv->write_reg(priv, SJA1000_ID1, (id & 0x000007f8) >> 3);
                 priv->write_reg(priv, SJA1000_ID2, (id & 0x00000007) << 5);
                 ...
                 (1)
                 ...
                 sja1000_write_cmdreg(priv, CMD_TR);

can't be interrupted at all (especially at (1)), by any IRQ which ISR 
could write (again) some new ID?
I mean, shouldn't the SJA1000 and the sequence order of the cmds be 
considered as shared resource?

Regards,

Stéphane

Le 08/12/2015 11:50, Andri Yngvason a écrit :
> Hi Stephane,
>
> On Tue, Dec 08, 2015 at 11:21:26AM +0100, Stephane Grosjean wrote:
>> Hi!
>>
>> Don't know atm what is buggier, but:
>>
>> - the issue isn't reproducible with our Windows drivers,
>> - the issue isn't reproducible with the pcan driver,
> You have spin locks sprinkled around the pcan driver even where there isn't a
> specific shared resource that's being protected.
>
> However, a nice side-effect of that is that the interrupt routine is not allowed
> to run concurrently with the xmit function, so the command register is never
> written to so frequently as in the linux-can driver.
> [...]
>> FYI, I have surrounded the _xmit() function as well as the ISR with couples
>> of spin_lock/spin_unlock instructions, rebuild everything and have ran
>> Andri's testbed... and guess what?
> I don't know. I'm not sure if you hinted at the answer to this question. Did the
> problem go away? I guess it did due to the reasons that I mentioned above.
>
> This does not strike at the core of the issue. A targeted solution is to add a
> delay.
> [...]
>> Le 03/12/2015 12:44, Marc Kleine-Budde a écrit :
>>> On 12/03/2015 12:23 PM, Andri Yngvason wrote:
>>>> I tried it and it's not enough. The sja1000 on the peak pci is an FPGA
>>>> implementation that claims to be sja1000 compatible. Is it possible that peak's
>>>> FPGA implementation is slower than the original sja1000?
>>> Maybe buggier :)
>>>
>>> Marc
>>>
> Regards,
> Andri

--
PEAK-System Technik GmbH
Sitz der Gesellschaft Darmstadt
Handelsregister Darmstadt HRB 9183 
Geschaeftsfuehrung: Alexander Gach, Uwe Wilhelm
--