Messages in this thread | | | Date | Wed, 9 Mar 2022 10:11:29 +0100 | From | 'Horatiu Vultur' <> | Subject | Re: [PATCH net-next] net: lan966x: Improve the CPU TX bitrate. |
| |
The 03/08/2022 22:46, David Laight wrote: > > From: Horatiu Vultur > > Sent: 08 March 2022 22:30 > > > > The 03/08/2022 22:36, Andrew Lunn wrote: > > > > > > > static int lan966x_port_inj_ready(struct lan966x *lan966x, u8 grp) > > > > { > > > > - u32 val; > > > > + unsigned long time = jiffies + usecs_to_jiffies(READL_TIMEOUT_US); > > > > + int ret = 0; > > > > > > > > - return readx_poll_timeout_atomic(lan966x_port_inj_status, lan966x, val, > > > > - QS_INJ_STATUS_FIFO_RDY_GET(val) & BIT(grp), > > > > - READL_SLEEP_US, READL_TIMEOUT_US); > > > > + while (!(lan_rd(lan966x, QS_INJ_STATUS) & > > > > + QS_INJ_STATUS_FIFO_RDY_SET(BIT(grp)))) { > > > > + if (time_after(jiffies, time)) { > > > > + ret = -ETIMEDOUT; > > > > + break; > > > > + } > > > > > > Did you try setting READL_SLEEP_US to 0? readx_poll_timeout_atomic() > > > explicitly supports that. > > > > I have tried but it didn't improve. It was the same as before. > > How many times round the loop is it going ?
In the tests that I have done, I have never seen entering in the loop.
> > It might be that by the time readx_poll_timeout_atomic() > gets around to reading the register the fifo is actually ready. > > The there is the delay between detecting 'ready' and writing > the next data. > That delay might be cumulative and affect performance.
There is also a small delay between writting the word and checking if more words can be written.
> > OTOH spinning waiting for fifo space is just plain horrid.
Yes, I agree with you.
> Reminds me of 3C509 drivers :-)
> > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales)
-- /Horatiu
| |