> -----Original Message----- > From: Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> > Sent: 2019年11月11日 18:54 > To: Joakim Zhang <qiangqing.zhang@xxxxxxx>; sean@xxxxxxxxxx; > linux-can@xxxxxxxxxxxxxxx > Subject: Re: Wake up issue about Flexcan driver in v5.4 kernel > > On 11/11/19 11:36 AM, Joakim Zhang wrote: > >> - What did you do before wakeup? > >> - Clean reboot? > >> - ifdown/ifup? > > > > Clean boot > > Fine, so the chip should fill mailbox 0 first. > > > Sender side: > > ip link set can0 up type can bitrate 1000000 > > echo enabled > > /sys/bus/platform/drivers/flexcan/30a10000.caower/wakeup > > candump can0 & > > echo mem > /sys/power/state > > > > Receive side: > > ip link set can0 up type can bitrate 1000000 > > cangen can0 -vv > > > >> - sending other packets? > > No. > >> - Does this happen on every wakeup? > > Yes. > >> - Is the wake up frame always "received" as 6th frame? > > No, different with different frame gap. > > If the frame gap is unchanged, does the order change? No, it will not change. > >> - Is the situation the same, if you add some delay between the frames, > >> using the "cangen -g option"? > > The situation is different with different "cangen -g option" > >> - How big can you make the -g until the frames are received in order > >> again? > > I am not sure, I can do a test later. > > > >> The reception path works like this: > >> In the interrupt handler the rx-offload reads all mailboxes based on > >> the iflag register. It iterates over all set mailboxes, starting with > >> the first. All mailboxes are read including the rx-timestamp, sorted > >> and added into a queue. At the end of the IRQ handler the queue is > >> added to the per device queue thats read in the NAPI and pushed into the > networking stack. > >> > >> Maybe something with the timestamp of the first packet is wrong, as > >> the counter is only 16 bits wide, it will overflow quite often. > >> > >> Maybe you can trace_printk the mailbox number, timestamp and can_id > >> in > >> mailbox_read() and analyse output after wakeup. Feel free to post the > >> output of the tracer here. > > > > I also suspect this, but I check the flow of the receive path is the > > same with v4.14 and v4.19. > > > > Another thing confused me is that how does the driver handle the > > counter overflow. If the counter overflow in one round mailbox read, > > the receive order is not consistent with reality. I do not the handle > > of this case in driver. > > The overflow handling consists of two tricks: > > 1) Make the 16 bit timestamp a 32 bit one: > > https://elixir.bootlin.com/linux/latest/source/drivers/net/can/flexcan.c#L800 > > 2) Subtract two u32 timestamps and treat result as (singed) int. > > A u32 overflows at 2^32 = 4294967295 = 0xffffffff > 2^32 + 1 = 1 = 0x00000001 > > A s32 overflows 2147483647 to -2147483648 = > 0x7fffffff to 0x80000000. > > Let's assume one frame arrives at: > 0xfffffffe and the next one 0x00000002. > The difference from new to old is -4: > 0x00000002 - 0xfffffffe = 0xfffffffc > Interpreting 0xfffffffc as a signed value means -4. > > The trick basically moves the overflow from 0xffffffff to 0x7fffffff. > > > https://elixir.bootlin.com/linux/latest/source/drivers/net/can/rx-offload.c#L10 > 7 Thanks, I will learn it later. Best Regards, Joakim Zhang > > I will use the trace_printk() to post the output here. > > Marc > > -- > Pengutronix e.K. | Marc Kleine-Budde | > Embedded Linux | https://www.pengutronix.de | > Vertretung West/Dortmund | Phone: +49-231-2826-924 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
