linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jon-hunter@ti.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion
Date: Mon, 11 Jun 2012 13:36:30 -0500	[thread overview]
Message-ID: <4FD63AAE.90008@ti.com> (raw)
In-Reply-To: <2d6f0fb31cde98cd700d7a4268683b4aeeee87f2.1339419244.git.afzal@ti.com>

Hi Afzal,

On 06/11/2012 09:01 AM, Afzal Mohammed wrote:
> Reorganize gpmc-onenand initialization so that changes
> required for gpmc driver migration can be made smooth.
> 
> Ensuring sync read/write are disabled in onenand cannot be
> expect to work properly unless GPMC is setup, this has been
> removed. 

So I think I see what you are saying, but the above is not 100% clear. I
think that what you are saying is that omap2_onenand_set_async_mode() is
attempting to configure the onenand registers before configuring the
gpmc interface and hence this is not correct.

> Two instances of doing the same has been clubbed
> into one as onenand driver always calls indirectly
> "omap2_onenand_set_sync_mode", and has placed such that
> configuring onenand for async read/write would happen once
> GPMC is setup for async mode (which happens even for sync
> mode, before configuring to sync mode).

It may be clearer to say that _set_sync_mode is always called during
onenand setup and this will call _set_async_mode. So instead of calling
_set_async_mode from _set_sync_mode, just call it directly during the
gpmc_onenand_init().

> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
>  arch/arm/mach-omap2/gpmc-onenand.c |   24 +++++++++---------------
>  1 file changed, 9 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
> index 71d7c07..fd4c48d 100644
> --- a/arch/arm/mach-omap2/gpmc-onenand.c
> +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> @@ -38,10 +38,9 @@ static struct platform_device gpmc_onenand_device = {
>  	.resource	= &gpmc_onenand_resource,
>  };
>  
> -static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
> +static int omap2_onenand_set_async_mode(int cs)
>  {
>  	struct gpmc_timings t;
> -	u32 reg;
>  	int err;
>  
>  	const int t_cer = 15;
> @@ -55,11 +54,6 @@ static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
>  	const int t_wpl = 40;
>  	const int t_wph = 30;
>  
> -	/* Ensure sync read and sync write are disabled */
> -	reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
> -	reg &= ~ONENAND_SYS_CFG1_SYNC_READ & ~ONENAND_SYS_CFG1_SYNC_WRITE;
> -	writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
> -
>  	memset(&t, 0, sizeof(t));
>  	t.sync_clk = 0;
>  	t.cs_on = 0;
> @@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
>  	if (err)
>  		return err;
>  
> -	/* Ensure sync read and sync write are disabled */
> -	reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
> -	reg &= ~ONENAND_SYS_CFG1_SYNC_READ & ~ONENAND_SYS_CFG1_SYNC_WRITE;
> -	writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);

I agree with getting rid of the first instance at the beginning of
_set_async_mode, but why get rid of the above one? Are you assuming that
by default it is in async mode? Could be nice to keep it to be explicit.

>  	return 0;
>  }
> @@ -191,19 +181,21 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
>  	u32 reg;
>  	bool clk_dep = false;
>  
> +	/* Ensure sync read and sync write are disabled */
> +	reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
> +	reg &= ~ONENAND_SYS_CFG1_SYNC_READ & ~ONENAND_SYS_CFG1_SYNC_WRITE;
> +	writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
> +

Should we only set these after we have checked the flags and depending
on which flags are set?

>  	if (cfg->flags & ONENAND_SYNC_READ) {
>  		sync_read = 1;
>  	} else if (cfg->flags & ONENAND_SYNC_READWRITE) {
>  		sync_read = 1;
>  		sync_write = 1;
>  	} else
> -		return omap2_onenand_set_async_mode(cs, onenand_base);
> +		return 0;
>  
>  	if (!freq) {
>  		/* Very first call freq is not known */
> -		err = omap2_onenand_set_async_mode(cs, onenand_base);
> -		if (err)
> -			return err;
>  		freq = omap2_onenand_get_freq(cfg, onenand_base, &clk_dep);
>  		first_time = 1;
>  	}
> @@ -421,6 +413,8 @@ void __init gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
>  	gpmc_onenand_resource.end = gpmc_onenand_resource.start +
>  							ONENAND_IO_SIZE - 1;
>  
> +	omap2_onenand_set_async_mode(gpmc_onenand_data->cs);
> +

What about putting this in the gpmc_onenand_setup() function before the
call to _set_sync_mode? Seems nice to have these together.

Cheers
Jon

  reply	other threads:[~2012-06-11 18:36 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-11 14:01 [PATCH 0/3] Prepare for GPMC driver conversion Afzal Mohammed
2012-06-11 14:01 ` [PATCH 1/3] ARM: OMAP2+: nand: unify init functions Afzal Mohammed
2012-06-11 15:43   ` Jon Hunter
2012-06-12  5:50     ` Mohammed, Afzal
2012-06-11 14:01 ` [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion Afzal Mohammed
2012-06-11 18:36   ` Jon Hunter [this message]
2012-06-12  6:16     ` Mohammed, Afzal
2012-06-12 17:30       ` Jon Hunter
2012-06-13  5:03         ` Mohammed, Afzal
2012-06-13 16:38           ` Jon Hunter
2012-06-14  5:40             ` Mohammed, Afzal
2012-06-14 17:53               ` Jon Hunter
2012-06-15  6:52                 ` Mohammed, Afzal
2012-06-11 14:02 ` [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings Afzal Mohammed
2012-06-11 18:49   ` Jon Hunter
2012-06-12  6:37     ` Mohammed, Afzal
2012-06-12 17:36       ` Jon Hunter
2012-06-13  4:56         ` Mohammed, Afzal
2012-06-13 11:32           ` Tony Lindgren
2012-06-13 11:54             ` Tony Lindgren
2012-06-13 11:58               ` Mohammed, Afzal
2012-06-14 10:10                 ` Mohammed, Afzal
2012-06-14 10:19                   ` Tony Lindgren
2012-06-14 10:39                     ` Mohammed, Afzal
2012-06-14 11:49                       ` Tony Lindgren
2012-06-14 11:59                         ` Mohammed, Afzal
2012-06-14 12:09                         ` Mohammed, Afzal
2012-06-14 12:21                           ` Mohammed, Afzal
2012-06-14 12:30                             ` Tony Lindgren
2012-06-14 11:52                       ` Tony Lindgren
2012-06-14 11:56                         ` Mohammed, Afzal
2012-06-14 12:29                           ` Tony Lindgren
2012-06-14 12:53                             ` Mohammed, Afzal
2012-06-14 16:53                               ` Tony Lindgren
2012-06-15  5:42                                 ` Mohammed, Afzal
2012-06-15  6:16                                   ` Mohammed, Afzal
2012-06-15 10:45                                     ` Tony Lindgren
2012-06-15 10:49                                       ` Mohammed, Afzal
2012-06-13 12:34             ` Mohammed, Afzal
2012-06-13 12:42               ` Tony Lindgren
2012-06-13 14:04                 ` Mohammed, Afzal
2012-06-14  6:32                   ` Tony Lindgren
2012-06-14  9:29   ` Tony Lindgren
2012-06-14  9:41     ` Mohammed, Afzal
2012-06-14 11:23       ` Tony Lindgren
2012-06-12 10:27 ` [PATCH 0/3] Prepare for GPMC driver conversion Mohammed, Afzal
2012-06-13 11:33   ` Tony Lindgren
2012-06-13 12:40     ` Mohammed, Afzal
2012-06-13 16:46       ` Jon Hunter
2012-06-14  5:58         ` Mohammed, Afzal

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=4FD63AAE.90008@ti.com \
    --to=jon-hunter@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).