This change makes the rtc on the exynos5250 and 5440 disabled by
default to match exynos4.

Ever since the common clock framework came in, exynos5250 boards
have dumped lots of warnings in the boot log. It turns out that
we don't see those on exynos4 since the rtc is disabled by default.
While we need to get to the bottom of the problems with the RTC,
it still makes sense to have the default state of the RTC on exynos
boards match.

For the record, warnings look like this:
  ------------[ cut here ]------------
  WARNING: at drivers/clk/clk.c:771 __clk_enable+0x34/0xb0()
  Modules linked in:
  [<80015bfc>] (unwind_backtrace+0x0/0xec) from [<804717f0>] (dump_stack+0x20/0x24)
  [<804717f0>] (dump_stack+0x20/0x24) from [<80023cd0>] (warn_slowpath_common+0x5c/0x7c)
  [<80023cd0>] (warn_slowpath_common+0x5c/0x7c) from [<80023d1c>] (warn_slowpath_null+0x2c/0x34)
  [<80023d1c>] (warn_slowpath_null+0x2c/0x34) from [<8035ddb0>] (__clk_enable+0x34/0xb0)
  [<8035ddb0>] (__clk_enable+0x34/0xb0) from [<8035de54>] (clk_enable+0x28/0x3c)
  [<8035de54>] (clk_enable+0x28/0x3c) from [<8031a160>] (s3c_rtc_probe+0xf4/0x434)
  [<8031a160>] (s3c_rtc_probe+0xf4/0x434) from [<8028e288>] (platform_drv_probe+0x24/0x28)
  [<8028e288>] (platform_drv_probe+0x24/0x28) from [<8028ce10>] (driver_probe_device+0xbc/0x22c)
  [<8028ce10>] (driver_probe_device+0xbc/0x22c) from [<8028cff8>] (__driver_attach+0x78/0x9c)
  [<8028cff8>] (__driver_attach+0x78/0x9c) from [<8028bdfc>] (bus_for_each_dev+0x64/0xac)
  [<8028bdfc>] (bus_for_each_dev+0x64/0xac) from [<8028c7e0>] (driver_attach+0x28/0x30)
  [<8028c7e0>] (driver_attach+0x28/0x30) from [<8028c43c>] (bus_add_driver+0xe0/0x234)
  [<8028c43c>] (bus_add_driver+0xe0/0x234) from [<8028d55c>] (driver_register+0xac/0x13c)
  [<8028d55c>] (driver_register+0xac/0x13c) from [<8028e4f4>] (platform_driver_register+0x54/0x68)
  [<8028e4f4>] (platform_driver_register+0x54/0x68) from [<8065c944>] (s3c_rtc_driver_init+0x14/0x1c)
  [<8065c944>] (s3c_rtc_driver_init+0x14/0x1c) from [<800086d8>] (do_one_initcall+0x60/0x138)
  [<800086d8>] (do_one_initcall+0x60/0x138) from [<80633a8c>] (kernel_init_freeable+0x108/0x1d0)
  [<80633a8c>] (kernel_init_freeable+0x108/0x1d0) from [<8046d2f8>] (kernel_init+0x1c/0xf4)
  [<8046d2f8>] (kernel_init+0x1c/0xf4) from [<8000e358>] (ret_from_fork+0x14/0x20)
  ---[ end trace 4bcdc801c868d73f ]---
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

This reverts commit bd51de53.

Turns out that multiplatform breaks some uses cases, such as when you
have an existing defconfig, since it adds the new EXYNOS_SINGLE config
option as a dependecy. As a result, nearly all exynos config options
will be disabled by default.

Reverting instead of rebasing since this branch is pulled in as a
dependency elsewhere.
Signed-off-by: NOlof Johansson <olof@lixom.net>

Commit 6e6aac75 "ARM: EXYNOS: Migrate clock support to common
clock framework" from Thomas Abraham removed the Exynos5 specific
register definitions as they were unused at the time, but the
cpufreq driver actually still uses them.

Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Tomasz Figa <t.figa@samsung.com>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This makes it possible to enable the exynos platform as part of a
multiplatform kernel, in addition to keeping the single-platform
exynos support.

The multiplatform variant has a number of limitations at the moment:

* It only supports DT-enabled machines. This is not a problem in
  the long run, as non-DT machines for exynos are going away.
  The main problem here is that the gpio code and the exynos_eint
  irqchip are not multiplatform capable but still required for
  ATAGS based boot.
* The watchdog driver is still missing a conversion.
* sparsemem and memory_holes are currently not supported in
  multiplatform.

The the multiplatform aware ARCH_EXYNOS Kconfig symbol is disabled
for now, as dependent patches are still pending in other
subsystem trees. We will enable it once everything comes together.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Nothing outside of the rtc driver includes plat/regs-rtc.h,
so we can simply move the file into the same directory,
which allows us to build the file as platform-independent
code.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: rtc-linux@googlegroups.com
Cc: Alessandro Zummo <a.zummo@towertech.it>

Nothing uses the NAND register definitions other than the
actual driver, so we can move the header file into the
same local directory, which lets us build it in a multiplatform
configuration.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Cc: linux-mtd@lists.infradead.org
Cc: David Woodhouse <dwmw2@infradead.org>

plat/regs-sdhci.h is not used anywhere but in the sdhci-s3c
driver, so it can become a local file there and all other
inclusions removed.

plat/sdhci.h is used only to define the platform devices,
and with the exception of the platform_data structure not
needed by the driver, so we can split out the platform_data
definition instead and leave the rest to platform code.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NChris Ball <cjb@laptop.org>

For a DT-only build we don't want to compile devs.c, but we do need
the mfc device, which is also referenced by the DT based platforms,
so move it all into one place.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The move is necessary to support early debug output on exynos
with multiplatform configurations. This implies also moving the
plat/debug-macro.S file, but we are leaving the remaining users of that
file in place, to avoid adding large numbers of extra configuration
options to Kconfig.debug
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

When we enable CONFIG_SPARSE_IRQ, we have to set the value of NR_IRQS in
the machine_desc for legacy IRQ domains, and any file referring to the
number of interrupts or a specific number must include the mach/irqs.h
header file explicitly.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

As a preparation for multiplatform support, this introduces
a new Kconfig symbol to split the ATAGS based EXYNOS platforms
from the DT based ones. Turning off CONFIG_EXYNOS_ATAGS disables
all platforms that are not yet converted to DT, and we can
have code that relies on DT checking for this symbol being
disabled.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This patch moves the arch-vt8500 irq code to drivers/irqchip and converts
it to use the new IRQCHIP_DECLARE and irqchip_init. This allows the removal
of some more functions from common.h
Signed-off-by: NTony Prisk <linux@prisktech.co.nz>
Signed-off-by: NOlof Johansson <olof@lixom.net>

This patch adds a arm-pmu node to bind device tree for exynos4210.
The exynos4210 and 4212 have two cpus which includes a pmu. In contrast, the
exynos4412 has 4 cpus and pmus. We need to define two more pmus for this type
board. However, supporting arm-pmu for the exynos4412 will handle it later
because there is no dts support for 4412 based board.
Signed-off-by: NChanho Park <chanho61.park@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This patch enables arm-pmu to bind device tree for exynos5250. The exynos5250
has two pmus which have combiner irq type.
Reviewed-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NChanho Park <chanho61.park@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This patch defines irq numbers of ARM performance monitoring unit for exynos4.
Firs of all, we need to fix IRQ_PMU correctly and to split pmu initialization
of exynos from plat-samsung for easily defining it.

The number of CPU cores and PMU irq numbers are vary according to soc types.
So, we need to identify each soc type using soc_is_xxx function and to define
the pmu irqs dynamically. For example, the exynos4412 has 4 cpu cores and pmus.
Signed-off-by: NChanho Park <chanho61.park@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This patch corrects combined IRQs for exynos4 series platform. The exynos4412
has four extra combined irq group and the exynos4212 has two more combined
irqs
than exynos4210. Each irq is mapped to IRQ_SPI(xx). Unfortunately, extra 4
combined IRQs isn't sequential. So, we need to map the irqs manually.
Signed-off-by: NChanho Park <chanho61.park@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
[kgene.kim@samsung.com: changes moved into drivers/irqchip/]
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The functions exynos4_clk_init and exynos4_clk_register_fixed_ext
are applicable only on Exynos4 non-dt platforms. But when building
Exynos5 platforms without including Exynos4 platforms, the following
errors show up.

arch/arm/mach-exynos/built-in.o: In function `exynos_init_time':
arch/arm/mach-exynos/common.c:446: undefined reference to `exynos4_clk_init'
arch/arm/mach-exynos/common.c:447: undefined reference to `exynos4_clk_register_fixed_ext'

Fix this compilation errors by marking these calls as Exynos4 specific.
Signed-off-by: NThomas Abraham <thomas.ab@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Remove duplicated include.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NStephen Warren <swarren@nvidia.com>

Add references to tegra_car clocks for the basic device nodes. Also remove
the clock-frequency property of the serial node as the UART driver can now
use the clock framework to obtain the frequency.
Signed-off-by: NPeter De Schrijver <pdeschrijver@nvidia.com>
Acked-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NStephen Warren <swarren@nvidia.com>

The Tegra clock driver is initialized during the ARM machine descriptor's
.init_irq() hook. It can't be initialized earlier, since dynamic memory
usage is required. It can't be initialized later, since the .init_timer()
hook needs the clocks initialized. However, at this time, udelay()
doesn't work.

The Tegra clock initialization table may enable some PLLs. Enabling a PLL
may require usage of udelay(). Hence, this can't happen right when the
clock driver is initialized.

To solve this, separate the clock driver initialization from the clock
table processing, so they can execute at separate times.
Signed-off-by: NStephen Warren <swarren@nvidia.com>

Move zynq timer out of mach folder to generic location
and enable it.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Remove all xilinx specific names from the driver
because this is generic driver for cadence ttc.
xttc->ttc
ttcps->ttc
...

No functional changes in this driver.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Use clocksource timer initialization.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Use cdns,ttc because this driver is Cadence Rev06
Triple Timer Counter and everybody can use it
without xilinx specific function name or probing.

Also use standard dt description for timer
and also prepare for moving to clocksource
initialization.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

This move is necessary to make use of the irqchip infrastructure
for the following devicetree support for s3c24xx architectures.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Remove the gpio related devicetree nodes as these are no longer required
with the move to a combined pinctrl/gpio driver.
Signed-off-by: NTony Prisk <linux@prisktech.co.nz>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

This patch adds pinctrl nodes to the VIA VT8500 and Wondermedia SoC dtsi
files to support the pinctrl driver.
Signed-off-by: NTony Prisk <linux@prisktech.co.nz>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

This patch adds support for the GPIO/pinmux controller found on the VIA
VT8500 and Wondermedia WM8xxx-series SoCs.

Each pin within the controller is capable of operating as a GPIO or as
an alternate function. The pins are numbered according to their control
bank/bit so that if new pins are added, the existing numbering is maintained.

All currently supported SoCs are included: VT8500, WM8505, WM8650, WM8750 and
WM8850.
Signed-off-by: NTony Prisk <linux@prisktech.co.nz>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

With the inclusion of the pin control driver, more GPIO pins have been
identified on the arch-vt8500 SoCs requiring an increase in the available
GPIOs.
Signed-off-by: NTony Prisk <linux@prisktech.co.nz>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.

This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>

The gpmc_probe_nor_child() function is used in the GPMC driver to
configure the GPMC for a NOR child device node.

But this function is quite generic and all the NOR specific configuration
is made by the driver of the actual NOR flash memory used.

Other Pseudo-SRAM devices such as ethernet controllers need a similar
setup so by making this function generic it can be used for those too.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>

gpmc_probe_nor_child() calls of_platform_device_create() to create a
platform device for the NOR child. If this function fails the value
of ret is returned to the caller but this value is zero since it was
assigned the return of a previous call to gpmc_cs_program_settings()
that had to succeed or otherwise gpmc_probe_nor_child() would have
returned before.

This means that if of_platform_device_create() fails, 0 will be returned
to the caller instead of an appropriate error code.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>

When the GPMC driver is probed, we call gpmc_mem_init() to see which
chip-selects have already been configured and enabled by the boot-loader
and allocate space for them. If we fail to allocate space for one
chip-select, then we return failure from the probe and the GPMC driver
will not be available.

Rather than render the GPMC useless for all GPMC devices, if we fail to
allocate space for one chip-select print a warning and disable the
chip-select. This way other GPMC clients can still be used.

There is no downside to this approach, because all GPMC clients need to
request a chip-select before they can use the GPMC and on requesting a
chip-select, if memory has not already been reserved for the chip-select
then it will be.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>

With commit 21cc2bda (ARM: OMAP2+: Remove apollon board support) the
variable "boot_rom_space" is now not needed and the code surrounding
this variable can be cleaned up and simplified. Remove unnecessary
definitions and clean-up the comment as well.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>

Each GPMC chip-select can be configured to map 16MB, 32MB, 64MB or 128MB
of address space. The physical base address where a chip-select starts
is also configurable and must be aligned on a boundary that is equal to
or greater than the size of the address space mapped bt the chip-select.
When enabling a GPMC chip-select, ensure that the base address is aligned
to the appropriate boundary.
Reported-by: NMark Jackson <mpfj-list@mimc.co.uk>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>

When booting with device-tree, retrieve GPMC settings for ONENAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.

The user must now specify the ONENAND device width in the device-tree
binding so that the GPMC can be programmed correctly. Therefore, update
the device-tree binding documentation for ONENAND devices connected to
the GPMC to reflect this.

Please note that this does not include GPMC timings for ONENAND. The
timings are being calculated at runtime.

There is some legacy code that only enables read wait monitoring for
non-OMAP3 devices. There are no known OMAP3 device issues that prevent
this feature being enabled and so when booting with device-tree use the
wait-monitoring settings described in the device-tree blob.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>

When booting with device-tree, retrieve GPMC settings for NAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>

NOR flash is not currently supported when booting with device-tree
on OMAP2+ devices. Add support to detect and configure NOR devices
when booting with device-tree.

Add documentation for the TI GPMC NOR binding.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>

Some of the GPMC timings parameters are currently missing from the GPMC
device-tree binding. Add these parameters to the binding documentation
as well as code to read them. Also add either "-ps" or "-ns" suffix to
the GPMC timing properties to indicate whether the timing is in
picoseconds or nanoseconds.

The existing code in gpmc_read_timings_dt() is checking the value of
of_property_read_u32() and only is successful storing the value read
in the gpmc_timings structure. Checking the return value in this case
is not necessary and we can simply read the value, if present, and
store directly in the gpmc_timings structure. Therefore, simplify the
code by removing these checks.

The comment in the gpmc_read_timings_dt() function, "only for OMAP3430"
is also incorrect as it is applicable to all OMAP3+ devices. So correct
this too.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>

When I applied regarding samsung-time patches, the "select GENERIC_GPIO"
has been added wrong, so this patch fixes that.
And since the GENERIC_GPIO in arch/arm/ will be gone away, this adds
ARCH_REQUIRE_GPIOLIB for S3C24XX and S5PC100 instead.
Reported-by: NAlexandre Courbot <gnurou@gmail.com>
Cc: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>