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 v2 2/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Date: Mon, 18 Jun 2012 11:01:46 -0500 [thread overview]
Message-ID: <4FDF50EA.4080506@ti.com> (raw)
In-Reply-To: <1414767dd444d4ab3998adf957e77ff4f3394f92.1339828867.git.afzal@ti.com>
Hi Afzal,
Thanks for sending the update.
On 06/16/2012 03:03 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 expected to work properly unless GPMC is setup, this
> has been removed. And invocation of set_async has been
> moved from set_sync to gpmc_onenand_init function; gpmc
> for onenand needs to be initialized to async mode (even
> for sync mode initially). Ensuring that onenand part
> has been setup for async mode has been moved now to
> setup function.
>
> Thanks to Jon for his suggestions on improving this change.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
>
> v2: Move ensuring that async mode in OneNAND has been setup from
> set_sync to setup function, improve commit message
>
> arch/arm/mach-omap2/gpmc-onenand.c | 25 ++++++++++---------------
> 1 file changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
> index 71d7c07..975c1f9 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);
Sorry if I was not clear, but I was still thinking that we keep the
above instance of setting async mode.
> return 0;
> }
> @@ -197,13 +187,10 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
> 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;
> }
> @@ -385,6 +372,12 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
> static int gpmc_onenand_setup(void __iomem *onenand_base, int *freq_ptr)
> {
> struct device *dev = &gpmc_onenand_device.dev;
> + u32 reg;
> +
> + /* 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);
... and here we should just call omap2_onenand_set_async_mode(), ...
> /* Set sync timings in GPMC */
> if (omap2_onenand_set_sync_mode(gpmc_onenand_data, onenand_base,
> @@ -421,6 +414,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);
> +
... then remove the above call.
Cheers
Jon
next prev parent reply other threads:[~2012-06-18 16:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-16 8:02 [PATCH v2 0/3] Prepare for GPMC driver conversion Afzal Mohammed
2012-06-16 8:03 ` [PATCH v2 1/3] ARM: OMAP2+: nand: unify init functions Afzal Mohammed
2012-06-16 8:03 ` [PATCH v2 2/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration Afzal Mohammed
2012-06-18 16:01 ` Jon Hunter [this message]
2012-06-19 5:57 ` Mohammed, Afzal
2012-06-20 22:11 ` Jon Hunter
2012-06-21 6:38 ` Mohammed, Afzal
2012-06-16 8:03 ` [PATCH v2 3/3] ARM: OMAP2+: gpmc: handle additional timings Afzal Mohammed
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=4FDF50EA.4080506@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 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).