Hi Venkat,
If you disable the "mrst" earlyprintk, then there is no conflict.
As I said in last email, if you still randomly see it, it's fine. The basic
idea for the busy wait (code is listed here) is simple, after write/read the
FIFO wait till the HW register tell us it's not busy
static void wait_till_not_busy(struct dw_spi *dws)
{
unsigned long end = jiffies + 1 + usecs_to_jiffies(5000);
while (time_before(jiffies, end)) {
if (!(dw_readw(dws, sr) & SR_BUSY))
return;
cpu_relax();
}
dev_err(&dws->master->dev,
"DW SPI: Status keeps busy for 5000us after a read/write!\n");
}
5000 us should be enough for dumping the DW spi controller's FIFO (which is 40
words deep) even for a low speed UART slave device at 115200 bps.
If you still see lots of that message, can you enlarge that 5000 to 100000 to
check if it's gone?
Thanks,
Feng
> -----Original Message-----
> From: Jayaraman, Venkat
> Sent: Friday, February 25, 2011 2:46 PM
> To: Tang, Feng; [email protected]; [email protected]
> Subject: RE: [Meego-kernel] Question on Designware SPI Controller Driver
>
> Feng,
> No, the messages do not appear endlessly, but do come up quite a bit
> during
> bootup. If mrst earlyprintk console is disabled, what could be causing these
> series of messages? What are the entities that could be causing the conflict?
>
> Thanks
> Venkat
>
> -----Original Message-----
> From: Tang, Feng
> Sent: Sunday, February 20, 2011 5:26 PM
> To: Jayaraman, Venkat; [email protected]; [email protected]
> Subject: RE: [Meego-kernel] Question on Designware SPI Controller Driver
>
> Venkat,
>
> Were you seeing endless printing of that message? On Moorestown or Medfield?
>
> Last time, Yakui Zhao told me he saw endless printing of the this message on
> his MRST CDK, and removing the "earlyprintk=mrst" solved his problem.
>
> If you randomly see that message, it's ok, otherwise we don't need that
> warning
> at all.
>
> Btw, the DW SPI controller supports 3 working modes: PIO, DMA and interrupt
> driven,
> current max3110 use the PIO mode, which will check status register after every
> IO read/write. Migrating to interrupt mode will save you from seeing that
> message,
> but due to the poor interrupt latency from MRST non-OS side, I don't really
> recommend that.
>
> - Feng
>
> > -----Original Message-----
> > From: Jayaraman, Venkat
> > Sent: Saturday, February 19, 2011 8:49 AM
> > To: Tang, Feng; [email protected]; [email protected]
> > Subject: RE: [Meego-kernel] Question on Designware SPI Controller Driver
> >
> > Feng,
> > I see the message even if I remove "earlyprintk=mrst" from the cmdline.
> > Why could this be happening? Do I have to disable MRST_EARLY_PRINT from the
> > config?
> >
> > Venkat
> >
> > -----Original Message-----
> > From: Tang, Feng
> > Sent: Friday, February 18, 2011 1:37 AM
> > To: [email protected]; Jayaraman, Venkat; [email protected]
> > Subject: RE: [Meego-kernel] Question on Designware SPI Controller Driver
> >
> > Yes, it should affect all other devices connecting to the SPI0 controller,
> when
> > early console is printing sth out while the controller is accessed by other
> > devices through spi core, the early console will be disabled after the
> > ttyS0
> > gets the control
> >
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]]
> > > Sent: Friday, February 18, 2011 5:15 PM
> > > To: Tang, Feng; Jayaraman, Venkat; [email protected]
> > > Subject: RE: [Meego-kernel] Question on Designware SPI Controller Driver
> > >
> > > Hello,
> > >
> > > This problem also confuse me long time ago.
> > > I change module_init(serial_m3110_init) to be
> > > late_initcall(serial_m3110_init) to avoid this problem.
> > >
> > > May I ask that if the root cause is conflict between the MRST earlyprintk
> > console
> > > and the real spi max3110 console, is there possible also conflict other
> SPI
> > > device?
> > >
> > > Thank you.
> > >
> > > Sincerely,
> > > Major Lee
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email protected]
> > > > [mailto:[email protected]] On Behalf Of Tang, Feng
> > > > Sent: Friday, February 18, 2011 4:24 PM
> > > > To: Jayaraman, Venkat; [email protected]
> > > > Subject: Re: [Meego-kernel] Question on Designware SPI
> > > > Controller Driver
> > > >
> > > > Hi Venkat,
> > > >
> > > > I've heard several reports about the annoying message.
> > > >
> > > > The reason for it should be the conflict between the MRST
> > > > earlyprintk console (earlyprintk=mrst in cmdline) and the
> > > > real spi max3110 console aka ttyS0, and actually the 2
> > > > consoles use the same hardware.
> > > >
> > > > I developed that early console mainly for MRST/MDF power
> > > > on use, which is to debug the early kernel boot by hacky
> > > > direct operating the DW SPI0 controller, long before the
> > > > spi driver subsystem get inited which I developed for the
> > > > MRST power on So when the spi subsystem is up, there is
> > > > conflict between them, other spi devices connected to
> > > > SPI0 including max3110 itself will access the SPI0 controller
> > > > by apis from spi core, while the earlyprintk still directly
> > > > access controller, so likely the message will be triggered out.
> > > >
> > > > And in current phase, the earlyprintk should be disabled for
> > > > normal stable kernels, and I suggest to remove the
> > > > "earlyprintk=mrst" from cmdline for Meego kernel. Another way
> > > > is to downgrade the error message to a dev_dbg().
> > > >
> > > > Thanks,
> > > > Feng
> > > > ________________________________________
> > > > From: [email protected]
> > > > [mailto:[email protected]] On Behalf Of
> > > > Jayaraman, Venkat
> > > > Sent: Friday, February 18, 2011 3:03 PM
> > > > To: [email protected]
> > > > Subject: [Meego-kernel] Question on Designware SPI Controller Driver
> > > >
> > > > Hi,
> > > > I consistently see the following message
> > > > being printed from the Designware SPI controller driver
> > > > (dw_spi.c) during the booting phase on Medfield platform.
> > > >
> > > > "Status keeps busy for 5000us after a read/write"
> > > >
> > > > Seems like a "write" inside the interrupt
> > > > handler is causing this. Any idea why this happens?
> > > >
> > > > Thanks
> > > > Venkat
> > > > _______________________________________________
> > > > MeeGo-kernel mailing list
> > > > [email protected]
> > > > http://lists.meego.com/listinfo/meego-kernel
> > > >
_______________________________________________
MeeGo-kernel mailing list
[email protected]
http://lists.meego.com/listinfo/meego-kernel
