Add support for L2 cache controller (PL310) on AM437x SoC.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Get rid of init call to initialize L2 cache.  Instead use the init_early
machine hook. This helps in using the initialization routine across
SoCs without the need of ugly cpu_is_*() checks.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

L2 cache initialization for OMAP4 redundantly sets the cache policy to
Round-Robin. This is not needed since thats the PL310 default anyway.

Removing this reduces the number of platform specific aux control
settings.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Avoid reading directly from the L2 registers in platform code.  The L2
code will have already saved the register values itself into the
l2x0_saved_regs structure, so platform code should just move these
values to where they're required.

This is safe because the L2x0 will have been initialised by an early
initcall, whereas the OMAP4 PM code is initialised late.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Since we now always enable NS access to the unlock registers, this can
be removed from OMAP4.  Remove the NS access bit for the interrupt
registers from OMAP4 as well - nothing in the kernel accesses that yet,
and we can add it in core code when we have the need.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The cache size should already be present in the L2 cache auxiliary
control register: it is part of the integration process to configure
the hardware IP.  Most platforms get this right, yet still many
cargo-cult program, and assume that they always need specifying to
the L2 cache code.  Remove them so we can find out which really need
this.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Now that OMAP2 uses the write_sec method, we don't need to enable the L2
cache in OMAP2 specific code; this can be done via the normal mechanisms
in the L2C code.  Remove the OMAP2 specific code.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

With the write_sec method, we no longer need to override the default
L2C disable method, and we no longer need the L2C set_debug method.
Both of these can be handled via the write_sec method.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Since we now automatically enable early BRESP in core L2C-310 code when
we detect a Cortex-A9, we don't need platforms/SoCs to set this bit
explicitly.  Instead, they should seek to preserve the value of bit 30
in the auxiliary control register.
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We have a mixture of different devices with different register layouts,
but we group all the bits together in an opaque mess.  Split them out
into those which are L2C-310 specific and ones which refer to earlier
devices.  Provide full auxiliary control register definitions.
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Santosh says:
> But we should kill all of that since we long back decided to remove
> ES1.0 related code. The mach-omap code alreasy has removed the ES1.0
> compatibility so feel free to remove any specific ES1.0
> related stuff. That silicon is long dead.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

On my DRA7 system, when the kernel is built in Thumb-2 mode, the secondary CPU
(Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
seems to be because the CPU is in ARM mode once the ROM hands over control to
the kernel.  Switch to Thumb-2 mode if required once the kernel is control of
secondary CPU. On OMAP4 on the other hand, it appears to be in Thumb-2 mode on
entry so this is not required and SMP boot works as is.

Also corrected a spurious '+' and updated copyright information.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Nishanth Menon <nm@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NJoel Fernandes <joelf@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

At least the smc91x driver expects the device to be at 0x300
offset from bus base address. This does not work currently
for GPMC when booted in device tree mode as it attempts to
remap the the allocated GPMC partition to the address
configured by the device tree plus the device offset.

Note that this works just fine when booted with legacy mode.

Let's fix the issue by just ignoring any device specific
offset while remapping. And let's make sure the remap
address confirms to the GPMC 16MB minimum granularity
as listed in the TRM for GPMC_CONFIG7 BASEADDRESS bits.

Otherwise we can get something like this:

omap-gpmc 6e000000.gpmc: cannot remap GPMC CS 1 to 0x01000300

Cc: Pekon Gupta <pekon@ti.com>
Reviewed-by: NJavier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

If gpmc_cs_remap() fails we will get an error because we are calling
release_resource() on an uninitialized resource. Let's fix that by
checking the resource flags. And while at it, let's also make
gpmc_cs_delete_mem() use the res pointer that we already have to
avoid confusion.

Without this patch we can get the following error:

omap-gpmc 6e000000.gpmc: cannot remap GPMC CS 1 to 0x01000300
Unable to handle kernel NULL pointer dereference at virtual address 00000018
...
(gpmc_cs_free+0x94/0xc8)
(gpmc_probe_generic_child+0x178/0x1ec)
(gpmc_probe_dt+0x1bc/0x2cc)
(gpmc_probe+0x250/0x44c)
(platform_drv_probe+0x3c/0x6c)
(really_probe+0x74/0x208)
(driver_probe_device+0x34/0x50)
(bus_for_each_drv+0x60/0x8c)
(device_attach+0x80/0xa4)
(bus_probe_device+0x88/0xb0)
(device_add+0x320/0x450)
(of_platform_device_create_pdata+0x80/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)
(pdata_quirks_init+0x30/0x48)
(customize_machine+0x20/0x48)
(do_one_initcall+0x2c/0x14c)
(do_basic_setup+0x98/0xd8)
(kernel_init_freeable+0x12c/0x1e0)
(kernel_init+0x8/0xf0)
(ret_from_fork+0x14/0x2c)
Code: e1a04000 e59f0070 eb195136 e5942010 (e5923018)

Cc: Pekon Gupta <pekon@ti.com>
Reviewed-by: NJavier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Ntony Lindgren <tony@atomide.com>

Do not try to initialize display for DT boot, since omapdss
is now initialized via Device Tree. Without this patch the
display subsystem does not properly come up.
Signed-off-by: NSebastian Reichel <sre@kernel.org>
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Bug was introduced by commit 'f92d9597: ARM: OMAP2+: hwmod:
Extract no-idle and no-reset info from DT'

There were 2 versions of the patch posted which resulted in the above
commit. While v1 [1] had the bug, v2 [2] had it fixed.
However v1 apparently seemed to have been pulled in by mistake
introducing the bug.

Given of_find_property() does return NULL when the node passed is
NULL, it did not introduce any functional issues as such, just the
fact that the second if check was executed unnecessarily.

[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg94220.html
[2] http://www.spinics.net/lists/linux-omap/msg98490.html

Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Fixes: f92d9597 ("ARM: OMAP2+: hwmod: Extract no-idle and no-reset info from DT")
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

On AM43xx, if a PLL is in bypass at kernel init, the code in
omap2_get_dpll_rate() will not realize this and will try to calculate
the clock rate using the multiplier and the divider, resulting in
errors.

omap2_init_dpll_parent() has similar issue.

Add the missing soc_is_am43xx() check to make the code work on AM43xx.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NSathya Prakash M R <sathyap@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

OMAP3 doesn't contain "l3_init_clkdm" clock domain. Use the
proper clock domains for USB Host and USB TLL modules.

Gets rid of the following warnings during boot
 omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
 omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
Reported-by: NNishanth Menon <nm@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Fixes: de231388 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3")
Cc: Keshava Munegowda <keshava_mgowda@ti.com>
Cc: Partha Basak <parthab@india.ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

There is a solitary write to this register every wakeup from off-mode,
which isn't doing anything, so remove it.

Also note that modifying this register trashes any attempted
voltage scaling configuration and the change probably should
never have gotten merged in the first place.

Cc: Nishanth Menon <nm@ti.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NTero Kristo <t-kristo@ti.com>
[tony@atomide.com: updated comments to describe regression]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Remove pdata quirks for the displays on boards that are now supported
properly with DT.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Export the DMA register information from the SoC specific data, such
that we can access the registers directly in omap-dma.c, mapping the
register region ourselves as well.

Rather than calculating the DMA channel register in its entirety for
each access, we pre-calculate an offset base address for the allocated
DMA channel and then just use the appropriate register offset.
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The omap_system_dma_plat_info structure is only seven words, it's not
worth the expense of kmalloc()'ing backing store for this only to
release it later.  Note that platform_device_add_data() copies the
data anyway.  Clean up the initialisation of this structure - we don't
even need code to initialise most of this structure.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This really needs to be there, because otherwise the plat-omap code can
kfree() this data structure, and then re-use the pointer later.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There's no need for this to be a global variable; move it into the
errata configuration function instead.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We can do much better with this by using a structure to describe each
register, rather than code.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

dma_stride and dma_common_ch_start are only ever initialised to one
known value at initialisation, and are private to each of these files.
There's no point these being variables at all.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The disable_irq_lch method is never actually used, so there's not much
point it existing; remove it.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

CONFIG_PROC_DEVICETREE has been removed from the tree. This commit
removes a dangling select of the config symbol.
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Cc: Paul Bolle <pebolle@tiscali.nl>
Cc: Rob Herring <rob.herring@linaro.org>

As there is no common panel framework in the kernel, we have OMAP
specific panel drivers. However, the DT data should be generic. This
brings the issue that some other platform could use the same panels, and
would need to create a driver with the same 'compatible' string as the
OMAP driver.

In the long run, we have to get a common panel framework. For the time
being, this patch solves the issue:

At early boot time, we go through the DT nodes looking for the panels
the kernel supports for OMAP. For each found node, the 'compatible'
string is prepended with "omapdss,", i.e. "sony,acx565akm" becomes
"omapdss,sony,acx565akm". The OMAP display drivers all have "omapdss,"
at the beginning of their compatible field.

This allows us to have generic DT data, but OMAP specific display
drivers.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

The OMAP display architecture requires a bunch of platform devices which
are not created via .dts (for now). We also need to pass a few function
pointers and the DSS hardware version from the arch code to omapdss
driver.

This patch adds omapdss_init_of() function, called from board-generic at
init time, which handles those tasks.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Use the proper clock name 'usbhost_120m_fck' instead of the
alias 'ehci_logic_fck'

Get rid of the 'ehci_logic_fck' alias from the OMAP3 hwmod data
as well.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Not all revisions have all the clocks so get the necessary clocks
based on hardware revision.

This should avoid un-necessary clk_get failure messages that were
observed earlier.

Also remove the dummy USB host clocks from the OMAP3 clock data.
These are no longer expected by the driver.

Acked-by: Mike Turquette <mturquette@linaro.org> [OMAP3 CLK data]
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The spinlock module's SYSCONFIG register does not support
smart wakeup, so remove this flag from the idle modes in
the spinlock hwmod definition.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Acked-by: NBenoit Cousson <bcousson@baylibre.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if
CONFIG_PM is enabled, else, disabling CONFIG_PM results in build
failure complaining about the following:
arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
:(.text+0x8a70): undefined reference to `pm44xx_errata'

Fixes: c9621844 (ARM: OMAP4: PM: add errata support)
Reported-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.ocm>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

When an interrupt has become active on the INTC it will stay active
until it is acked, even if masked or de-asserted. The
INTC_PENDING_IRQn registers are however updated and since these are
used by omap_intc_handle_irq to determine which interrupt to handle,
it will never see the active interrupt. This will result in a storm of
useless interrupts that is only stopped when another higher priority
interrupt is asserted.

Fix by sending the INTC an acknowledge if we find no interrupts to
handle.

Cc: stable@vger.kernel.org
Signed-off-by: NStefan Sørensen <stefan.sorensen@spectralink.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP5 has the same iommus as OMAP4, so extend the OMAP4
iommu pdata quirks for OMAP5 as well.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

A new MMU hwmod class and data structures are created
to represent the MMUs within the IPU and DSP processor
subsystems in OMAP5. The MMUs in OMAP5 are identical to
those in OMAP4.

Cc: Benoit Cousson <bcousson@baylibre.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The OMAP iommu driver performs the reset management for the
iommu instances in processor sub-systems using the omap_device
API which are currently supplied as platform data ops. Use pdata
quirks to maintain the functionality as the OMAP iommu driver
gets converted to use DT nodes, until the reset portions are
decoupled from omap_hwmod/omap_device into a separate reset
driver.

This patch adds the pdata quirks for the reset management of
iommus within the DSP (OMAP3 & OMAP4) and IPU subsystems (OMAP4).
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The IOMMU DT adaptation support uses the device name instead
of an iommu object name. Fixup the ISP device archdata MMU
name at runtime if using DT-boot. This allows the OMAP3 camera
to be functional in both legacy and DT boots. The iommu object
names should eventually vanish when all the IOMMU users have
been converted to DT nodes.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The IVA MMU is not functional when used through the hwmod and
omap_device layers. Add fixes to clockdomain and hwmod data
to have it functional. The hwmod changes are needed to enable
the clock, and the SWSUP change is needed to wakeup the domain
because the power domain is programmed to be in RET, and there
is no automatic power domain switching to ON.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>