On 11/22/2017 03:56 AM, ZHU Yi (ST-FIR/ENG1-Zhu) wrote:
>>> I'm afraid so far no known flexcan core supports it.
>>
>> Should we update the table and add a "IRQ Err Passive" no for all
>> cores?
> By look into the reference manual of MX25[1], MX35[2] and VF610[3],
> it turns out that none of them support the error passive interrupt.
> So we should update the "IRQ Err Passive" to no for all cores.

I'll create a patch.

> Interestingly, seems the new RM of MX25 (Rev.2) and MX35 (Rev.3)
> states that both core have the [TR]WRN_INT connected, so I guess the
> no in that column were added for the legacy core.

What do you mean by connected exactly?

As fas as I know these IP cores have these interrupts lines, but they
are not properly wired to the IRQ line that leaves the IP core. To quote
Shawn Guo from the discussion back in 2012:

>> From what I can tell, i.MX35, i.MX51 and i.MX53 use the same version,
>> so they should all have the bug.  And for i.MX6Q, since it uses a newer
>> version even than i.MX28, I would believe it's affected by the bug.
>> But I'm copying Dong who should have better knowledge about this to
>> confirm.

Further Dong Aisheng says:

>> Our IC owner double checked the MX35 and MX53 IP and found the
>> RX_WARN & TX_WARN Interrupt source actually are not connected to
>> ARM. That means flexcan will not trigger interrupt to ARM core even
>> RX_WARN or TX_WARN Happens. This may be the root cause that why you
>> cannot see RX_WARN interrupt if not enable bus error interrupt on
>> mx35. He also checked that mx6q has the rx/tx warning interrupt
>> connected to arm. So we guess mx6q does not have this issue. 
>> Anyway, we can test to confirm.

> However, as the driver also needs to work with the legacy core, and
> they share the same devtype_data as p1010, so I think we should leave
> it as it is.

>>>  * Below is some version info we got:
>>>  *    SOC   Version   IP-Version  Glitch- [TR]WRN_INT IRQ Err Memory err RTR re-
>>>  *                                Filter? connected?  Passive detection  ception in MB
>>>  *   MX25  FlexCAN2  03.00.00.00     no        no         ?       no        no
>>>  *   MX28  FlexCAN2  03.00.04.00    yes       yes        no       no        no
>>>  *   MX35  FlexCAN2  03.00.00.00     no        no         ?       no        no
>>>  *   MX53  FlexCAN2  03.00.00.00    yes        no        no       no        no
>>>  *   MX6s  FlexCAN3  10.00.12.00    yes       yes        no       no       yes
>>>  *   VF610 FlexCAN3  ?               no       yes         ?      yes       yes?
>>
>> And does it make sense to add "FLEXCAN_QUIRK_BROKEN_PERR_STATE" to the
>> vf610, too?

> I think vf610 will need this quirk to report correct state transitions.
> The reason last time we do not touch this is because neither Wolfgang
> nor I had access to vf610, so we can only test with MX28, MX53 and MX6.
> We thought someone will speak out if they meet problems with this core,
> and then they can help to fix and test it.

Cc'ed Stefan Agner - maybe he has access to this SoC.

> @Marc, @Wolfgang,
> What do you think? Or shall we fix first and then wait?

Let's wait if Stefan can test, otherwise just fix.

> @Pankaj, as you are currently working on patch this driver, is it
> possible that you can help to create patch for the table and/or the
> PERR_STATE quirk fix for vf610 in case required? Thanks!
Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |