Add clocks for gpmi-nand.
Signed-off-by: NHuang Shijie <shijie8@gmail.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

Aas the flexcan driver has DT binding for some time now. This patch makes
the flexcan driver available in the can drivers menu if a SOC with flexcan
is enabled.
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

Add the DT node for gpmi nand.
Add the pinmux support for gpmi nand.

The gpmi nand may conflicts with other modules, such as MMC.
So we do not enable the gpmi nand for mx6q-arm2 board, just add the
node for the board.
Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NHuang Shijie <shijie8@gmail.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

add clock for apbh-dma.
Signed-off-by: NHuang Shijie <shijie8@gmail.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

add DT node for apbh-dma.
Signed-off-by: NHuang Shijie <shijie8@gmail.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

When moving to common clk framework, the imx6q clks rom and mmdc_ch1_axi
get different on/off states than old clk driver, which breaks suspend
function.  There might be a better way to manage these clocks, but let's
takes the old clk driver approach to fix the regression first.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

OMAP4470 currently fails to boot, printing various messages such as ...

omap_hwmod: mpu: cannot clk_get main_clk dpll_mpu_m2_ck
omap_hwmod: mpu: cannot _init_clocks
------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:2062 _init+0x2a0/0x2e4()
omap_hwmod: mpu: couldn't init clocks
Modules linked in:
[<c001c7fc>] (unwind_backtrace+0x0/0xf4) from [<c0043c64>] (warn_slowpath_common+0x4c/0x64)
[<c0043c64>] (warn_slowpath_common+0x4c/0x64) from [<c0043d10>] (warn_slowpath_fmt+0x30/0x40)
[<c0043d10>] (warn_slowpath_fmt+0x30/0x40) from [<c0674208>] (_init+0x2a0/0x2e4)
[<c0674208>] (_init+0x2a0/0x2e4) from [<c067428c>] (omap_hwmod_setup_one+0x40/0x60)
[<c067428c>] (omap_hwmod_setup_one+0x40/0x60) from [<c0674280>] (omap_hwmod_setup_one+0x34/0x60)
[<c0674280>] (omap_hwmod_setup_one+0x34/0x60) from [<c06726f4>] (omap_dm_timer_init_one+0x30/0x250)
[<c06726f4>] (omap_dm_timer_init_one+0x30/0x250) from [<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108)
[<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108) from [<c0672c60>] (omap4_timer_init+0x10/0x5c)
[<c0672c60>] (omap4_timer_init+0x10/0x5c) from [<c066c418>] (time_init+0x20/0x30)
[<c066c418>] (time_init+0x20/0x30) from [<c0668814>] (start_kernel+0x1b0/0x304)
[<c0668814>] (start_kernel+0x1b0/0x304) from [<80008044>] (0x80008044)
---[ end trace 1b75b31a2719ed1c ]---

The problem is that currently none of the clocks are being registered for
OMAP4470 devices and so on boot-up no clocks can be found and the kernel panics.

This fix allows the kernel to boot without failure using a simple RAMDISK file
system on OMAP4470 blaze board.

Per feedback from Paul and Benoit the 4470 clock data is incomplete for new
modules such as the 2D graphics block that has been added to the 4470.
Therefore add a warning to indicate that the clock data is incomplete.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 20ef9e08 ("ARM: EXYNOS: Support DMA for EXYNOS5250 SoC")
renamed EXYNOS4_DEV_DMA to EXYNOS_DEV_DMA. But some machine entries
still had EXYNOS4_DEV_DMA. Changed them to EXYNOS_DEV_DMA.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

commit 8259573b (ARM: OMAP2+: nand: Make board_onenand_init() visible
to board code) broke the build for configs with OneNAND disabled.  By
removing the static in the header file, it created a duplicate definition
in the .c and the .h files, resuling in a build error:

/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.c:102:111: error: redefinition of 'board_onenand_init'
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.h:56:51: note: previous definition of 'board_onenand_init' was here
make[2]: *** [arch/arm/mach-omap2/board-flash.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [arch/arm/mach-omap2] Error 2
make: *** [sub-make] Error 2

Fix this by removing the duplicate dummy entry from the C file.

Cc: Enric Balletbò i Serra <eballetbo@gmail.com>
Cc: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

IOMMU-aware dma_alloc_attrs() implementation allocates buffers in
power-of-two chunks to improve performance and take advantage of large
page mappings provided by some IOMMU hardware. However current code, due
to a subtle bug, allocated those chunks in the smallest-to-largest
order, what completely killed all the advantages of using larger than
page chunks. If a 4KiB chunk has been mapped as a first chunk, the
consecutive chunks are not aligned correctly to the power-of-two which
match their size and IOMMU drivers were not able to use internal
mappings of size other than the 4KiB (largest common denominator of
alignment and chunk size).

This patch fixes this issue by changing to the correct largest-to-smallest
chunk size allocation sequence.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>

The orion watchdog is expecting to be passed the physcial address of
the hardware, and will ioremap() it to give a virtual address it will
use as the base address for the hardware. However, when creating the
platform resource record, a virtual address was being used.

Add the necassary #define's so we can pass the physical address as
expected.

Tested on Kirkwood and Orion5x.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NOlof Johansson <olof@lixom.net>

In commit:
    98d9986c ARM: Kirkwood: Replace clock gating
the kirkwood clock gating has been reworked. A custom variant of
clock gating, that calls a custom function before gating the clock
off, has been introduced. However in clk_register_gate_fn() this
custom function "fn" is never assigned.

This patch adds the missing fn assignment.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NMarc Kleine-Budde <mkl@blackshift.org>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Acked-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Commit 4d5fc58d (ARM: remove bunch of
now unused mach/io.h files) removed the orion5x io.h. Unfortunately,
this is still needed for the definition of IO_SPACE_LIMIT which
overrides the default 64K. All Orion based systems have 1Mbyte of IO
space per PCI[e] bus, and try to request_resource() this size. Orion5x
has two such PCI buses.

It is likely that the original, removed version, was broken. This
version might be less broken. However, it has not been tested on
hardware with a PCI card, let alone hardware with a PCI card with IO
capabilities.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Acked-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Without this, the interrupts for I2C, VIN, GPIO, SDHC, HSCIF and
HPB-DMAC are sent to the SH processor.
Signed-off-by: NPhil Edworthy <phil.edworthy@renesas.com>
Acked-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

As per the OMAP4 documentation, audio over HDMI must be transmitted in
no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmod uses
no-idle/force-idle settings instead of smart-idle mode.

This is required as the DSS interface clock is used as functional clock
for the HDMI wrapper audio FIFO. If no-idle mode is not used, audio could
be choppy, have bad quality or not be audible at all.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
[b-cousson@ti.com: Update the subject and align the .flags
location with the script template]
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit bbd707ac ("ARM: omap2: use
machine specific hook for late init") resulted in the addition of this
sparse warning:

arch/arm/mach-omap2/mux.c:791:12: warning: symbol 'omap_mux_late_init' was not declared. Should it be static?

Fix by including the header file containing the prototype.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>

Increase the timeout for disabling an IP block to five milliseconds.
This is to handle the usb_host_fs idle latency, which takes almost
four milliseconds after a host controller reset.

This is the second of two patches needed to resolve the following
boot warning:

omap_hwmod: usb_host_fs: _wait_target_disable failed

Thanks to Sergei Shtylyov <sshtylyov@mvista.com> for finding
an unrelated hunk in a previous version of this patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: Tero Kristo <t-kristo@ti.com>

Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it.  This
patch populates some clock structure clockdomain names to resolve the
following warnings during kernel init:

omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>

The 32k sync timer IP block target idle modes in the hwmod data are
incorrect.  The IP block does not support any smart-idle modes.
Update the data to reflect the correct modes.

This problem was initially identified and a diff fragment posted to
the lists by Benoît Cousson <b-cousson@ti.com>.  A patch description
bug in the first version was also identified by Benoît.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>

If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the
IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup.
Signed-off-by: NDjamil Elaidi <d-elaidi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Since commit 21cc1b7e ("ARM: shmobile:
use machine specific hook for late init") suspend and CPU idle are not
initialized automatically anymore. Set shmobile_init_late() as the
machine late init hook to initialize them.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Since commit 21cc1b7e ("ARM: shmobile:
use machine specific hook for late init") suspend and CPU idle are not
initialized automatically anymore. Set shmobile_init_late() as the
machine late init hook to initialize them.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Since commit 21cc1b7e ("ARM: shmobile:
use machine specific hook for late init") suspend and CPU idle are not
initialized automatically anymore. Set shmobile_init_late() as the
machine late init hook to initialize them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

viresh.kumar@st.com email-id doesn't exist anymore as I have left the
company.  Replace ST's id with viresh.linux@gmail.com.

It also updates .mailmap file to fix address for 'git shortlog'
Signed-off-by: NViresh Kumar <viresh.linux@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

While upgrading the kernel on a S3C2412 based board I've noted
that it was impossible to boot the board with a 2.6.32 or upper
kernel. I've tracked down the problem to the EBI virtual memory
mapping that is in conflict with the IO mapping definition in
arch/arm/mach-s3c24xx/s3c2412.c.
Signed-off-by: NJose Miguel Goncalves <jose.goncalves@inov.pt>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Commit e813a55e ("OMAP: board-files:
remove custom PD GPIO handling for DVI output") moved TFP410 chip's
powerdown-gpio handling from the board files to the tfp410 driver. One
gpio_request_one(powerdown-gpio, ...) was mistakenly left unremoved in
the Beagle board file. This causes the tfp410 driver to fail to request
the gpio on Beagle, causing the driver to fail and thus the DVI output
doesn't work.

This patch removes several boot errors from board-omap3beagle.c:

 - gpio_request: gpio--22 (DVI reset) status -22
 - Unable to get DVI reset GPIO

There is a combination of leftover code and revision confusion.
Additionally, xM support is currently a hack.

For original Beagleboard this removes the double initialization of GPIO
170, properly configures it as an output, and wraps the initialization
in an if block so that xM does not attempt to request it.

For Beagleboard xM it removes reference to GPIO 129 which was part
of rev A1 and A2 designs, but never functioned. It then properly assigns
beagle_dvi_device.reset_gpio in beagle_twl_gpio_setup and removes the
hack of initializing it high. Additionally, it uses
gpio_set_value_cansleep since this GPIO is connected through i2c.

Unfortunately, there is no way to tell the difference between xM A2 and
A3. However, GPIO 129 does not function on rev A1 and A2, and the TWL
GPIO used on A3 and beyond is not used on rev A1 and A2, there are no
problems created by this fix.

Tested on Beagleboard-xM Rev C1 and Beagleboard Rev B4.
Signed-off-by: NRuss Dill <Russ.Dill@ti.com>
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

When booting with device-tree on an OMAP2420H4, the kernel is hanging when
initialising the interrupts and following kernel dumps is seen ...

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at arch/arm/mach-omap2/irq.c:271 omap_intc_of_init+0x50/0xb4()
[    0.000000] unable to get intc registers
[    0.000000] Modules linked in:
[    0.000000] [<c001befc>] (unwind_backtrace+0x0/0xf4) from [<c0040c34>] (warn_slowpath_common+0x4c/0x64)
[    0.000000] [<c0040c34>] (warn_slowpath_common+0x4c/0x64) from [<c0040ce0>] (warn_slowpath_fmt+0x30/0x40)
[    0.000000] [<c0040ce0>] (warn_slowpath_fmt+0x30/0x40) from [<c066b8a4>] (omap_intc_of_init+0x50/0xb4)
[    0.000000] [<c066b8a4>] (omap_intc_of_init+0x50/0xb4) from [<c0688b70>] (of_irq_init+0x144/0x288)
[    0.000000] [<c0688b70>] (of_irq_init+0x144/0x288) from [<c0663294>] (init_IRQ+0x14/0x1c)
[    0.000000] [<c0663294>] (init_IRQ+0x14/0x1c) from [<c06607fc>] (start_kernel+0x198/0x304)
[    0.000000] [<c06607fc>] (start_kernel+0x198/0x304) from [<80008044>] (0x80008044)
[    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
[    0.000000] of_irq_init: children remain, but no parents

The OMAP2 interrupt controller binding is missing the number of interrupts and
interrupt controller register address. Adding these fixes the problem.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Here's one more gpio_to_irq conversion that we missed
earlier. Tested with n800 in gadget mode using USB_ETH.

Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 62285963 (usb: musb: drop a gigantic amount of ifdeferry)
got rid of a bunch of ifdefs in the MUSB code. Looks like the
platform init code is still using these dropped defines though,
which in many cases results the board defaulting always to host
mode.

Currently the situation is that USB_MUSB_HDRC is the main
Kconfig option with additional USB_GADGET_MUSB_HDRC so only
these two should be used to select between host and OTG mode.

Fix the situation for omaps. The following users should fix the
platform init code in a similar way:

Dropped Kconfig option          Current users

USB_MUSB_OTG                    blackfin, davinci, not in Kconfigs
USB_MUSB_PERIPHERAL             davinci, not in Kconfigs
USB_MUSB_HOST                   davinci, not in Kconfigs
USB_MUSB_HDRC_HCD               blackfin, not in Kconfigs
USB_MUSB_OTG                    blackfin, not in Kconfigs

Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: linux-usb@vger.kernel.org
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

SDHI0 card-detect GPIO IRQ on mackarel currently works, because it is the
default configuration of IRQ26. However, we should not rely on this and
should configure the function explicitly.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Build failed, when SMP is enabled and EMEV2 is not enabled.

arch/arm/mach-shmobile/built-in.o: In function `shmobile_platform_cpu_kill':
/home/iwamatsu/work/kernel/sh-2.6-devel/arch/arm/mach-shmobile/platsmp.c:62: undefined reference to `emev2_platform_cpu_kill'
arch/arm/mach-shmobile/built-in.o: In function `shmobile_smp_get_core_count':
/home/iwamatsu/work/kernel/sh-2.6-devel/arch/arm/mach-shmobile/platsmp.c:39: undefined reference to `emev2_get_core_count'
arch/arm/mach-shmobile/built-in.o: In function `shmobile_smp_prepare_cpus':
/home/iwamatsu/work/kernel/sh-2.6-devel/arch/arm/mach-shmobile/platsmp.c:53: undefined reference to `emev2_smp_prepare_cpus'
arch/arm/mach-shmobile/built-in.o: In function `platform_secondary_init':
/home/iwamatsu/work/kernel/sh-2.6-devel/arch/arm/mach-shmobile/platsmp.c:78: undefined reference to `emev2_secondary_init'
arch/arm/mach-shmobile/built-in.o: In function `boot_secondary':
/home/iwamatsu/work/kernel/sh-2.6-devel/arch/arm/mach-shmobile/platsmp.c:90: undefined reference to `emev2_boot_secondary

This is the cause by when EMEV2 is disabled, that the check by OF of EMEV2 is
performed in platsmp.c.
This patch revise what the function about EMEV2 may not be used in this file,
when EMEV2 is not enabled.
Signed-off-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Acked-by: NSimon Horman <horms@verge.net.au>
Acked-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

chclr_write() will use (chan_reg + chclr_offset).
In sh7372 case, DMA1CHCLR is started from 0xfe008220,
and chan_reg is started from 0xfe008020 (= sh7372_dmae0_resources).
Thus, chclr_offset should be (0x220 - 0x20) instead of 0x220.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

681e1b3e
(ARM: mach-shmobile: sh73a0 DMA Engine support for SY-DMAC)
adds SY-DMAC, but it is 218, not 318

This patch is based on v2.0 manual
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

On the error condition clk_get() returns ERR_PTR().
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This solves a section mismatch warning. I hadn't noticed this before,
because my compiler was inlining tegra_cpu_reset_handler_enable() inside
tegra_cpu_reset_handler_init(), which is already __init, but I switched
compilers and it stopped doing that.

Cc: <stable@kernel.org> # v3.4
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

This reverts commit d509835e. That commit
breaks support for the generic pass-through mode in the driver for formats,
not natively supported by it. Besides due to a merge conflict it also breaks
driver compilation:

drivers/media/video/mx2_camera.c: In function 'mx2_camera_set_bus_param':
drivers/media/video/mx2_camera.c:937: error: 'pixfmt' undeclared (first use in this function)
drivers/media/video/mx2_camera.c:937: error: (Each undeclared identifier is reported only once
drivers/media/video/mx2_camera.c:937: error: for each function it appears in.)
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Commit a5302572 (OMAP: Add debugfs
node to show the summary of all clocks) introduced clock summary,
however, we are interested in seeing snapshot of the clock state, not
in dynamically changing clock configurations as the data provided by
clock summary will then be useless for debugging configuration
issues. So, hold the common lock when dumping the clock summary.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NTodd Poynor <toddpoynor@google.com>
[nm@ti.com: added commit message]
Signed-off-by: NNishanth Menon <nm@ti.com>
[paul@pwsan.com: minor edits to commit message]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

v3.5-rc1 fails to build when DT and iconnect is enabled because of
this now none existant include file.

Also remove the other two SPI include files, which are not needed
with the move to DT.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Acked-by: NArnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

When the ethernet driver was built as a module, it would lock the
machine when loaded. At boot the ethernet clks are unused, so get
turned off.  Later, when the module is loaded, the probe function
would access the hardware before the clock was restarted, and the
machine would lock. It has also been determined that when the clk is
turned off, the interface forgets its MAC address, which for most
systems, is set by the boot loader.

When the machine setup file creates a platform device for the
interface, prepare and enable the clock for the interface. This will
ensure it is not turned off. However, if the setup file only
instantiates one platform device, the other will have its clk
disabled, thus maybe saving a little power.
Report-by: NSimon Baatz <gmbnomis@gmail.com>
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NSimon Baatz <gmbnomis@gmail.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

With commit 4d5fc58d (ARM: remove bunch of now unused
mach/io.h files), the I/O space setup was completely broken on
versatile. This patch fixes that and prepares for further
I/O space clean-up.

I/O space handling on the versatile platform is currently
broken in multiple ways. Most importantly, the ports do
not get mapped into the virtual address space at all.

Also, there is some amount of confusion between PCI I/O
space and other statically mapped MMIO registers in the
platform code:

* The __io_address() macro that is used to access the
  platform register maps to the same __io macro that gets
  used for I/O space.

* The IO_SPACE_LIMIT is set to a value that is much larger
  than the total available space.

* The I/O resource of the PCI bus is set to the physical
  address of the mapping, which is way outside of the
  actual I/O space limit as well as the address range that
  gets decoded by traditional PCI cards.

* No attempt is made to stay outside of the ISA port range
  that some device drivers try access.

* No resource gets requested as a child of ioport_resource,
  but an IORESOURCE_IO type mapping gets requested
  as a child of iomem_resource.

This patch attempts to correct all of the above. This makes
it possible to use virtio-pci based virtual devices as well
as actual PCI cards including those with legacy ISA port
ranges like VGA.

Some of the issues seem to be duplicated on other platforms.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
[rob: update to 3.5-rc2 and io.h cleanup related changes]
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Tested-by: NRobert Schwebel <r.schwebel@pengutronix.de>
Signed-off-by: NOlof Johansson <olof@lixom.net>