by Ray Jui

[permalink] [raw]

Subject: Re: [PATCH v3 06/10] mtd: brcmstb_nand: add SoC-specific support

On 5/8/2015 1:47 PM, Brian Norris wrote:
> On Fri, May 08, 2015 at 09:49:02PM +0200, Arnd Bergmann wrote:
>> On Friday 08 May 2015 12:38:50 Brian Norris wrote:
>>> On Fri, May 08, 2015 at 03:41:10PM +0200, Arnd Bergmann wrote:
> [...]
>
>>> To be clear, since I'm not sure if you're confused below:
>>>
>>> * Cygnus is a family of chips using the IPROC architecture, coming from
>>> the Infrastructure/Networking Group; there are BCMxxxx numbers noted
>>> in arch/arm/mach-bcm/Kconfig for them, but I usually just refer to
>>> the Cygnus family or the IPROC architecture.
>>>
>>> * BCM63xxx is a class of DSL chips from the Broadband/Connectivity
>>> Group.
>>
>> Thanks for the clarification, I think that is roughly what I thought it was,
>> but I'm still not sure about brcmstb. Is that related to bcm63xxx or separate?
>
> I think arch/arm/mach-bcm/Kconfig has the best summary. brcmstb is
> separate; BCM7xxx is generally (always?) Set-Top Box.
>
> Another potentially confusing point: the main driver is named
> 'brcsmtb_nand' since the NAND core (and driver) originated from STB
> chips. But that core was applied to other non-STB chips, and so the
> driver has been extended.
>
>>>> bcm63138_nand_driver with its own probe() function that calls the
>>>> common probe function. That would make the soc specific parts
>>>> better contained and match how we normally do abstractions of
>>>> similar drivers.
>>>
>>> OK, so I can imagine this might require changing the DT binding a bit [1]
>>> (is that your goal?). But what's the intended software difference? [2]
>>> I'll still be passing around the same sorts of callbacks from the
>>> 'iproc_nand' probe to the common probe function.
>
> ^^ before getting bogged down on the DT details (which can be changed
> independently), I'd like to address this point.
>
>>> Brian
>>>
>>> [1] e.g.:
>>>
>>> nand: nand@18046000 {
>>> compatible = "brcm,iproc-nand", "brcm,brcmnand-v6.1", "brcm,brcmnand";
>>> reg = <0x18046000 0x600>, <0xf8105408 0x600>, <0x18046f00 0x20>;
>>> reg-names = "nand", "iproc-idm", "iproc-ext";
>>> interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
>>>
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> brcm,nand-has-wp;
>>> };
>>>
>>> This captures the extra "iproc-*" register ranges. Then we could have
>>> the iproc_nand driver bind against "brcm,iproc-nand", then call into the
>>> common probe, which would then accept/reject based on
>>> "brcm,brcmnand-vX.Y".
>>>
>>> [2] The DT structure from [1] could actually accommodate either driver
>>> structure just fine. So maybe that means it's a better hardware
>>> description?
>>
>> Yes, I think this makes sense overall. Regarding the specific example, can you
>> clarify how the register areas in iproc are structured?
>>
>> The 0xf8105408 and 0x18046f00 start addresses are not aligned to large powers
>> of two, which often indicates that they are part of some other, larger,
>> unit that might need to have a driver of its own, so before we specify
>> a binding like the one you proposed above I'd like to make sure we're not
>> getting ourselves into trouble later.
>
> I may want the Cygnus guys to speak up here, partly for technical
> expertise and partly to know how much they care to share...
>
> <0xf8105408 0x600>: covers a series of NAND_IDM registers. NAND has a
> few bits we don't care about (for debugging, logging, and resetting), as
> well as its interrupt enable bits. The adjacent blocks cover similar IDM
> blocks for other cores (SPI, PNOR, DDR), and they are similarly
> unaligned. Not sure why, exactly; probably just a compact layout.

Yes, starting from 0xf8105408, within the range of 0x600, there are
various NAND_IDM registers scattered, which is indeed a very weird
register layout.

Like Brian said, most of those NAND_IDM registers are for debugging,
logging, or status reporting. As of today, we only care about the first
register, that contains a bunch of bits that allow you to configure the
endianness of the AXI/APB bus, enabling NAND interrupts and clocks.

>
> <0x18046f00 0x20>: a series of 8 NAND interrupt registers, each word
> containing a single bit representing status/clear. There is nothing
> between the "nand" range and this range, and the SPI core register range
> follows.

Correct.

>
> So I think these are pretty clearly-delineated register ranges for NAND,
> and the alignment is not really missing anything. Adjacent hardware
> (e.g., SPI) is independent, though pieces look similar. For one, it has
> similar:
>
> * interrupt enable bits in the IDM range (0xf8106408 to 0xf8106a00);
> and
> * interrupt status/clear following the SPI block (0x180473a0 to
> 0x180473b8)
>
> Brian
>

2015-05-11 23:26:05

by Brian Norris

[permalink] [raw]

Subject: Re: [PATCH v3 01/10] mtd: nand: add common DT init code

On Wed, May 06, 2015 at 10:59:45AM -0700, Brian Norris wrote:
> These are already-documented common bindings for NAND chips. Let's
> handle them in nand_base.
>
> If NAND controller drivers need to act on this data before bringing up
> the NAND chip (e.g., fill out ECC callback functions, change HW modes,
> etc.), then they can do so between calling nand_scan_ident() and
> nand_scan_tail().
>
> Signed-off-by: Brian Norris <[email protected]>

Pushed just this patch to l2-mtd.git, since it's relatively
uncontroversial and hasn't changed across the first three revisions. It
should be of benefit to a few other driver writers out there that I've
reviewed.

Brian

> ---
> drivers/mtd/nand/nand_base.c | 41 +++++++++++++++++++++++++++++++++++++++++
> include/linux/mtd/nand.h | 5 +++++
> 2 files changed, 46 insertions(+)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index c2e1232cd45c..c6cf775ee431 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -48,6 +48,7 @@
> #include <linux/leds.h>
> #include <linux/io.h>
> #include <linux/mtd/partitions.h>
> +#include <linux/of_mtd.h>
>
> /* Define default oob placement schemes for large and small page devices */
> static struct nand_ecclayout nand_oob_8 = {
> @@ -3798,6 +3799,39 @@ ident_done:
> return type;
> }
>
> +static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip,
> + struct device_node *dn)
> +{
> + int ecc_mode, ecc_strength, ecc_step;
> +
> + if (of_get_nand_bus_width(dn) == 16)
> + chip->options |= NAND_BUSWIDTH_16;
> +
> + if (of_get_nand_on_flash_bbt(dn))
> + chip->bbt_options |= NAND_BBT_USE_FLASH;
> +
> + ecc_mode = of_get_nand_ecc_mode(dn);
> + ecc_strength = of_get_nand_ecc_strength(dn);
> + ecc_step = of_get_nand_ecc_step_size(dn);
> +
> + if ((ecc_step >= 0 && !(ecc_strength >= 0)) ||
> + (!(ecc_step >= 0) && ecc_strength >= 0)) {
> + pr_err("must set both strength and step size in DT\n");
> + return -EINVAL;
> + }
> +
> + if (ecc_mode >= 0)
> + chip->ecc.mode = ecc_mode;
> +
> + if (ecc_strength >= 0)
> + chip->ecc.strength = ecc_strength;
> +
> + if (ecc_step > 0)
> + chip->ecc.size = ecc_step;
> +
> + return 0;
> +}
> +
> /**
> * nand_scan_ident - [NAND Interface] Scan for the NAND device
> * @mtd: MTD device structure
> @@ -3815,6 +3849,13 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
> int i, nand_maf_id, nand_dev_id;
> struct nand_chip *chip = mtd->priv;
> struct nand_flash_dev *type;
> + int ret;
> +
> + if (chip->dn) {
> + ret = nand_dt_init(mtd, chip, chip->dn);
> + if (ret)
> + return ret;
> + }
>
> /* Set the default functions */
> nand_set_defaults(chip, chip->options & NAND_BUSWIDTH_16);
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 3d4ea7eb2b68..e0f40e12a2c8 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -26,6 +26,8 @@
>
> struct mtd_info;
> struct nand_flash_dev;
> +struct device_node;
> +
> /* Scan and identify a NAND device */
> extern int nand_scan(struct mtd_info *mtd, int max_chips);
> /*
> @@ -542,6 +544,7 @@ struct nand_buffers {
> * flash device
> * @IO_ADDR_W: [BOARDSPECIFIC] address to write the 8 I/O lines of the
> * flash device.
> + * @dn: [BOARDSPECIFIC] device node describing this instance
> * @read_byte: [REPLACEABLE] read one byte from the chip
> * @read_word: [REPLACEABLE] read one word from the chip
> * @write_byte: [REPLACEABLE] write a single byte to the chip on the
> @@ -644,6 +647,8 @@ struct nand_chip {
> void __iomem *IO_ADDR_R;
> void __iomem *IO_ADDR_W;
>
> + struct device_node *dn;
> +
> uint8_t (*read_byte)(struct mtd_info *mtd);
> u16 (*read_word)(struct mtd_info *mtd);
> void (*write_byte)(struct mtd_info *mtd, uint8_t byte);
> --
> 1.9.1
>