Messages in this thread | | | Date | Wed, 28 Mar 2012 09:02:38 +0200 (CEST) | From | Guennadi Liakhovetski <> | Subject | Re: [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/
| |