On Mon, 2015-03-16 at 22:18 +0530, Vinod Koul wrote:
> On Tue, Mar 10, 2015 at 12:25:07PM +0200, Andy Shevchenko wrote:
> > In some cases we might have DMA powered off and therefore get 0xffffffff from
> > the register. This patch introduces a counter to prevent a hang.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> > ---
> > drivers/dma/dw/core.c | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> > index a8ad052..3f514d6 100644
> > --- a/drivers/dma/dw/core.c
> > +++ b/drivers/dma/dw/core.c
> > @@ -191,8 +191,10 @@ static inline void dwc_dump_chan_regs(struct dw_dma_chan *dwc)
> >
> > static inline void dwc_chan_disable(struct dw_dma *dw, struct dw_dma_chan *dwc)
> > {
> > + unsigned int count = 20;
> > +
> > channel_clear_bit(dw, CH_EN, dwc->mask);
> > - while (dma_readl(dw, CH_EN) & dwc->mask)
> > + while (dma_readl(dw, CH_EN) & dwc->mask && count--)
> you have a write instructions before this, so how is that write is not
> impacted and read is.
The write rather can be impacted, but we can't know this for sure (needs
some probe on the interconnect / IOSF to see that).
> Why would DMA be powered off?
In our case DMA is a private IP to the host controllers (SPI, for
example), So, the power rail is shared for SPI and DMA. SPI uses runtime
PM and can be switched off.
The actual issue we have is happened at dw_dma_off(). I decided to add
an extra to dwc_chan_disable().
Give another thought I'm okay to fix just dw_dma_off() case.
--
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
