lkml.org 
[lkml]   [2012]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] dma: shdma: fix runtime PM: clear channel buffers on reset
On Wed, 28 Mar 2012, Paul Mundt wrote:

> On Wed, Jan 04, 2012 at 03:34:17PM +0100, Guennadi Liakhovetski wrote:
> > On platforms, supporting power domains, if the domain, containing a DMAC
> > instance is powered down, the driver fails to resume correctly. On those
> > platforms DMAC channels have an additional CHCLR register for clearing
> > channel buffers. Using this register during runtime resume fixes the
> > problem.
> >
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>
> ..
>
> > @@ -139,6 +157,10 @@ static int sh_dmae_rst(struct sh_dmae_device *shdev)
> > dev_warn(shdev->common.dev, "Can't initialize DMAOR.\n");
> > return -EIO;
> > }
> > + if (shdev->pdata->dmaor_init & ~dmaor)
> > + dev_warn(shdev->common.dev,
> > + "DMAOR=0x%x hasn't latched the initial value 0x%x.\n",
> > + dmaor, shdev->pdata->dmaor_init);
> > return 0;
> > }
> >
> I've just hit this on SH7786, which I suspect means that I've got it
> wired up incorrectly somehow. This hunk also appears completely unrelated
> to the changelog, so I'm wondering what exactly it's for. If this is a
> probe attempt then presumably we should be handing down an error and
> -ENODEV'ing in the init path? Is it expected that this is non-fatal in
> the other reset cases?

The answer is "I don't know." I'm also seeing this in several cases, e.g.,
on sh7372 one of the two USB DMA controllers always triggers this, IIRC.
This failure does indeed seem to be non-fatal, and it has been simply
ignored in the past. I just hit it in my tests and decided it was worth
drawing attention to it to maybe actually find out what's going on there.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


\
 
 \ /
  Last update: 2012-03-28 09:05    [W:0.035 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site