Move NAND specific device tree parsing to NAND driver.

The NAND controller node must have a compatible id, register space
resource and interrupt resource.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NTony Lindgren <tony@atomide.com>

GPMC provides 2 interrupts for NAND use. i.e. fifoevent and termcount.
Use IRQ domain for this. NAND device tree node can then
get the necessary interrupts by using gpmc as the interrupt parent.

Legacy boot uses gpmc_get_client_irq to get the
NAND interrupts from the GPMC IRQ domain.
Get rid of custom bitmasks and use IRQ domain for that
as well.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NRob Herring <robh@kernel.org>
Acked-by: NTony Lindgren <tony@atomide.com>

This is needed by OMAP NAND driver to poll the empty status
of the writebuffer.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

The OMAP GPMC module has certain registers dedicated for NAND
access and some NAND bits mixed with other GPMC functionality.

For the NAND dedicated registers we have the struct gpmc_nand_regs.

The NAND driver needs to access NAND specific bits from the
following non-dedicated registers
- EMPTYWRITEBUFFERSTATUS from GPMC_STATUS

For accessing these bits we introduce the struct gpmc_nand_ops.

Add gpmc_omap_get_nand_ops() that returns the gpmc_nand_ops along
with updating the gpmc_nand_regs. This API will be called by the
OMAP NAND driver to access the necessary bits in GPMC register space.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

In order to support extended timings parameters on hardware supporting the
"AAD" mode like the AM335x or DM816x, add these entries into the GPMC driver
if the hardware is capable.

Tested on DM816x and AM335x.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

When gpmc_cs_show_timings is called in gpmc_cs_set_timings()
gpmc_cs_program_settings() was already run which modifies the CONFIG1
register. So to be more useful do the "before" dump earlier.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID -> !IRQ_NOREQUEST
IRQF_PROBE -> !IRQ_NOPROBE
IRQF_NOAUTOEN -> IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.
Signed-off-by: NRob Herring <robh@kernel.org>
Acked-by: NRoger Quadros <rogerq@ti.com>
Cc: linux-omap@vger.kernel.org
Signed-off-by: NTony Lindgren <tony@atomide.com>

If for some reason the GPMC device hasn't been probed yet, gpmc_base is
going to be NULL. Because there's no context yet to be saved, just turn
these functions into no-ops until that device gets probed.

Unable to handle kernel NULL pointer dereference at virtual address 00000010
pgd = c0204000
[00000010] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc5-next-20150804-05947-g23f38fe8eda9 #1
Hardware name: Generic OMAP3-GP (Flattened Device Tree)
task: c0e623e8 ti: c0e5c000 task.ti: c0e5c000
PC is at omap3_gpmc_save_context+0x8/0xc4
LR is at omap_sram_idle+0x154/0x23c
pc : [<c087c7ac>]    lr : [<c023262c>]    psr: 60000193
sp : c0e5df40  ip : c0f92a80  fp : c0999eb0
r10: c0e57364  r9 : c0e66f14  r8 : 00000003
r7 : 00000000  r6 : 00000003  r5 : 00000000  r4 : c0f5f174
r3 : c0fa4fe8  r2 : 00000000  r1 : 00000000  r0 : fa200280
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 80204019  DAC: 00000015
Process swapper/0 (pid: 0, stack limit = 0xc0e5c220)
Stack: (0xc0e5df40 to 0xc0e5e000)
df40: 00000000 c0e66ef8 c0f5f1a4 00000000 00000003 c02333a4 c3813822 00000000
df60: 00000000 c0e5a5c8 cfb8a5d0 c07f0c44 0e4f1d7e 00000000 00000000 00000000
df80: c3813822 00000000 cfb8a5d0 c0e5e4e4 cfb8a5d0 c0e66f14 c0e5a5c8 c0e5e54c
dfa0: c0e5e544 c0e57364 c0999eb0 c0277758 000000fa c0f5d000 00000000 c0d61c18
dfc0: ffffffff ffffffff 00000000 c0d61674 00000000 c0df7a48 00000000 c0f5d5d4
dfe0: c0e5e4c0 c0df7a44 c0e634f8 80204059 00000000 8020807c 00000000 00000000
[<c087c7ac>] (omap3_gpmc_save_context) from [<c023262c>] (omap_sram_idle+0x154/0x23c)
[<c023262c>] (omap_sram_idle) from [<c02333a4>] (omap3_enter_idle_bm+0xec/0x1a8)
[<c02333a4>] (omap3_enter_idle_bm) from [<c07f0c44>] (cpuidle_enter_state+0xbc/0x284)
[<c07f0c44>] (cpuidle_enter_state) from [<c0277758>] (cpu_startup_entry+0x174/0x24c)
[<c0277758>] (cpu_startup_entry) from [<c0d61c18>] (start_kernel+0x358/0x3c0)
[<c0d61c18>] (start_kernel) from [<8020807c>] (0x8020807c)
Code: c0ccace8 c0ccacc0 e59f30b4 e5932000 (e5921010)
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Suggested-by: NJavier Martinez Canillas <javier@dowhile0.org>
Reviewed-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Acked-by: NRoger Quadros <rogerq@ti.com>
[tony@atomide.com: updated description as suggested by Javier]
Signed-off-by: NTony Lindgren <tony@atomide.com>

We support decoding the bootloader values if DEBUG is defined.
But we also need to change the struct omap_hwmod flags to have
HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
boot. Otherwise just the default timings will be displayed
instead of the bootloader configured timings.

This also allows us to clean up the various GPMC related
hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
and HWMOD_INIT_NO_IDLE is not needed.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Roger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

We currently artificially limit the parsing of GPMC connected
devices based on the device name. Let's stop doing that, it's
confusing as adding devices to .dts files with using normal
names like fpga and usb will currently cause them to not probe.

Cc: Roger Quadros <rogerq@ti.com>
Reported-by: NBrian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

GPMC_CONFIG1_i parameters CLKACTIVATIONTIME and WAITMONITORINGTIME
have reserved values.
Raise an error if calculated timings try to program reserved values.

GPMC_CONFIG1_i ATTACHEDDEVICEPAGELENGTH and DEVICESIZE were already checked
when parsing the DT.

Explicitly comment invalid values on gpmc_cs_show_timings for
-CLKACTIVATIONTIME
-WAITMONITORINGTIME
-DEVICESIZE
-ATTACHEDDEVICEPAGELENGTH
Signed-off-by: NRobert ABEL <rabel@cit-ec.uni-bielefeld.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
even though the access is defined as asynchronous, and no GPMC_CLK clock
is provided to the external device. Still, GPMCFCLKDIVIDER is used as a divider
for the GPMC clock, so it must be programmed to define the
correct WAITMONITORINGTIME delay.

This patch correctly computes WAITMONITORINGTIME in GPMC_CLK cycles instead of GPMC_FCLK cycles,
both during programming (gpmc_cs_set_timings) and during retrieval (gpmc_cs_show_timings).
Signed-off-by: NRobert ABEL <rabel@cit-ec.uni-bielefeld.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
even though the access is defined as asynchronous, and no GPMC_CLK clock
is provided to the external device. Still, GPMCFCLKDIVIDER is used as a divider
for the GPMC clock, so it must be programmed to define the
correct WAITMONITORINGTIME delay.

Calculate GPMCFCLKDIVIDER independent of gpmc,sync-clk-ps in DT for
pure asynchronous accesses, i.e. both read and write asynchronous.
Signed-off-by: NRobert ABEL <rabel@cit-ec.uni-bielefeld.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
even though the access is defined as asynchronous, and no GPMC_CLK clock
is provided to the external device. Still, GPMCFCLKDIVIDER is used as a divider
for the GPMC clock, so it must be programmed to define the
correct WAITMONITORINGTIME delay.
Signed-off-by: NRobert ABEL <rabel@cit-ec.uni-bielefeld.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

DTS output was formatted to require additional work when copy-pasting into DTS.
Nano-second timings were replaced with interval of values that produce the same
number of clock ticks.
Signed-off-by: NRobert ABEL <rabel@cit-ec.uni-bielefeld.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

GPMC debug output is aligned to 10 characters for field names.
However, some fields have bigger names, screwing up the alignment.
Consequently, alignment was changed to longest field name (17 chars) for now.
Signed-off-by: NRobert ABEL <rabel@cit-ec.uni-bielefeld.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

This patch adds support for spawning buses as children of the GPMC.
Signed-off-by: NRobert ABEL <rabel@cit-ec.uni-bielefeld.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

OMAP2+ GPMC driver undefines DEBUG, which makes it unnecessarily
hard to turn DEBUG on. Remove the offending lines.
Signed-off-by: NRobert ABEL <rabel@cit-ec.uni-bielefeld.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

Fix sparse warning:
  warning: symbol 'gpmc_cs_get_name' was not declared. Should it be static?
Signed-off-by: NSemen Protsenko <semen.protsenko@globallogic.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

Some GPMC_CONFIG7 register bits marked as "RESERVED", means they
shouldn't be overwritten. A typical approach to handle such bits called
"Read-Modify-Write". Writing procedure used in gpmc_cs_set_memconf()
utilizes RMW technique, but implemented incorrectly. Due to obvious typo
in code read register value is being rewritten by another value, which
leads to loss of read RESERVED bits. This patch fixes this.

While at it, replace magic numbers with named constants to improve code
readability.
Signed-off-by: NSemen Protsenko <semen.protsenko@globallogic.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

Just move to drivers as further clean-up can now happen there
finally.

Let's also add Roger and me to the MAINTAINERS so we get
notified for any patches related to GPMC.

Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This will us allow to just move gpmc.c to live under drivers
in the next patch.

Note that we now also remove the omap specific check for the
initcall. That's OK as gpmc_probe() checks for the pdata
and bails out for other platforms compiled in.

Also the postcore_initcall() maybe possible to change to
just regular module_init(), but let's do that in separate
patch after the move to drivers is done.

Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We still need to support platform data for omap3 until it's booting
in device tree only mode. So let's add platform_data/omap-gpmc.h for
that, and a minimal linux/omap-gpmc.h for the save and restore used
by the PM code.

Let's also keep a minimal mach-omap2/gpmc.h still around to avoid
churn on the board-*.c files. Once omap3 boots in device tree only
mode, we can drop mach-omap2/gpmc.h and we can make the data
structures in platform_data/omap-gpmc.h private to the GPMC driver.

Note that we can now also remove gpmc-nand.h and gpmc-onenand.h.

Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP3 and lower SoCs don't have the ELM module so this warning
is annoying. Get rid of it.
Reported-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The GPMC driver includes arch/arm/mach-omap2/common.h but
does not use anything on that header so it can be removed.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Now that we have timings in the .dts files for smc91x
and 8250, we can remove the device specific checks and
just print out the bootloader timings for devices that
may not have timings in the .dts files.
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

As we still have some devices with GPMC timings missing from the
.dts files, let's make it a bit easier to use the bootloader
values and print them out.

Note that we now need to move the parsing of the device tree provided
configuration a bit earlier so we can use that for checking if anything
was configured.
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

There are cases where we have multiple device instances
connected to a single GPMC chip select. For example, there
are four UARTs on the Zoom debug boards that all share a
single chip select and a GPIO interrupt.

We do have support for this already in theory, but it's broken
because we're bailing out if the chip select is already taken.

To be able to provide checks on the chip select usage, let's
add new struct gpmc_cs_data so we can start using already
registered device names for checks.

Later on we probably want to start using struct gpmc_cs_data
as a wrapper for all the GPMC chipselect related data.
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This prevents potential division by zero errors
if GPMC fck turns out to be zero due to faulty clock
data.

Use resource managed clk_get() API.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

As per the OMAP reference manual [1], the Chip Select must be
disabled (i.e. CSVALID is 0) while configuring any of the
Chip select parameters.

[1] - 10.1.5.1 Chip-Select Base Address and Region Size Configuration
http://www.ti.com/lit/pdf/swpu177Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Although RESET state of LIMITEDADDRESS bit in GPMC_CONFIG register
is 0 (i.e. A26-A11 enabled), faulty bootloaders might accidentally
set this bit. e.g. u-boot 2014.07 with CONFIG_NOR disabled.

Explicity disable LIMITEDADDRESS bit for non NAND devices so that
they can always work.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

gpmc_cs_set_timings() returns non-zero if there was
an error while setting the GPMC timings. e.g. Timing was too
large to be accomodated with current GPMC clock frequency and available
timing range. Fail in this case, else we risk operating a NOR device
with non compliant timings.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Simplify set_gpmc_timing_reg() and always print error message
if the requested timing cannot be achieved due to a too fast
GPMC functional clock, irrespective if whether DEBUG is defined
or not. This should help us debug timing configuration issues,
which were otherwise simply not being displayed in the kernel log.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This commit adds a new platform-data boolean property that enables use
of a flash-based bad block table. This can also be enabled by setting
the 'nand-on-flash-bbt' devicetree property.

If the flash BBT is not enabled, the driver falls back to use OOB
bad block markers only, as before. If the flash BBT is enabled the
kernel will keep track of bad blocks using a BBT, in addition to
the OOB markers.

As explained by Brian Norris the reasons for using a BBT are:

""
The primary reason would be that NAND datasheets specify it these days.
A better argument is that nobody guarantees that you can write a
bad block marker to a worn out block; you may just get program failures.

This has been acknowledged by several developers over the last several
years.

Additionally, you get a boot-time performance improvement if you only
have to read a few pages, instead of a page or two from every block on
the flash.
""
Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

of_device_ids (i.e. compatible strings and the respective data) are not
supposed to change at runtime. All functions working with of_device_ids
provided by <linux/of.h> work with const of_device_ids. So mark the
non-const function parameters and structs for OMAP2+ as const, too.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For NAND read & write wait pin monitoring must be kept disabled as the
wait pin is only used to indicate NAND device ready status and not to
extend each read/write cycle.

So don't print a warning if wait pin is specified while read/write
monitoring is not in the device tree.

Sanity check wait pin number irrespective if read/write monitoring is
set or not.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For v3.14 and prior, 1-bit Hamming code ECC via software was the
default choice for some boards e.g. 3430sdp.
Commit ac65caf5 in v3.15 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.14
and prior to be unusable in v3.15 and later. So don't mark "sw" scheme
as deperecated and support it.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Currently, child nodes of the gpmc node are iterated and probed
regardless of their 'status' property. This means adding 'status =
"disabled";' has no effect.

This patch changes the iteration to only probe nodes marked as
available.
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Tested-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch add support for BCH16_ECC in GPMC (controller) driver:
- extends configuration space to include BCH16 registers
- extends parsing of DT binding for selecting BCH16 ecc-scheme
Signed-off-by: NPekon Gupta <pekon@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>