From: Tony Lindgren <tony@atomide.com>
To: Roger Quadros <rogerq@ti.com>
Cc: linux-omap@vger.kernel.org, jg1.han@samsung.com, nsekhar@ti.com,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
pekon@ti.com, ezequiel.garcia@free-electrons.com,
javier@dowhile0.org, computersforpeace@gmail.com,
dwmw2@infradead.org
Subject: Re: [RFC PATCH 00/10] OMAP: GPMC: NAND: Introduce GPMC APIs for OMAP NAND
Date: Thu, 10 Jul 2014 23:52:12 -0700 [thread overview]
Message-ID: <20140711065211.GK28884@atomide.com> (raw)
In-Reply-To: <1404909450-11970-1-git-send-email-rogerq@ti.com>
* Roger Quadros <rogerq@ti.com> [140709 05:39]:
> Hi,
>
> The following hardware modules/registers are meant for NAND controller driver
> usage:
> - NAND I/O control (NAND address, data, command registers)
> - Prefetch/Write-post engine
> - ECC/BCH engine
>
> However, these registers sit in the GPMC controller's register space and there
> need to be some sane way to access them from the OMAP NAND controller driver.
>
> Till now the GPMC driver was populating a data structure (struct gpmc_nand_regs)
> with the register addresses and passing it to the OMAP NAND driver via platform
> data. This mechanism cannot be used for true Device tree support as custom
> platform data passing mechanism doesn't seem to work. Moreover, direct
> access to these registers must be limited to the GPMC driver. This calls for
> a few custom OMAP GPMC specific APIs that the OMAP NAND driver can use
> to access these GPMC space registers.
>
> This series attempts to add the following new APIs and gets rid of
> 'struct gpmc_nand_regs' and 'gpmc_update_nand_regs()'.
>
> -For NAND I/O control registers
> u32 omap_gpmc_read_reg(int cs, enum omap_gpmc_reg reg);
> void omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg, u32 val);
>
> -For Prefetch engine
> int omap_gpmc_prefetch_start(int cs, int fifo_th, bool dma,
> u32 count, int is_write);
> int omap_gpmc_prefetch_stop(int cs);
> u32 omap_gpmc_get_prefetch_count(void);
> u32 omap_gpmc_get_prefetch_fifo_count(void);
>
> -For ECC/BCH engine
> void omap_gpmc_ecc_disable(void);
> void omap_gpmc_ecc_configure_enable(int cs, bool ecc16, u8 ecc_size0,
> u8 ecc_size1, bool use_bch,
> enum omap_gpmc_bch_type bch_type,
> u8 bch_sectors, u8 bch_wrap_mode);
> void omap_gpmc_ecc_get_result(int length, u32 *result);
> void omap_gpmc_ecc_get_bch_result(int length, u8 sector, u32 *result);
These seem fine to me. At least I don't have any better ideas to
expose these GPMC registers to the NAND driver(s).
> These APIs don't implement any logic to serialize access to the
> NAND/Prefetch/ECC registers. It is upto the NAND controller driver
> to ensure that. As these modules can only handle one NAND controller context
> at a time, we set the nand_chip->hwcontrol to point to a single
> controller instance even if there are multiple NAND chips on different
> Chip select spaces. The NAND base driver then takes care of serializing
> access to the NAND controller (and ECC) through nandchip->hwcontrol->lock.
>
> NOTE: Patches are still untested and only meant for review.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Roger Quadros <rogerq@ti.com>
Cc: computersforpeace@gmail.com, javier@dowhile0.org, pekon@ti.com,
ezequiel.garcia@free-electrons.com, dwmw2@infradead.org,
jg1.han@samsung.com, nsekhar@ti.com,
linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 00/10] OMAP: GPMC: NAND: Introduce GPMC APIs for OMAP NAND
Date: Thu, 10 Jul 2014 23:52:12 -0700 [thread overview]
Message-ID: <20140711065211.GK28884@atomide.com> (raw)
In-Reply-To: <1404909450-11970-1-git-send-email-rogerq@ti.com>
* Roger Quadros <rogerq@ti.com> [140709 05:39]:
> Hi,
>
> The following hardware modules/registers are meant for NAND controller driver
> usage:
> - NAND I/O control (NAND address, data, command registers)
> - Prefetch/Write-post engine
> - ECC/BCH engine
>
> However, these registers sit in the GPMC controller's register space and there
> need to be some sane way to access them from the OMAP NAND controller driver.
>
> Till now the GPMC driver was populating a data structure (struct gpmc_nand_regs)
> with the register addresses and passing it to the OMAP NAND driver via platform
> data. This mechanism cannot be used for true Device tree support as custom
> platform data passing mechanism doesn't seem to work. Moreover, direct
> access to these registers must be limited to the GPMC driver. This calls for
> a few custom OMAP GPMC specific APIs that the OMAP NAND driver can use
> to access these GPMC space registers.
>
> This series attempts to add the following new APIs and gets rid of
> 'struct gpmc_nand_regs' and 'gpmc_update_nand_regs()'.
>
> -For NAND I/O control registers
> u32 omap_gpmc_read_reg(int cs, enum omap_gpmc_reg reg);
> void omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg, u32 val);
>
> -For Prefetch engine
> int omap_gpmc_prefetch_start(int cs, int fifo_th, bool dma,
> u32 count, int is_write);
> int omap_gpmc_prefetch_stop(int cs);
> u32 omap_gpmc_get_prefetch_count(void);
> u32 omap_gpmc_get_prefetch_fifo_count(void);
>
> -For ECC/BCH engine
> void omap_gpmc_ecc_disable(void);
> void omap_gpmc_ecc_configure_enable(int cs, bool ecc16, u8 ecc_size0,
> u8 ecc_size1, bool use_bch,
> enum omap_gpmc_bch_type bch_type,
> u8 bch_sectors, u8 bch_wrap_mode);
> void omap_gpmc_ecc_get_result(int length, u32 *result);
> void omap_gpmc_ecc_get_bch_result(int length, u8 sector, u32 *result);
These seem fine to me. At least I don't have any better ideas to
expose these GPMC registers to the NAND driver(s).
> These APIs don't implement any logic to serialize access to the
> NAND/Prefetch/ECC registers. It is upto the NAND controller driver
> to ensure that. As these modules can only handle one NAND controller context
> at a time, we set the nand_chip->hwcontrol to point to a single
> controller instance even if there are multiple NAND chips on different
> Chip select spaces. The NAND base driver then takes care of serializing
> access to the NAND controller (and ECC) through nandchip->hwcontrol->lock.
>
> NOTE: Patches are still untested and only meant for review.
Regards,
Tony
next prev parent reply other threads:[~2014-07-11 6:52 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-09 12:37 [RFC PATCH 00/10] OMAP: GPMC: NAND: Introduce GPMC APIs for OMAP NAND Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` [RFC PATCH 01/10] mtd: nand: omap: Use a single hardware controller instance Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` [RFC PATCH 02/10] mtd: nand: omap: Always use chip->ecc.steps for BCH sector count Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-11 7:43 ` Gupta, Pekon
2014-07-11 7:43 ` Gupta, Pekon
2014-07-11 10:35 ` Roger Quadros
2014-07-11 10:35 ` Roger Quadros
2014-07-11 11:27 ` Gupta, Pekon
2014-07-11 11:27 ` Gupta, Pekon
2014-07-11 11:51 ` Roger Quadros
2014-07-11 11:51 ` Roger Quadros
2014-07-09 12:37 ` [RFC PATCH 03/10] OMAP: GPMC: Introduce APIs to access NAND control registers Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` [RFC PATCH 04/10] mtd: nand: omap: Use GPMC APIs for NAND control Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` [RFC PATCH 05/10] OMAP: GPMC: Introduce APIs for accessing Prefetch/Write-post engine Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` [RFC PATCH 06/10] mtd: nand: omap: Use GPMC APIs for accessing Prefetch engine Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` [RFC PATCH 07/10] OMAP: GPMC: Introduce APIs for Configuring ECC Engine Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-11 7:54 ` Gupta, Pekon
2014-07-11 7:54 ` Gupta, Pekon
2014-07-09 12:37 ` [RFC PATCH 08/10] OMAP: GPMC: Introduce APIs to get ECC/BCH results Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` [RFC PATCH 09/10] mtd: nand: omap: Use GPMC APIs for accessing ECC/BCH engine Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-11 7:56 ` Gupta, Pekon
2014-07-11 7:56 ` Gupta, Pekon
2014-07-09 12:37 ` [RFC PATCH 10/10] OMAP: GPMC: NAND: Don't pass NAND/ECC/BCH register adresses to NAND driver Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-09 12:37 ` Roger Quadros
2014-07-11 6:52 ` Tony Lindgren [this message]
2014-07-11 6:52 ` [RFC PATCH 00/10] OMAP: GPMC: NAND: Introduce GPMC APIs for OMAP NAND Tony Lindgren
2014-07-11 7:27 ` Gupta, Pekon
2014-07-11 7:27 ` Gupta, Pekon
2014-07-11 8:28 ` Roger Quadros
2014-07-11 8:28 ` Roger Quadros
2014-07-11 9:42 ` Gupta, Pekon
2014-07-11 9:42 ` Gupta, Pekon
2014-07-11 10:23 ` Roger Quadros
2014-07-11 10:23 ` Roger Quadros
2014-07-29 10:39 ` Tony Lindgren
2014-07-29 10:39 ` Tony Lindgren
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=20140711065211.GK28884@atomide.com \
--to=tony@atomide.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ezequiel.garcia@free-electrons.com \
--cc=javier@dowhile0.org \
--cc=jg1.han@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=pekon@ti.com \
--cc=rogerq@ti.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.