ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5

The cam_mclk clock is generated through the following clocks chain:

dpll4 -> dpll4_m5 -> dpll4_m5x2 -> cam_mclk

As dpll4_m5 and dpll4_m5x2 do not driver any clock other than cam_mclk,
back-propagate the cam_clk rate changes up to dpll4_m5.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Mike Turquette <mturquette@linaro.org>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Tested-by: Sakari Ailus <sakari.ailus@iki.fi>
omap3isp: Set cam_mclk rate directly

Now that the cam_mclk rate changes are back-propagated to dpll4_m5_ck we
can set the cam_mclk rate directly instead of manually setting the rate
of the parent clock.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Mike Turquette <mturquette@linaro.org>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Tested-by: Sakari Ailus <sakari.ailus@iki.fi>
Merge remote-tracking branch 'arm-soc/irqchip/gic-vic-move' into kvm-arm/vgic
ARM: OMAP2+: dpll: am335x - avoid freqsel

am335x does not have freqsel, avoid it.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP2+: clock data: add DEFINE_STRUCT_CLK_FLAGS helper

DEFINE_STRUCT_CLK does not have the capability to set flags, define
DEFINE_STRUCT_CLK_FLAGS to handle flags. This is needed to add
SET_RATE_PARENT flag in statically defined lcd clock in am335x.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP AM33XX: clock data: SET_RATE_PARENT in lcd path

LCDC clock node is a one that does not have set rate capability. It
just passes on the rate that is sent downstream by it's parent. While
lcdc clock parent and it's grand parent - dpll_disp_m2_ck and
dpll_disp_ck has the capability to configure rate.

And the default rates provided by LCDC clock's ancestors are not
sufficient to obtain pixel clock for current LCDC use cases, hence
currently display would not work on AM335x SoC's (with driver
modifications in platfrom independent way).

Hence inform clock framework to propogate set rate for LCDC clock as
well as it's parent - dpll_disp_m2_ck. With this change, set rate on
LCDC clock would get propogated till dpll_disp_ck via dpll_disp_m2_ck,
hence allowing the driver (same driver is used in DaVinci too) to set
rates using LCDC clock without worrying about platform dependent clock
details.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP2+: AM33xx: Add SoC specific restart hook

Add restart hook so that DTS based AM33xx builds can restart
the platform.

Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jean-Sebastien A. Beaudry <jsabeaudry@handyem.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP2+: Get rid of custom OMAP_32K_TIMER_HZ

The timekeeping doesn't depend on HZ value in presence of fine grained
clocksource and hence there should not be any time drift because of HZ
value which was chosen to be divisor of 32768.

OMAP has been using HZ = 128 value to avoid any time drift issues
because of 32768 HZ clock. But with various measurements performed
with HZ = 100, no time drift is observed and it also proves the
point about HZ not having impact on time keeping on OMAP.

Very informative thread on this topic is here:
	https://lkml.org/lkml/2013/1/29/435

Special thanks to John Stulz, Arnd Bergmann and Russell King for their
valuable suggestions.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP2: AM33XX: id: Add support for AM335x PG2.0

Add support for chip id recognition of AM335x PG2.0 silicon. By default
omap3xxx_check_revision() recognizes PG1.0, which is extended by adding
PG2.0 support

Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: at91/DT: remove atmel,use-dma-* from 9x5 and 9n12 USART nodes

Fix the use of USART on both at91sam9x5 and at91sam9n12. In DTS, the
atmel,use-dma-[rx|tx] property is present but a DMA channel cannot be used.
Indeed the connexion between the DMA engine and the slave is not implemented
yet in Device Tree.
Note however that this property is also used for PDC (private DMA) on older
SoCs. This is why the driver alone cannot determine the validity of this
property.

Reported-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org> [3.8+]
ARM: OMAP2xxx: PM: enter WFI via inline asm if CORE stays active

There shouldn't be any need to jump to SRAM code if the OMAP CORE
clockdomain (and consequently the SDRAM controller and CORE PLL) stays
active during MPU WFI.  The SRAM code should only be needed when the RAM
enters self-refresh.  So in the case where CORE stays active, just call
WFI directly from the mach-omap2/pm24xx.c code.  This removes some
unnecessary SRAM code.

This second version replaces the inline WFI with the corresponding
coprocessor register call, using tlbflush.h as an example.  This is
because the assembler doesn't recognize WFI as a valid ARMv6
instruction.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
ARM: OMAP2+: hwmod: add support for blocking WFI when a device is active

Apparently, on some OMAPs, the MPU can't be allowed to enter WFI while
certain peripherals are active.  It's not clear why, and it's likely
that there is simply some other bug in the driver or integration code.
But since the likelihood that anyone will have the time to track these
problems down in the future seems quite small, we'll provide a
flag, HWMOD_BLOCK_WFI, to mark these issues in the hwmod data.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP2420: hwmod data/PM: use hwmod to block WFI when I2C active

Use the HWMOD_BLOCK_WFI flag in the hwmod data to prevent the MPU from
entering WFI when the I2C devices are active.  No idea why this is needed;
this could certainly bear further investigation if anyone is interested.
The objective here is to remove some custom code from the OMAP24xx PM
code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active

According to Mark Greer, on OMAP AM3517/3505 chips, the EMAC is unable
to wake the ARM up from WFI:

    http://www.spinics.net/lists/arm-kernel/msg174734.html

Further troubleshooting was unable to narrow the problem down.  So we
don't have much choice other than to block WFI when the EMAC is active
with the HWMOD_BLOCK_WFI flag.

Based on Mark's original patch.  We're removing the omap_device-based
pm_lats code, so a different approach was needed.

This third version contains some corrections thanks to Mark's review.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Acked-by: Mark A. Greer <mgreer@animalcreek.com>
ARM: OMAP4: PM: Warn users about usage of older bootloaders

OMAP4 CHIP level PM works only with newer bootloaders. The
dependency on the bootloader comes from the fact that the
kernel is missing reset and initialization code for some
devices.

While the right thing to do is to add reset and init code in
the kernel, for some co-processor IP blocks like DSP and IVA
it means downloading firmware into each one of them to execute
idle instructions.

While a feasible solution is worked upon on how such IP blocks
can be better handled in the kernel, in the interim, to avoid
any further frustration to users testing PM on OMAP4 and finding
it broken, warn them about the bootloader being a possible
cause.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: R Sricharan <r.sricharan@ti.com>
[paul@pwsan.com: tweaked warning messages and comments slightly]
Acked-by: Kevin Hilman <khilman@linaro.org>
[paul@pwsan.com: fixed checkpatch warning]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP2+: AM33XX: CM: Get rid of unnecessary header inclusions

cm33xx.h unnecessarily includes a lot of header files.
Get rid of these and directly include "iomap.h" which
is needed to keep things compiling.

Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files

This is necessary to ensure that macros declared here can
be reused from assembly files.

Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP2+: AM33XX: hwmod: Register OCMC RAM hwmod

OCMC RAM lies in the PER power domain and this memory
support retention.

Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags

Third Party Transfer Controller (TPTC0) needs to be idled and
put to standby under SW control. Add the appropriate flags in
the TPTC0 hwmod entry.

Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP2+: AM33XX: hwmod: Fixup cpgmac0 hwmod entry

The current HWMOD code expects the memory region with
the IP's SYSCONFIG register to be marked with ADDR_TYPE_RT
flag.

CPGMAC0 hwmod entry specifies two memory regions and marks
both with the flag ADDR_TYPE_RT although only the 2nd region
has the SYSCONFIG register. This leads to the HWMOD code
accessing the wrong memory address for idle and standby
operations. Fix this by removing the ADDR_TYPE_RT flag from
the 1st memory region in CPGMAC0 hwmod entry.

Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>