Re: Bug in in spi-bcm53xx (rcu_sched) exposed by 0461a41 ("spi: Pump transfers inside calling context for spi_sync()")

[Rafał Miłecki <zajec5@xxxxxxxxx>]

On 10 February 2016 at 14:15, Mark Brown <broonie@xxxxxxxxxx> wrote:
> On Wed, Feb 10, 2016 at 02:04:21PM +0100, Rafał Miłecki wrote:
>> On 10 February 2016 at 13:48, Mark Brown <broonie@xxxxxxxxxx> wrote:
>
>> > It's most likely just hammering the CPU for a very long time without
>> > scheduling due to doing a long PIO transfers.  That change just removes
>> > some needless context switching.
>
>> The fact is it happens only after flashing firmware, when flash is
>> formatted for the first time. After flashing some changes from ramfs
>> are likely flushed to the falsh. I guess it matches your theory of
>> long time CPU hammering.
>
> I bet you can trigger it with a heavy read load too (especially lots of
> reads going on in parallel).  You'll have always been able to trigger
> it, it's just that this has made it easier.
>
>> Any idea how to handle this?
>
> 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?

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.

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html