All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-kernel@vger.kernel.org, Vinod Koul <vinod.koul@intel.com>,
	linux-sh@vger.kernel.org, linux-pm@vger.kernel.org,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH 1/2] dma: shdma: fix runtime PM: clear channel buffers on reset
Date: Wed, 28 Mar 2012 05:25:04 +0000	[thread overview]
Message-ID: <20120328052503.GP26543@linux-sh.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1201041532290.30506@axis700.grange>

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?

WARNING: multiple messages have this Message-ID (diff)
From: Paul Mundt <lethal@linux-sh.org>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-kernel@vger.kernel.org, Vinod Koul <vinod.koul@intel.com>,
	linux-sh@vger.kernel.org, linux-pm@vger.kernel.org,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH 1/2] dma: shdma: fix runtime PM: clear channel buffers on reset
Date: Wed, 28 Mar 2012 14:25:04 +0900	[thread overview]
Message-ID: <20120328052503.GP26543@linux-sh.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1201041532290.30506@axis700.grange>

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?

  reply	other threads:[~2012-03-28  5:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-04 14:34 [PATCH 0/2] dma: shdma: clear buffers on reset Guennadi Liakhovetski
2012-01-04 14:34 ` Guennadi Liakhovetski
2012-01-04 14:34 ` [PATCH 1/2] dma: shdma: fix runtime PM: clear channel buffers on Guennadi Liakhovetski
2012-01-04 14:34   ` [PATCH 1/2] dma: shdma: fix runtime PM: clear channel buffers on reset Guennadi Liakhovetski
2012-03-28  5:25   ` Paul Mundt [this message]
2012-03-28  5:25     ` Paul Mundt
2012-03-28  7:02     ` Guennadi Liakhovetski
2012-03-28  7:02       ` Guennadi Liakhovetski
2012-01-04 14:34 ` [PATCH 2/2] ARM: mach-shmobile: specify CHCLR registers on SH7372 Guennadi Liakhovetski
2012-01-04 14:34   ` Guennadi Liakhovetski
2012-01-06  6:11 ` [PATCH 0/2] dma: shdma: clear buffers on reset Vinod Koul
2012-01-06  6:23   ` Vinod Koul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120328052503.GP26543@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=rjw@sisk.pl \
    --cc=vinod.koul@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.