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>

omap_hsmmc only supports one slot. So slot id is always zero, and
slot id was never used in the callbacks anyway
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

omap_hsmmc supports only one slot per controller, see OMAP_MMC_MAX_SLOTS.
This unnecessary indirection leads to confusion in the omap_hsmmc driver.
For example the card_detect callback is not installed by platform code
but from the driver probe function. So it should be a field of
omap_hsmmc_host. But since it is declared under the platform slot while
the drivers struct omap_hsmmc_host has no slot abstraction, this looks
like a bug, especially when not familiar that this driver only supports
1 slot anyway.
Either we should add a slot abstraction to omap_hsmmc_host or remove
it from the platform data struct. Removed since slot multiplexing is
an un-implemented feature
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

trigger of this callback has been removed in 0a82e06eAcked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

these fields are never read, probably an unimplemented feature
or superseded by pm_runtime
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

platform data is built from omap2_hsmmc_info, remove all fields that
are never set in omap_hsmmc_info, hence never copied to platform data.
Note that the omap_hsmmc driver is not affected by this patch those
fields were completely unused.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

- omap mmc driver supports multiplexing, omap_mmc_hs doesn't
this leads to one of the major confusions in the omap_hsmmc driver

- platform data should be read-only for the driver
most callbacks are not set by the omap3 platform init code while still
required. So they are set from the driver probe function, which is against
the paradigm that platform-data should not be modified by the driver
typical examples are card_detect, read_only callbacks

un-bundling by searching for driver name \"omap_hsmmc in the
arch/arm folder. omap_hsmmc_platform_data is not initialized directly,
but from omap2_hsmmc_info, which is defined in a separate header file
not touched by this patch

hwmod includes platform headers to declare features of the platform. All
the declared features are prefixed OMAP_HSMMC. There is no need to
include platform header from hwmod other except for feature defines
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Only a few files really need that platform header. When later splitting
omap_mmc_platform_data into omap_mmc and omap_mmc_hs, those files
declaring an hs mmc platform data will have to change the platform
include, which is a good sanity check.
Also removing omap242x_init_mmc, which is not used anywhere, checked
with grep.
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Remove ADS7846 touchscreen pdata quirk for CM-T3x CoMs
Signed-off-by: NDmitry Lifshitz <lifshitz@compulab.co.il>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch adds hwmod support for ADC on AM43xx. Since clockdomain
and offsets of adc_tsc are different from AM33xx, ADC data has been
directly added to AM43xx hwmod file.
Signed-off-by: NVignesh R <vigneshr@ti.com>
[paul@pwsan.com: fixed spelling of "Anolog"; converted spaces to tabs]
Signed-off-by: NPaul Walmsley <paul@pwsan.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>

We had constrainted hwmod entries to entries in dts which were present
only for default mapped interrupts, the ones such as UARTs > 6 which
needed IRQ crossbar configured were never added to hwmod database.

Add them now that IRQ crossbar is functional

Without this, enabling UARTs7 to 10 in dts results in the following crash:
[    1.893829] omap_uart 48420000.serial: _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info
[    1.903381] Unhandled fault: imprecise external abort (0x1406) at 0x00000000
[    1.903381] ------------[ cut here ]------------
[    1.903381] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x2ac/0x32c()
[    1.903411] 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER2_P3 (Read): Data Access in User mode during Functional access
[    1.903411] Modules linked in:
[    1.903411] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W      3.18.0-rc1-dirty #3
[    1.903442] [<c0015270>] (unwind_backtrace) from [<c00119b4>] (show_stack+0x10/0x14)
[    1.903442] [<c00119b4>] (show_stack) from [<c05e4afc>] (dump_stack+0x78/0x94)
[    1.903472] [<c05e4afc>] (dump_stack) from [<c003fed0>] (warn_slowpath_common+0x6c/0x8c)
[    1.903472] [<c003fed0>] (warn_slowpath_common) from [<c003ff84>] (warn_slowpath_fmt+0x30/0x40)
[    1.903472] [<c003ff84>] (warn_slowpath_fmt) from [<c0333bfc>] (l3_interrupt_handler+0x2ac/0x32c)
[    1.903503] [<c0333bfc>] (l3_interrupt_handler) from [<c008d6f8>] (handle_irq_event_percpu+0x60/0x230)
[    1.903503] [<c008d6f8>] (handle_irq_event_percpu) from [<c008d904>] (handle_irq_event+0x3c/0x5c)
[    1.903503] [<c008d904>] (handle_irq_event) from [<c00903b0>] (handle_fasteoi_irq+0xc4/0x190)
[    1.903503] [<c00903b0>] (handle_fasteoi_irq) from [<c008d01c>] (generic_handle_irq+0x20/0x30)
[    1.903533] [<c008d01c>] (generic_handle_irq) from [<c008d114>] (__handle_domain_irq+0x64/0xb8)
[    1.903533] [<c008d114>] (__handle_domain_irq) from [<c00086e4>] (gic_handle_irq+0x20/0x60)
[    1.903533] [<c00086e4>] (gic_handle_irq) from [<c05eb124>] (__irq_svc+0x44/0x5c)
[    1.903533] Exception stack(0xc08d1f60 to 0xc08d1fa8)
[    1.903564] 1f60: 00000001 00000001 00000000 c08dc930 c08d0000 00000000 00000000 00000000
[    1.903564] 1f80: ffffffed c0978028 c08d89dc c08d8978 00000000 c08d1fa8 c0083fc0 c000f160
[    1.903564] 1fa0: 20000013 ffffffff
[    1.903564] [<c05eb124>] (__irq_svc) from [<c000f160>] (arch_cpu_idle+0x20/0x3c)
[    1.903594] [<c000f160>] (arch_cpu_idle) from [<c0077c54>] (cpu_startup_entry+0x198/0x338)
[    1.903594] [<c0077c54>] (cpu_startup_entry) from [<c0869be0>] (start_kernel+0x358/0x3c4)
[    1.903594] [<c0869be0>] (start_kernel) from [<80008074>] (0x80008074)
[    1.903594] ---[ end trace 293fc95d463cff71 ]---
[    2.117553] Internal error: : 1406 [#1] SMP ARM
[    2.122314] Modules linked in:
[    2.125518] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W      3.18.0-rc1-dirty #3
[    2.133850] task: ed868b80 ti: ed86a000 task.ti: ed86a000
[    2.139526] PC is at serial_omap_probe+0x2fc/0x514
[    2.144561] LR is at trace_hardirqs_on_caller+0xec/0x1c4
[    2.150146] pc : [<c038f0f0>]    lr : [<c0083fc0>]    psr: 40000013
[    2.150146] sp : ed86be18  ip : ed9bb57c  fp : f005e000
[    2.162231] r10: 0000012a  r9 : ed9b4f80  r8 : edc5bdcd
[    2.167724] r7 : edc58810  r6 : ed9bb400  r5 : ed9bb410  r4 : edc5bc10
[    2.174560] r3 : 00000000  r2 : 00000000  r1 : 00000014  r0 : ffffffed
[    2.181427] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    2.189117] Control: 10c5387d  Table: 8000406a  DAC: 00000015
[    2.195159] Process swapper/0 (pid: 1, stack limit = 0xed86a248)
[    2.201477] Stack: (0xed86be18 to 0xed86c000)
[    2.206054] be00:                                                       ed9ba2d0 00000000
[    2.214660] be20: edc50150 00000001 c08cba58 00000000 00000000 ed9bb410 ffffffed c09481d8
[    2.223236] be40: 00000000 c09481d8 c08cba58 00000000 00000000 c039bcfc c1170958 ed9bb410
[    2.231842] be60: ed9bb444 c039a6f4 00000000 ed9bb410 c09481d8 ed9bb444 00000000 c08dc698
[    2.240447] be80: edc4a100 c039a8b0 c09481d8 c039a81c 00000000 c0399060 ed8afaa8 ed92c110
[    2.249053] bea0: c09481d8 edc482c0 c0949308 c0399ee0 c077f80c c09481d8 ed86a000 c09481d8
[    2.257659] bec0: ed86a000 c08dc698 00000000 c039b088 00000000 00000000 ed86a000 c08a1924
[    2.266235] bee0: c08a1904 c00089c4 00000000 00000000 00000000 00000000 60000093 00000000
[    2.274841] bf00: 00000004 00000000 ed868b80 00000004 00000000 60000053 00000000 00000001
[    2.283447] bf20: 00000000 c0083ea8 00000001 ed86a000 c08334bc ef7fc307 000000b2 c0059358
[    2.292053] bf40: c07e176c c083299c 00000006 00000006 c08cb588 c08b69cc 00000006 c08b69ac
[    2.300659] bf60: c097a280 000000b2 c08cba58 c0869588 00000000 c0869e04 00000006 00000006
[    2.309234] bf80: c0869588 00000000 00000000 c05dfd7c 00000000 00000000 00000000 00000000
[    2.317840] bfa0: 00000000 c05dfd84 00000000 c000e668 00000000 00000000 00000000 00000000
[    2.326446] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.335052] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 020405d0 00090c40
[    2.343658] [<c038f0f0>] (serial_omap_probe) from [<c039bcfc>] (platform_drv_probe+0x48/0x98)
[    2.352630] [<c039bcfc>] (platform_drv_probe) from [<c039a6f4>] (driver_probe_device+0x10c/0x234)
[    2.361968] [<c039a6f4>] (driver_probe_device) from [<c039a8b0>] (__driver_attach+0x94/0x98)
[    2.370819] [<c039a8b0>] (__driver_attach) from [<c0399060>] (bus_for_each_dev+0x54/0x88)
[    2.379425] [<c0399060>] (bus_for_each_dev) from [<c0399ee0>] (bus_add_driver+0xdc/0x1d4)
[    2.388031] [<c0399ee0>] (bus_add_driver) from [<c039b088>] (driver_register+0x78/0xf4)
[    2.396453] [<c039b088>] (driver_register) from [<c08a1924>] (serial_omap_init+0x20/0x40)
[    2.405059] [<c08a1924>] (serial_omap_init) from [<c00089c4>] (do_one_initcall+0x80/0x1cc)
[    2.413757] [<c00089c4>] (do_one_initcall) from [<c0869e04>] (kernel_init_freeable+0x1b8/0x28c)
[    2.422912] [<c0869e04>] (kernel_init_freeable) from [<c05dfd84>] (kernel_init+0x8/0xe4)
[    2.431396] [<c05dfd84>] (kernel_init) from [<c000e668>] (ret_from_fork+0x14/0x2c)
[    2.439361] Code: e1b02f23 020320f0 0203300f 01a02222 (0a000021)
[    2.445770] ---[ end trace 293fc95d463cff72 ]---
[    2.450683] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    2.450683]
[    2.460296] CPU0: stopping
[    2.463134] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G      D W      3.18.0-rc1-dirty #3
[    2.471405] [<c0015270>] (unwind_backtrace) from [<c00119b4>] (show_stack+0x10/0x14)
[    2.479522] [<c00119b4>] (show_stack) from [<c05e4afc>] (dump_stack+0x78/0x94)
[    2.487060] [<c05e4afc>] (dump_stack) from [<c001394c>] (handle_IPI+0x190/0x264)
[    2.494781] [<c001394c>] (handle_IPI) from [<c000871c>] (gic_handle_irq+0x58/0x60)
[    2.502716] [<c000871c>] (gic_handle_irq) from [<c05eb124>] (__irq_svc+0x44/0x5c)
[    2.510528] Exception stack(0xc08d1f60 to 0xc08d1fa8)
[    2.515808] 1f60: c000f15c 00000000 00000000 00000000 c08d0000 00000000 00000000 00000000
[    2.524353] 1f80: ffffffed c0978028 c08d89dc c08d8978 00000000 c08d1fa8 c000f15c c000f160
[    2.532897] 1fa0: 60000013 ffffffff
[    2.536529] [<c05eb124>] (__irq_svc) from [<c000f160>] (arch_cpu_idle+0x20/0x3c)
[    2.544281] [<c000f160>] (arch_cpu_idle) from [<c0077c54>] (cpu_startup_entry+0x198/0x338)
[    2.552917] [<c0077c54>] (cpu_startup_entry) from [<c0869be0>] (start_kernel+0x358/0x3c4)
[    2.561462] [<c0869be0>] (start_kernel) from [<80008074>] (0x80008074)
[    2.568298] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[
Reported-by: NFranklin Cooper Jr. <fcooper@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NAmbresh K <ambresh@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

RFBI iclk was set to point to hacky "dss_fck", which will be removed.
Instead use "l3_div_ck", which is the proper clock for this. "l3_div_ck"
is the parent of "dss_fck", so the clock rate is the same as previously.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit.taneja@gmail.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Instead of using a hacky "dss_fck" clock (which toggles the MODULEMODE
bit) as DSS L3 interface clock, set the .modulemode field in the
omap44xx_dss_hwmod. This works now that the DSS core hwmod is enabled
during DSS submodule resets.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit.taneja@gmail.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Set DSS core hwmod as the parent for all the DSS submodules.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit.taneja@gmail.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Set DSS core hwmod as the parent for all the DSS submodules.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit.taneja@gmail.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add parent_hwmod pointer to omap_hwmod. This can be set to point to a
"parent" hwmod that needs to be enabled for the "child" hwmod to work.

This is used at hwmod setup time: when doing the initial setup and
reset, first enable the parent hwmod, and after setup and reset is done,
restore the parent hwmod to postsetup_state.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit.taneja@gmail.com>
[paul@pwsan.com: add kerneldoc documentation for parent_hwmod; note that it
 is a temporary workaround]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

ml->node and sl->node are currently initialized
by means of INIT_LIST_HEAD(). That initialiation
is followed by a list_add() call.

Looking at what both these functions do we will have:

	ml->node.next = &ml->node;
	ml->node.prev = &ml->node;
	oi->master->master_ports.next.prev = &ml->node;
	ml->node.next = &oi->master->master_ports.next;
	ml->node.prev = &oi->master->master_ports;
	oi->master->master_ports.next = &ml->node;

from this, it's clear that both INIT_LIST_HEAD() calls
are unnecessary and can be safely removed.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Currently, DPLLs are hiding the gory details of switching parent
within set_rate, which confuses the common clock code and is wrong.
Fixed by applying the new determine_rate() and set_rate_and_parent()
functionality to any clock-ops previously using the broken approach.
This patch also removes the broken legacy code.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Expand the support of omap4 per-dpll to provide set_rate_and_parent.
This is required for proper behavior of clk_change_rate with
determine_rate support.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Similarly to OMAP3 noncore DPLL, the implementation of this DPLL clock
type is wrong. This patch adds basic functionality for determine_rate
for this clock type which will be taken into use in the patches following
later.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Currently, DPLL code hides the re-parenting within its internals, which
is wrong. This needs to be exposed to the common clock code via
determine_rate and set_rate_and_parent APIs. This patch adds support
for these, which will be taken into use in the following patches.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

DPLL4 can't be reprogrammed on OMAP3430 ES1.0 due to hardware limitation.
Currently, the code does runtime omap_rev() check to see the chip it is
being executed on, instead, change this to use clk_features flags.
This avoids need for runtime omap_rev() checks.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The only place where the time is invalid is when the ACPI_CSTATE_FFH entry
method is not set. Otherwise for all the drivers, the time can be correctly
measured.

Instead of duplicating the CPUIDLE_FLAG_TIME_VALID flag in all the drivers
for all the states, just invert the logic by replacing it by the flag
CPUIDLE_FLAG_TIME_INVALID, hence we can set this flag only for the acpi idle
driver, remove the former flag from all the drivers and invert the logic with
this flag in the different governor.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add btwilink device for IGEPv2 Rev. F and IGEP COM MODULE Rev. G.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@iseebcn.com>
Acked-by: NJavier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

CPU logic power state is never programmed in either the initialization
or the suspend/resume logic, instead, we depend on mpuss to program this
properly. However, this leaves CPU logic power state indeterminate and
most probably in reset configuration (If bootloader or other similar
software have'nt monkeyed with the register). This can make powerstate=
RET be either programmed for CSWR (logic=ret) or OSWR(logic = OFF) and
in OSWR, there can be context loss when the code does not expect it.

To prevent all these confusions, just support clearly ON, INA, CSWR,
OFF which is the intent of the existing code by explicitly programming
logic state.

NOTE: since this is a hot path (using in cpuidle), the exit path just
programs powerstate (logic state is immaterial when powerstate is ON).

Without doing this, we end up with lockups when CPUs enter OSWR and
multiple blocks loose context, when we expect them to hit CSWR.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

As we add more static dependency mapping for various errata, the logic
gets clunkier. Since it is a simple lookup and map logic, centralize the
same and provide the mapping as  a simple list.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 705814b5 ("ARM: OMAP4+: PM: Consolidate OMAP4 PM code to
re-use it for OMAP5")

Moved logic generic for OMAP5+ as part of the init routine by
introducing omap4_pm_init. However, the patch left the powerdomain
initial setup, an unused omap4430 es1.0 check and a spurious log
"Power Management for TI OMAP4." in the original code.

Remove the duplicate code which is already present in omap4_pm_init from
omap4_init_static_deps.

As part of this change, also move the u-boot version print out of the
static dependency function to the omap4_pm_init function.

Fixes: 705814b5 ("ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5")
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

These fields were added by:
commit 9574f36f
    OMAP/serial: Add support for driving a GPIO as DTR.

but not removed by

commit 985bfd54
    tty: serial: omap: remove some dead code

which reverted most of that commit.
Time to revert the rest.
Signed-off-by: NNeilBrown <neilb@suse.de>
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>

This patch remove unnecessary KERN_INFO and KERN_ERR from omap_phy_internal.c.
Add pr_fmt.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Omap4 and later have been booting in device tree only
mode for quite some time now. This initcall is no longer
needed. Note that omap3 uses a different driver omap_l3_smx,
and the initcall for that one is still needed until omap3
boots in device tree only mode.
Signed-off-by: NTony Lindgren <tony@atomide.com>

When booting omap3 in device tree mode, we're currently getting
the following errors:

omap_l3_smx omap_l3_smx.0: couldn't request debug irq
omap_l3_smx: probe of omap_l3_smx.0 failed with error -22

This is because we don't have handling in the driver for the
compatible property and instead assume platform data being
passed.

Note that this binding is already documented, and implemented
for the related omap_l3_noc driver for omap4 and later. Looks
like the binding somehow never got never implemented for this
omap_l3_smx driver though.

Let's also remove __exit_p to allow binding and unbinding
of the driver while at it.
Reported-by: NPavel Machek <pavel@ucw.cz>
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This board seems to be in use only for few automated
boot test system and has been booting in device tree
only mode for quite some time now.

So let's drop the board file for it.
Signed-off-by: NTony Lindgren <tony@atomide.com>

The 81xx support is known to be broken for quite some
time now because of missing patches. And it should be
using device tree based booting now anyways.

So let's just drop the board file for it.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This code was only used by 2430sdp, 3430sdp, and n900 development
boards.

The 2430sdp is already device tree only, and all the users of the
3430sdp and n900 development boards are already booting in device
tree mode, so we can drop the legacy smc91x support.
Acked-by: NRoger Quadros <rogerq@ti.com>
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>