On 11/11/2015 01:29 PM, Mirza Krak wrote: >> Can you put a scope on the interrupt pin and see if it's a problem of >> the SoC and/or Linux or the SJA1000 not pulling the IRQ line. > > A little demonstration on what it looks like when the system is > resumed (added a printk in sja1000_start without my patch, though my > printk also clears IR register): > > root@mx4-vcc:/opt/hm# ip -det link show can0 > 33: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state > UNKNOWN mode DEFAULT qlen 10 > link/can > can state ERROR-ACTIVE (berr-counter tx 0 rx 128) restart-ms 0 > bitrate 500000 sample-point 0.875 > tq 250 prop-seg 3 phase-seg1 3 phase-seg2 1 sjw 1 > sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1 > clock 12000000 > root@mx4-vcc:/opt/hm# ifconfig can0 down > root@mx4-vcc:/opt/hm# ifconfig can0 up > [ 1612.621187] sja1000: MOD: 0x1 > [ 1612.640992] sja1000: SR: 0x7c > [ 1612.660039] sja1000: IR: 0x24 > > Also did a measurement with the scope, it is the SJA1000 chip not > pulling the IRQ line. > > I can actually send one frame when the controller is in this state but > never get a TI interrupt.
Thanks for testing. [...] >>> Yes, resume code should be implemented to handle this and other >>> problems (receive data). But still a DOWN/UP procedure should clear >>> any previous state that could exist in the controller registers. >> >> I'll add your patch to can/master and add stable on Cc. Looking forward >> for some suspend/resume code :) > > Looking forward to writing suspend/resume code :). > > Some cred should go to Christian (added him to CC) for finding this > problem and reporting it to me. I'll add a Reported-by: Christian Magnusson <christian.magnus...@semcon.com> to the patch. 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 |
signature.asc
Description: OpenPGP digital signature