Re: [PATCH] spi: atmel: Prevent false timeouts on long transfers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Mark,

broonie@xxxxxxxxxx wrote on Fri, 16 Jun 2023 18:43:51 +0100:

> On Fri, Jun 16, 2023 at 06:59:06PM +0200, Miquel Raynal wrote:
> > broonie@xxxxxxxxxx wrote on Fri, 16 Jun 2023 17:43:06 +0100:  
> > > On Fri, Jun 16, 2023 at 06:15:35PM +0200, Miquel Raynal wrote:  
> > > > broonie@xxxxxxxxxx wrote on Fri, 16 Jun 2023 15:20:27 +0100:    
> 
> > > Like I say we should know the transfer speed so we can do better than
> > > 4ms/10k - we know how long it takes to clock out each byte, we can just
> > > multiply that by the size of the transfer then add some fudge factor for
> > > setup/teardown overhead.  1s feels pretty generous too.  The sun6i
> > > driver for example does   
> 
> > >    max(tfr->len * 8 * 2 / (tfr->speed_hz / 1000), 100U)  
> 
> > > and just doubles the length based timeout with a minimum of 100ms which
> > > seems reasonable.  
> 
> > I already had issues with ~0.1s timeouts on NAND controllers, just
> > because the machine was heavily loaded. I believe we should avoid too
> > small timeouts, it does not make sense and make things worse under load.  
> 
> Well, we can raise that minimum if it's causing issues - 500ms say?  1s
> does feel a bit extreme for short transfers (and note that we'll use
> more than 100ms for long enough transfers).

Sounds reasonable. I believe it's worth the try.

Cheers,
Miquèl




[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux