All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jon-hunter@ti.com>
To: Afzal Mohammed <afzal@ti.com>
Cc: tony@atomide.com, paul@pwsan.com, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [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

WARNING: multiple messages have this Message-ID (diff)
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: 100+ 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 ` Afzal Mohammed
2012-06-11 14:01 ` [PATCH 1/3] ARM: OMAP2+: nand: unify init functions Afzal Mohammed
2012-06-11 14:01   ` Afzal Mohammed
2012-06-11 15:43   ` Jon Hunter
2012-06-11 15:43     ` Jon Hunter
2012-06-12  5:50     ` Mohammed, Afzal
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 14:01   ` Afzal Mohammed
2012-06-11 18:36   ` Jon Hunter [this message]
2012-06-11 18:36     ` Jon Hunter
2012-06-12  6:16     ` Mohammed, Afzal
2012-06-12  6:16       ` Mohammed, Afzal
2012-06-12 17:30       ` Jon Hunter
2012-06-12 17:30         ` Jon Hunter
2012-06-13  5:03         ` Mohammed, Afzal
2012-06-13  5:03           ` Mohammed, Afzal
2012-06-13 16:38           ` Jon Hunter
2012-06-13 16:38             ` Jon Hunter
2012-06-14  5:40             ` Mohammed, Afzal
2012-06-14  5:40               ` Mohammed, Afzal
2012-06-14 17:53               ` Jon Hunter
2012-06-14 17:53                 ` Jon Hunter
2012-06-15  6:52                 ` Mohammed, Afzal
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 14:02   ` Afzal Mohammed
2012-06-11 18:49   ` Jon Hunter
2012-06-11 18:49     ` Jon Hunter
2012-06-12  6:37     ` Mohammed, Afzal
2012-06-12  6:37       ` Mohammed, Afzal
2012-06-12 17:36       ` Jon Hunter
2012-06-12 17:36         ` Jon Hunter
2012-06-13  4:56         ` Mohammed, Afzal
2012-06-13  4:56           ` Mohammed, Afzal
2012-06-13 11:32           ` Tony Lindgren
2012-06-13 11:32             ` Tony Lindgren
2012-06-13 11:54             ` Tony Lindgren
2012-06-13 11:54               ` Tony Lindgren
2012-06-13 11:58               ` Mohammed, Afzal
2012-06-13 11:58                 ` Mohammed, Afzal
2012-06-14 10:10                 ` Mohammed, Afzal
2012-06-14 10:10                   ` Mohammed, Afzal
2012-06-14 10:19                   ` Tony Lindgren
2012-06-14 10:19                     ` Tony Lindgren
2012-06-14 10:39                     ` Mohammed, Afzal
2012-06-14 10:39                       ` Mohammed, Afzal
2012-06-14 11:49                       ` Tony Lindgren
2012-06-14 11:49                         ` Tony Lindgren
2012-06-14 11:59                         ` Mohammed, Afzal
2012-06-14 11:59                           ` Mohammed, Afzal
2012-06-14 12:09                         ` Mohammed, Afzal
2012-06-14 12:09                           ` Mohammed, Afzal
2012-06-14 12:21                           ` Mohammed, Afzal
2012-06-14 12:21                             ` Mohammed, Afzal
2012-06-14 12:30                             ` Tony Lindgren
2012-06-14 12:30                               ` Tony Lindgren
2012-06-14 11:52                       ` Tony Lindgren
2012-06-14 11:52                         ` Tony Lindgren
2012-06-14 11:56                         ` Mohammed, Afzal
2012-06-14 11:56                           ` Mohammed, Afzal
2012-06-14 12:29                           ` Tony Lindgren
2012-06-14 12:29                             ` Tony Lindgren
2012-06-14 12:53                             ` Mohammed, Afzal
2012-06-14 12:53                               ` Mohammed, Afzal
2012-06-14 16:53                               ` Tony Lindgren
2012-06-14 16:53                                 ` Tony Lindgren
2012-06-15  5:42                                 ` Mohammed, Afzal
2012-06-15  5:42                                   ` Mohammed, Afzal
2012-06-15  6:16                                   ` Mohammed, Afzal
2012-06-15  6:16                                     ` Mohammed, Afzal
2012-06-15 10:45                                     ` Tony Lindgren
2012-06-15 10:45                                       ` Tony Lindgren
2012-06-15 10:49                                       ` Mohammed, Afzal
2012-06-15 10:49                                         ` Mohammed, Afzal
2012-06-13 12:34             ` Mohammed, Afzal
2012-06-13 12:34               ` Mohammed, Afzal
2012-06-13 12:42               ` Tony Lindgren
2012-06-13 12:42                 ` Tony Lindgren
2012-06-13 14:04                 ` Mohammed, Afzal
2012-06-13 14:04                   ` Mohammed, Afzal
2012-06-14  6:32                   ` Tony Lindgren
2012-06-14  6:32                     ` Tony Lindgren
2012-06-14  9:29   ` Tony Lindgren
2012-06-14  9:29     ` Tony Lindgren
2012-06-14  9:41     ` Mohammed, Afzal
2012-06-14  9:41       ` Mohammed, Afzal
2012-06-14 11:23       ` Tony Lindgren
2012-06-14 11:23         ` Tony Lindgren
2012-06-12 10:27 ` [PATCH 0/3] Prepare for GPMC driver conversion Mohammed, Afzal
2012-06-12 10:27   ` Mohammed, Afzal
2012-06-13 11:33   ` Tony Lindgren
2012-06-13 11:33     ` Tony Lindgren
2012-06-13 12:40     ` Mohammed, Afzal
2012-06-13 12:40       ` Mohammed, Afzal
2012-06-13 16:46       ` Jon Hunter
2012-06-13 16:46         ` Jon Hunter
2012-06-14  5:58         ` Mohammed, Afzal
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=afzal@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=tony@atomide.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.