* git://git.infradead.org/mtd-2.6: (63 commits)
mtd: OneNAND: Allow setting of boundary information when built as module
jffs2: leaking jffs2_summary in function jffs2_scan_medium
mtd: nand: Fix memory leak on txx9ndfmc probe failure.
mtd: orion_nand: use burst reads with double word accesses
mtd/nand: s3c6400 support for s3c2410 driver
[MTD] [NAND] S3C2410: Use DIV_ROUND_UP
[MTD] [NAND] S3C2410: Deal with unaligned lengths in S3C2440 buffer read/write
[MTD] [NAND] S3C2410: Allow the machine code to get the BBT table from NAND
[MTD] [NAND] S3C2410: Added a kerneldoc for s3c2410_nand_set
mtd: physmap_of: Add multiple regions and concatenation support
mtd: nand: max_retries off by one in mxc_nand
mtd: nand: s3c2410_nand_setrate(): use correct macros for 2412/2440
mtd: onenand: add bbt_wait & unlock_all as replaceable for some platform
mtd: Flex-OneNAND support
mtd: nand: add OMAP2/OMAP3 NAND driver
mtd: maps: Blackfin async: fix memory leaks in probe/remove funcs
mtd: uclinux: mark local stuff static
mtd: uclinux: do not allow to be built as a module
mtd: uclinux: allow systems to override map addr/size
mtd: blackfin NFC: fix hang when using NAND on BF527-EZKITs
...
Minimal support for the 4-bit ECC engine found on DM355, DM365,
DA830/OMAP-L137, and similar recent DaVinci-family chips.
This is limited to small-page flash for now; there are some page
layout issues for large page chips. Note that most boards using
this engine (like the DM355 EVM) include 2GiB large page chips.
Sanity tested on DM355 EVM after swapping the socketed NAND for
a small-page one.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Provide a generic SRAM allocator using genalloc, and vaguely
modeled after what AVR32 uses. This builds on top of the
static CPU mapping set up in the previous patch, and returns
DMA mappings as requested (if possible).
Compared to its OMAP cousin, there's no current support for
(currently non-existent) DaVinci power management code running
in SRAM; and this has ways to deallocate, instead of being
allocate-only.
The initial user of this should probably be the audio code,
because EDMA from DDR is subject to various dropouts on at
least DM355 and DM6446 chips.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Package on-chip SRAM. It's always accessible from the ARM, so
set up a standardized virtual address mapping into a 128 KiB
area that's reserved for platform use.
In some cases (dm6467) the physical addresses used for EDMA are
not the same as the ones used by the ARM ... so record that info
separately in the SOC data, for chips (unlike the OMAP-L137)
where SRAM may be used with EDMA.
Other blocks of SRAM, such as the ETB buffer or DSP L1/L2 RAM,
may be unused/available on some system. They are ignored here.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Remove remnants of dm6446-specific SRAM allocator, as preparation for
a more generic replacement.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Different SoC have different numbers of pinmux registers and other
resources that overlap with each other. To clean up the code and
eliminate defines that overlap with each other, move the PINMUX
defines to the SoC specific files.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The Timer64p timer has 8 compare registers that can
be used to generate interrupts when the timer value
matches the compare reg's value. They do not disturb
the timer itself. This can be useful when there is
only one timer available for both clock events and
clocksource.
When enabled, the clocksource remains a continuous
32-bit counter but the clock event will no longer
support periodic interrupts. Instead only oneshot
timers will be supported and implemented by setting
the compare register to the current timer value plus
the period that the clock event subsystem is requesting.
Compare registers support is enabled automatically
when the following conditions are met:
1) The same timer is being used for clock events
and clocksource.
2) The timer is the bottom half (32 bits) of the
64-bit timer (hardware limitation).
3) The the compare register offset and irq are
not zero.
Since the timer is always running, there is a hardware
race in timer32_config() between reading the current
timer value, and adding the period to the current
timer value and writing the compare register.
Testing on a da830 evm board with the timer clocked
at 24 MHz and the processor clocked at 300 MHz,
showed the number of counter ticks to do this ranged
from 20-53 (~1-2.2 usecs) but usually around 41 ticks.
This includes some artifacts from collecting the
information. So, the minimum period should be
at least 5 usecs to be safe.
There is also an non-critical lower limit that
the period should be since there is no point in
setting an event that is much shorter than the
time it takes to set the event, and get & handle
the timer interrupt for that event. There can
also be all sorts of delays from activities
occuring elsewhere in the system (including
hardware activitis like cache & TLB management).
These are virtually impossible to quantify so a
minimum period of 50 usecs was chosen. That will
certianly be enough to avoid the actual hardware
race but hopefully not large enough to cause
unreasonably course-grained timers.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Integrate the Common Platform Interrupt Controller (cp_intc)
support into the low-level irq handling for davinci and similar
platforms. Do it such that support for cp_intc and the original
aintc can coexist in the same kernel binary.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Factor out the code to extract that mac address from
i2c eeprom.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The dm644x and dm646x board files have i2c eeprom read and
write routines but they are not used so remove them.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Since most of the emac platform_data is really SoC specific
and not board specific, move it to the SoC-specific files.
Put a pointer to the platform_data in the soc_info structure
so the board-specific code can set some of the platform_data
if it needs to.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Currently, there is one set of platform_device and platform_data
structures for all DaVinci SoCs. The differences in the data
between the various SoCs is handled by davinci_serial_init()
by checking the SoC type. However, as new SoCs appear, this
routine will become more & more cluttered.
To clean up the routine and make it easier to add support for new
SoCs, move the platform_device and platform_data structures into the
SoC-specific code and use the SoC infrastructure to provide access
to the data.
In the process, fix a bug where the wrong irq is used for uart2
of the dm646x.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The current gpio code needs to know the number of
gpio irqs there are and what the bank irq number is.
To determine those values, it checks the SoC type.
It also assumes that the base address and the number
of irqs the interrupt controller uses is fixed.
To clean up the SoC checks and make it support
different base addresses and interrupt controllers,
have the SoC-specific code set those values in
the soc_info structure and have the gpio code
reference them there.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The watchdog code currently hardcodes the base address
of the timer its using. To support new SoCs, make it
support timers at any address. Use the soc_info structure
to do this.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The davinci timer code currently hardcodes the timer register
base addresses, the timer irq numbers, and the timers to use
for clock events and clocksource. This won't work for some
a new SoC so put those values into the soc_info structure
and set them up in the SoC-specific files.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Use the SoC infrastructure to hold the interrupt controller
information (i.e., base address, default priorities,
interrupt controller type, and the number of IRQs).
The interrupt controller base, although initially put
in the soc_info structure's intc_base field, is eventually
put in the global 'davinci_intc_base' so the low-level
interrupt code can access it without a dereference.
These changes enable the SoC default irq priorities to be
put in the SoC-specific files, and the interrupt controller
to be at any base address.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The pinmux register base and setup can be different for different
SoCs so move the pinmux reg base, pinmux table (and its size) to
the SoC infrastructure.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The current code to support the DaVinci Power and Sleep Controller (PSC)
assumes that there is only one controller. This assumption is no longer
valid so expand the support to allow greater than one PSC.
To accomplish this, put the base addresses for the PSCs in the SoC
infrastructure so it can be referenced by the PSC code. This also
requires adding an extra parameter to davinci_psc_config() to specify
the PSC that is to be enabled/disabled.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
All of the davinci SoCs need to call davinci_clk_init() so
put the call in the common init routine.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The Davinci cpu_is_davinci_*() macros use the SoC part number
and variant retrieved from the JTAG ID register to determine the
type of cpu that the kernel is running on. Currently, the code to
read the JTAG ID register assumes that the register is always at
the same base address. This isn't true on some newer SoCs.
To solve this, have the SoC-specific code set the JTAG ID register
base address in soc_info structure and add a 'cpu_id' member to it.
'cpu_id' will be used by the cpu_is_davinci_*() macros to match
the cpu id. Also move the info used to identify the cpu type into
the SoC-specific code to keep all SoC-specific code together.
The common code will read the JTAG ID register, search through
an array of davinci_id structures to identify the cpu type.
Once identified, it will set the 'cpu_id' member of the soc_info
structure to the proper value and the cpu_is_davinci_*() macros
will now work.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Create a structure to encapsulate SoC-specific information.
This will assist in generalizing code so it can be used by
different SoCs that have similar hardware but with minor
differences such as having a different base address.
The idea is that the code for each SoC fills out a structure
with the correct information. The board-specific code then
calls the SoC init routine which in turn will call a common
init routine that makes a copy of the structure, maps in I/O
regions, etc.
After initialization, code can get a pointer to the structure
by calling davinci_get_soc_info(). Eventually, the common
init routine will make a copy of all of the data pointed to
by the structure so the original data can be made __init_data.
That way the data for SoC's that aren't being used won't consume
memory for the entire life of the kernel.
The structure will be extended in subsequent patches but
initially, it holds the map_desc structure for any I/O
regions the SoC/board wants statically mapped.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Add support for DM646x SoC (a.k.a DaVinci HD) and its Evalution
Module (EVM.)
Original support done by Sudhakar Rajashekhara.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
In addition, add board support for the DM355 Evaluation Module (EVM)
and the DM355 Leopard board.
Original DM355 EVM support done by Sandeep Paulraj, with significant
updates and improvements by David Brownell. DM355 Leopord support
done by Koen Kooi.
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Koen Kooi <koen@beagleboard.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Add support for Texas Instuments Common Platform Interrupt Controller
(cp_intc) used on DA830/OMAP-L137.
Signed-off-by: Steve Chen <schen@mvista.com>
Signed-off-by: Mark Greer <mgreer@mvista.com>
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The davinci pre-kernel boot code assumes that all platforms use the
same UART base address for the console. That assumption is not longer
valid with some newer SoCs so determine the console UART base address
from the machine number passed in from bootloader.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch defines debug macros for low-level debugging for Davinci
based platforms
Tested on :
- DM644x DaVinci EVM
- DM646X DaVinciHD EVM
- DM355 EVM
This patch attempts to solve the low-level debug issue in DM646x. The
UART on DM646x SoC allows only 32-bit access. The existing
debug-macro.S uses the macros from debug-8250.S file. This led to
garbage serial out in the case of DM646x.
The inclusion of debug-8250.S does not allow for run time fix for this
issue. There are compile time errors due to multiple definitions of
the macros. Also when building a single image for multiple DaVinci
Platforms, the ifdefs cannot be relied upon.
The solution below does not include the debug-8250.S file and defines
the necessary macros. This solution was arrived at after observing
that word access does not affect the low-level debug messages on
DM644x/DM355.
The other approach to this issue is to use the UART module information
available in the peripheral registers to decide the access
mechanism. But this will have to be done for every access of UART
specifically for DM646x. Also this calls for a modification of the
debug-8250.S file.
Signed-off-by: Chaithrika U S <chaithrika@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This is a build fix, resyncing the DaVinci EVM ASoC board code
with the version in the DaVinci tree. That resync includes
support for the DM355 EVM, although that board isn't yet in
mainline.
(NOTE: also includes a bugfix to the platform_add_resources
call, recently sent by Chaithrika U S <chaithrika@ti.com> but
not yet merged into the DaVinci tree.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Rework DM644x code into SoC specific and board specific parts.
This is also to generalize the structure a bit so it's easier to add
support for new SoCs in the DaVinci family.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Adding IRQ defintions for DaVinci DM355 and default interrupt
priorities for DM355
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Update the DaVinci GPIO code to work better on non-dm6446 parts,
notably the dm355:
- Only handle the number of GPIOs the chip actually has. So
for example on dm6467, GPIO-42 is the last GPIO, and trying
to use GPIO-43 now fails cleanly; or GPIO-72 on dm6446.
- Enable GPIO interrupts on each 16-bit GPIO-irq bank ...
previously, only the first five were enabled, so GPIO-80
and above (on dm355) wouldn't trigger IRQs.
- Use the right IRQ for each GPIO bank. The wrong values were
used for dm355 chips, so GPIO IRQs got routed incorrectly.
- Handle up to four pairs of 16-bit GPIO banks ... previously
only three were handled, so accessing GPIO-96 and up (e.g. on
dm355) would oops.
- Update several comments that were dm6446-specific.
Verified by receiving GPIO-1 (dm9000) and GPIO-5 (msp430) IRQs
on the DM355 EVM.
One thing this doesn't do is handle the way some of the GPIO
numbers on dm6467 are reserved but aren't valid as GPIOs. Some
bitmap logic could fix that if needed.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Original code for 2.6.10 and 2.6.28 series done by Texas Instruments
and MontaVista, but major updates and rework done by Troy Kisky and
David Brownell.
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Add arch-specific ioremap() which uses any existing static mappings in
place of doing a new mapping. From now on, drivers should always use
ioremap() instead of IO_ADDRESS().
In addition, remove the davinci_[read|write]* macros in favor of using
ioremap.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This is a significant rework of the low-level clock, PLL and Power
Sleep Controller (PSC) implementation for the DaVinci family. The
primary goal is to have better modeling if the hardware clocks and
features with the aim of DVFS functionality.
Highlights:
- model PLLs and all PLL-derived clocks
- model parent/child relationships of PLLs and clocks
- convert to new clkdev layer
- view clock frequency and refcount via /proc/davinci_clocks
Special thanks to significant contributions and testing by David
Brownell.
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* git://git.infradead.org/mtd-2.6: (53 commits)
[MTD] struct device - replace bus_id with dev_name(), dev_set_name()
[MTD] [NOR] Fixup for Numonyx M29W128 chips
[MTD] mtdpart: Make ecc_stats more realistic.
powerpc/85xx: TQM8548: Update DTS file for multi-chip support
powerpc: NAND: FSL UPM: document new bindings
[MTD] [NAND] FSL-UPM: Add wait flags to support board/chip specific delays
[MTD] [NAND] FSL-UPM: add multi chip support
[MTD] [NOR] Add device parent info to physmap_of
[MTD] [NAND] Add support for NAND on the Socrates board
[MTD] [NAND] Add support for 4KiB pages.
[MTD] sysfs support should not depend on CONFIG_PROC_FS
[MTD] [NAND] Add parent info for CAFÉ controller
[MTD] support driver model updates
[MTD] driver model updates (part 2)
[MTD] driver model updates
[MTD] [NAND] move gen_nand's probe function to .devinit.text
[MTD] [MAPS] move sa1100 flash's probe function to .devinit.text
[MTD] fix use after free in register_mtd_blktrans
[MTD] [MAPS] Drop now unused sharpsl-flash map
[MTD] ofpart: Check name property to determine partition nodes.
...
Manually fix trivial conflict in drivers/mtd/maps/Makefile
This is a device driver for the NAND flash controller found on the various
DaVinci family chips. It handles up to four SoC chipselects, and some
flavors of secondary chipselect (e.g. based on upper bits of the address
bus) as used with some multichip packages. (Including the 2 GiB chips
used on some TI devel boards.)
The 1-bit ECC hardware is supported (3 bytes ECC per 512 bytes data); but
not yet the newer 4-bit ECC (10 bytes ECC per 512 bytes data), as
available on chips like the DM355 or OMAP-L137 and needed with the more
error-prone MLC NAND chips.
This is a cleaned-up version of code that's been in use for several years
now; sanity checked with the new drivers/mtd/tests.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
OMAP wishes to pass state to the boot loader upon reboot in order to
instruct it whether to wait for USB-based reflashing or not. There is
already a facility to do this via the reboot() syscall, except we ignore
the string passed to machine_restart().
This patch fixes things to pass this string to arch_reset(). This means
that we keep the reboot mode limited to telling the kernel _how_ to
perform the reboot which should be independent of what we request the
boot loader to do.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
arch/arm/mach-at91/at91cap9.c:337: error: 'NR_AIC_IRQS' undeclared here (not in a function)
arch/arm/mach-at91/at91rm9200.c:301: error: 'NR_AIC_IRQS' undeclared here (not in a function)
arch/arm/mach-at91/at91sam9260.c:351: error: 'NR_AIC_IRQS' undeclared here (not in a function)
arch/arm/mach-at91/at91sam9261.c:287: error: 'NR_AIC_IRQS' undeclared here (not in a function)
arch/arm/mach-at91/at91sam9263.c:312: error: 'NR_AIC_IRQS' undeclared here (not in a function)
arch/arm/mach-at91/at91sam9rl.c:304: error: 'NR_AIC_IRQS' undeclared here (not in a function)
arch/arm/mach-h720x/h7202-eval.c:38: error: implicit declaration of function 'IRQ_CHAINED_GPIOB'
arch/arm/mach-ks8695/devices.c:46: error: 'KS8695_IRQ_WAN_RX_STATUS' undeclared here (not in a function)
arch/arm/mach-msm/devices.c:28: error: 'INT_UART1' undeclared here (not in a function)
arch/arm/mach-mx2/devices.c:233: error: 'MXC_GPIO_IRQ_START' undeclared here (not in a function)
arch/arm/mach-mx3/devices.c:128: error: 'MXC_GPIO_IRQ_START' undeclared here (not in a function)
arch/arm/mach-omap1/mcbsp.c:140: error: 'INT_730_McBSP1RX' undeclared here (not in a function)
arch/arm/mach-omap1/mcbsp.c:165: error: 'INT_McBSP1RX' undeclared here (not in a function)
arch/arm/mach-omap1/mcbsp.c:200: error: 'INT_McBSP1RX' undeclared here (not in a function)
arch/arm/mach-omap2/board-apollon.c:286: error: implicit declaration of function 'omap_set_gpio_direction'
arch/arm/mach-omap2/mcbsp.c:154: error: 'INT_24XX_MCBSP1_IRQ_RX' undeclared here (not in a function)
arch/arm/mach-omap2/mcbsp.c:181: error: 'INT_24XX_MCBSP1_IRQ_RX' undeclared here (not in a function)
arch/arm/mach-pxa/e350.c:36: error: 'IRQ_BOARD_START' undeclared here (not in a function)
arch/arm/plat-s3c/dev-i2c0.c:32: error: 'IRQ_IIC' undeclared here (not in a function)
...
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Both of these symbols should be defined by a platform, or neither
should be defined. Ensure that all platforms conform.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
As Al did for Versatile in 2ad4f86b60,
add a typesafe __io implementation for platforms to use. Convert
platforms to use this new simple typesafe implementation.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
