Merge branch 'master' into davinci-reset

Add the platform specific callback to control LCD panel and
backlight power.
Signed-off-by: Chaithrika U S <chaithrika@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

When programming the DMA engine, the next pointers must be
programmed with physical address as seen from the DMA master
address space. This address may be different from physical
address of the buffer RAM area. This patch abstracts the
buffer address translation logic.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

On certain SOCs, the EMAC controller is interfaced with a wrapper logic
for handling interrupts. This  patch implements a platform
specific hook to cater to platforms that require custom interrupt
handling logic
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

The davinci EMAC peripheral is also available on other TI
platforms -notably TI AM3517 SoC. This patch modifies the
config option and the platform structure header files so that
the driver can be reused on non-davinci platforms as well.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

This patch initializes the platform data to enable 4-bit
ecc support on DA850/OMAP-L138.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

On DA850/OMAP-L138, NOR flash partition was starting from offset
ZERO erasing the UBL and u-boot when the complete NOR is erased.
This patch moves the start of the partition to 512K, after the
bootloaders and u-boot env variables.

This patch also creates a new partition on NOR Flash to store
Linux kernel image.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Move /proc/davinci_clocks to /sys/kernel/debug/davinci_clocks
(debugfs).

debugfs is more suited for this since the clock dump is
debug information.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

This patch modifies clock dump to take care of
clock tress rooted at multiple oscillators.
Current code assumes the entire tree is rooted
on a single oscillator. When using off-chip
clock synthesizers, some of the clocks can
be obtained from a different on-board oscillator.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Currently, the spinlock in DaVinci clock framework is being
used to:

1) Protect clock structure variables usecount and rate against
concurrent modification.

2) Protect against simultaneous PSC enables/disables ie.
serialize davinci_psc_config().

3) Serialize clk_set_rate():
	i.	Prevent simultaneous setting of clock rates
	ii.	Ensure clock list remains sane during rate
		propagation (also in clk_set_parent).

Remove the spinlock usage in clock framework by:

1) Making clock rate and usecount as atomic variables.

2) Making davinci_psc_config() protect itself instead of
relying on serialization by caller.

3) (i) Allowing the clk->set_rate to serialize itself. There
should be no need to serialize all clock rate settings.
Currently the only user of rate setting is cpufreq driver on
DA850. cpufreq naturally serializes the calls to set CPU rate.
Also, there appears no need to lock IRQs during CPU rate
transtitions. If required, IRQs can be locked in the actual
set_rate function.

3) (ii) Use the mutex already in place for serialzing clock list
manipulation for serializing clock rate propagation as well.

Apart from the general benefit of reducing locking granurlarity,
the main motivation behind this change is to enable usage of
clock framework for off-chip clock synthesizers. One such
synthesizer, CDCE949, is present on DM6467 EVM. Access to the
synthesizer happens through I2C bus - accessing which can lead to
CPU sleep. Having IRQs locked in clk_set_rate prevents the
clk->set_rate function from sleeping.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Implement frame buffer blank operation feature for DA8xx/OMAP-L1xx
driver.
Signed-off-by: Chaithrika U S <chaithrika@ti.com>

Suspend/resume support DA8xx/OMAP-L1xx frame buffer driver.
This feature has been tested on DA850/OMAP-L138 EVM. For the purpose
of testing, the patch series[1] which adds suspend support for
DA850/OMAP-L138 SoC was applied.

[1] http://patchwork.kernel.org/patch/60260/Signed-off-by: Chaithrika U S <chaithrika@ti.com>

Add a helper function to enable raster. Also add one member in the
private data structure to track the current blank status, another
function pointer which takes in the platform specific callback function
to control panel power.

These updates will help in adding suspend/resume and frame buffer blank
operation features.
Signed-off-by: Chaithrika U S <chaithrika@ti.com>

Add cpufreq support for DA8xx/OMAP-L1xx frame buffer driver
Signed-off-by: Chaithrika U S <chaithrika@ti.com>

The clock divider value can be calculated from the pixel clock
value for the panel. This gives more flexiblity to the driver
to change the divider value on the fly as in the case of cpufreq
feature- support for which will be added shortly.
Signed-off-by: Chaithrika U S <chaithrika@ti.com>

All DaVinci platforms include a DSP or co-processor for
audio/video acceleration.

While creating memory for the DSP/co-processor, system
integrator can end up creating a hole in the memory map
of the sort:

<kernel memory> <hole (memory for DSP)> <kernel memory>

This sort of configuration needs ARCH_HAS_HOLES_MEMORYMODEL
enabled. See further details see this discussion on ARM
linux mailing list:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15262.html

The patch is boot tested on OMAP-L138, DM6446 and DM355 EVMs
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
CC: Sriramakrishnan <srk@ti.com>
CC: Khasim Syed Mohammed <khasim@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

DM6467T (T for Turbo) is a newer and faster DM6467
part from TI. The new part supports 1080p video and
has the ARM running at 495MHz. More SoC information:

http://focus.ti.com/docs/prod/folders/print/tms320dm6467t.html

Spectrum Digital, Inc has a new EVM for this part.
It is _mostly_ same as the older DM6467 EVM except
for a 33MHz crystal input and THS8200 video encoder
for 1080p support.

The meat of this patch is dedicated to initializing
the crystal frequency from EVM board file.

Additional notes:
I did consider some alternative ways to make the crystal
input board specific including - (1) having board code
initialize the crystal frequency using the first member
of soc_info->cpu_clks array (2) introducing a new ref_clk_rate
member in soc_info structure.

But, the current way seems to be the simplest and least
intruding considering that both the clock array and SoC
info structure are actually private to the SoC file. Also
the fact that davinci_common_init() initializes both the
soc_info and clocks in one go.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Currently all the #defines and static variables in the
board-dm646x-evm.c file are located right at the start
of the file because of which the related code is not
together - making reading the code difficult.

This patch moves around the code keeping related code
together.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Leave a comment explaining the constant value of 27Mhz used
in include/mach/timex.h for all DaVinci platforms. Many of
the platforms actually run at 24MHz timer frequency (Eg.
EVMs of DM355, DM365 and OMAP-L1).

The comment also serves as a porting alert.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Create static map for internal SRAM and populate SRAM base
and size in soc_info structure to allow SRAM allocation
functions from arch/arm/mach-davinci/sram.c to work.

On DA850 SRAM is used for suspend-to-RAM implementation
in places where DDR2 cannot be accessed as its clocks are
stopped.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

On omap-l1 devices the PLL registers can be locked from
writes. Currently the cpufreq rate setting code unlocks
PLL0 before the write actually happens. With suspend
support getting added PLL1 registers need be be unlocked
as well.

To facilitate this, unlock both PLLs during the init time
itself.

This also obviates the need to unlock PLL registers for
each CPUFreq transtition.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

When suspend is supported, both cpuidle and suspend code
need to work on DDR2 registers. Instead of mapping the
DDR2 registers twice, do it once outside of cpuidle
driver and let cpuidle driver get the virtual base address
of DDR2 registers.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

psc.h contains register defines for PSC module which
need to be accessed in assembly code which helps the
DA850/OMAP-L138 SoC go to sleep. Shutting down DDR clock
using PSC is a part of the sleep procedure.

Also, the PLL related hardware definitions in clock.h are
needed in assembly code to bypass the DDR2 PLL.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

The motivation behind the change is to use the same
definitions in the assembly code responsible for
suspending the SoC, a part of which is to clock gate
the DDR2 clock.

Note that the assembly code cannot invoke the C function
meant for this. The main reason being that stack in DDR2
cannot be accessed while DDR2 clock is being clock gated.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Move defintions of DDR2 controller registers to memory.h
from cpuidle.c. The motivation behind the change is to be
able to use these defintions in assembly code that puts
DDR2 in self-refresh and enables the SoC to enter suspend
state.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

As suspend support is added, the code supporting
the suspend operation needs to bypass PLLs and
needs to access the same wait time values as the
PLL code in clock.c.

To facilitate this, move the PLL wait times to
clock.h where they can be accessed by suspend code.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

OMAP-L138 adds a second SYSCFG region having useful functionality
like deep sleep, pull up/down control and SATA clock stop.

This patch makes provision for accessing registers from second
SYSCFG region in da8xx code.

Note that OMAP-L137 has a single SYSCFG region.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

On da850, RTC alarm is a wakeup source from deep sleep.
Mark it as a wakeup source after the rtc platform device
is registered.

Without this patch, the rtc-omap driver suspends the RTC
during the suspend sequence and hence it cannot wakeup the
SoC.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

There is nothing special to be done for interrupts
which can wakeup the device from sleep on CP-INTC,
but not having a set_wake implemented prevents use
of common drivers which expect this function to be
implemented for all wakeup interrupt sources.

This patch fixes the issue encountered when using the
omap-rtc driver on DA850. On DA850 the RTC alarm
interrupt is used to wake up the SoC from deep sleep
mode. Without this patch, the disable_irq_wake throws
an unbalanced wake disable warning while resuming
because the previous enable call fails for lack of
set_wake implementation.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

The ARM kernel supports writethrough data cache via the
CONFIG_CPU_DCACHE_WRITETHROUGH option.  However, that
functionality wasn't implemented in the arch/arm/boot/compressed
code.  It is now necessary due to a new ARM926EJS processor
that has an issue with writeback data cache.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>

On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after
setting the 4BITECC_ADD_CALC_START bit in the NAND Flash
control register to 1 and before waiting for the NAND Flash
status register to be equal to 1, 2 or 3, we have to wait
till the ECC HW goes to correction state. Without this wait,
ECC correction calculations will not be proper.

This has been tested on DA830/OMAP-L137, DA850/OMAP-L138,
DM355 and DM365 EVMs.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Acked-by: Sneha Narnakaje <nsnehaprabha@ti.com>

The existing NAND infrastructure allows the default main and
mirror bad block tables to be overridden in nand_default_bbt().
However, the davinci_nand driver does not support this.  So,
add fields to the davinci driver's platform data so platform
code can pass in their own bbt's and make the driver honor
those overrides.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

Add cpufreq support to MMC driver. The clock divider value has to be
modified according to the controller input frequency.
Signed-off-by: Chaithrika U S <chaithrika@ti.com>

Currently DaVinci EDMA driver supports multiple EDMA channel
controller instances. edma_alloc_channel() api returns a 32
bit value which has the channel controller number in MSB and
the EDMA channel number in LSB. The variables which store the
value returned by edma_alloc_channel() have to be 32 bit wide
now.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Acked-by: Vipin Bhandari <vipin.bhandari@ti.com>

This patch adds support for MMC/SD controller driver for all DaVinci family
SoC. This patch supports davinci family SoC's DM6446, DM355, DM365 and
DA830/OMAPL137.

The patch has been tested on DM355 EVM.

The MMCSD controller specifications for DM355 can be found at
http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spruee2cSigned-off-by: Vipin Bhandari <vipin.bhandari@ti.com>
Signed-off-by: Purshotam Kumar <purushotam@ti.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>

The rtc-omap driver currently hardcodes the RTC to be
not capable of wakeup events. On the DA850/OMAP-L138
SoC, the RTC is a wake up source from its "deep sleep"
mode.

Let platform data set the wakeup capability flag instead.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>