On Wed, Feb 10, 2016 at 04:30:03PM +0100, Rafał Miłecki wrote: > On 10 February 2016 at 14:15, Mark Brown <broonie@xxxxxxxxxx> wrote: > > Don't busy wait in the driver, ideally implement DMA support. Add some > > sleeps if you really need to. A PIO driver really isn't fit for purpose > > with large transfers like you get on flash. > The only place with busy waiting seems to be bcm53xxspi_wait. I tried > adding cpu_relax() before udelay(5) as well as cpu_relax() at the > beginning of this function. I didn't chage anything. Should I raher > use some timer & sleeping/waking mechanism? Yes, you'd need to either add some actual sleeps (probably a brief one after every transfer) or work with the maintainers of the lockup detector to come up with some other way that the thread can tell the detector that it really intends to burn huge amounts of CPU time in kernel. > I'm afraid there isn't a real DMA available. It seems Broadcom uses > something called "Boot SPI". Enabling this mode maps flash content > into a memory, but it may be a bit complex to implement. It would > require flash driver to have better control over SPI controller and > I'm not aware of any existing API for that. Read support has actually just been implemented (it ends up just being a callback with a MTD specific accessor), write support could also be added along similar lines I guess. See spi_flash_read() in -next.
Attachment:
signature.asc
Description: PGP signature
