| Age | Commit message (Collapse) | Author |
|---|
|
Ethernet Media Access Controller (EMAC) on da850/omap-l138
supports 10/100 Mbps operation. It also supports Media
Independent Interface (MII) and Reduced Media Independent
Interface (RMII) to physical layer (PHY).
Phy which supports MII is present on the DA850/OMAP-L138
base board and Phy supporting RMII is present on the
UI card. This patch adds support only for the MII Phy.
Support for RMII Phy will be added later.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Add support for the DA850/OMAP-L138 Evaluation Module (EVM)
from TI. The EVM has User Interface (UI) card which contains
various devices. This UI card can be connected to the base
board. Support for all the devices on the UI card and ones on
the EVM will be added in subsequent patches.
The EVM schematics are not available publicly yet; but should
be available soon.
A new defconfig for this board has been added mainly because
the DA830/OMAP-L137 defconfig forces writethrough cache mode
which is not required on DA850/OMAP-L138.
This patch has been boot tested on DA850/OMAP-L138 EVM
using ramdisk as filesystem.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
The DA850/OMAP-L138 is a new SoC from TI in the same family as
DA830/OMAP-L137.
Major changes include better support for power management,
support for SATA devices and McBSP (same IP as DM644x).
DA850/OMAP-L138 documents are available at
http://focus.ti.com/docs/prod/folders/print/omap-l138.html.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
DM646x has MUSB connected to IRQs 13 and 14 (unlike IRQ12 on other platforms),
so pass the correct IRQ resources with the platform device.
Signed-off-by: Dmitry Krivoschekov <dkrivoschekov@ru.mvista.com>
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Rearrange the PINMUX macros and pinmux_setup function which
are common between da830/omap-l137 and da850/omap-l138.
Also, replace the da830 string in function names to da8xx.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
In EDMA resource structure, instead of passing EDMA CC
interrupt, EDMA TC error interrupt number is being passed.
Before the patch:
root@arago:~# cat /proc/interrupts
CPU0
12: 0 cp_intc edma_error
13: 0 cp_intc edma
Err:
After the patch:
root@arago:~# cat /proc/interrupts
CPU0
11: 0 cp_intc edma
12: 0 cp_intc edma_error
Err:
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
With the introduction of TI da850/omap-l138, some of the macros
defined for da830/omap-l137 will be needed in da850 source file.
So, move the common macros to da8xx.h header file.
Also, modify the macro names from DA830_... to DA8XX_.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
This patch adds platform data and init function for IDE which could be called
from board specific file to register IDE device.
Note that for 594MHz device the transfer mode is limited to UDMA4 since ideclk
rate is less than 100 MHz, which forces udma_mask in palm_bk3710.c to UDMA4,
while for 729MHz device, it is UDMA5.
Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Make arch_idle and arch_reset inline as inline function.
Not having them inline leads to a warning of this sort when only
one of these functions is used:
arch/arm/mach-davinci/include/mach/system.h:24: warning: 'arch_reset' \
defined but not used
boot, re-boot tested on OMAP-L138 EVM
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
This patch takes out IO mapping macros from mach/io.h and puts them in
mach/hardware.h avoiding need to include mach/io.h in various files such as
serial.h, vmalloc.h etc.
The main reason to avoid inclusion of mach/io.h is, when default in/out macros
are overridden by machine specific functions (e.g., in case of PCI I/O), they
result into linker error. An example snippet and error snapshot is listed below.
Following code in mach/io.h:
#define inl(p) my_inl()
static inline unsigned int my_inl(unsigned int addr)
{
if (IS_PCI_IO(addr))
return pci_inl ();
else
return le32_to_cpu(__raw_readl(__typesafe_io(addr)));
}
leads to error:
LD arch/arm/boot/compressed/vmlinux
arch/arm/boot/compressed/misc.o: In function `my_inl':
misc.c:(.text+0x2744): undefined reference to `pci_inl'
make[2]: *** [arch/arm/boot/compressed/vmlinux] Error 1
This is because mach/io.h gets included in arch/arm/boot/compressed/misc.c
through mach/serial.h but pci.c file, which defines 'pci_inl' doesn't get built
into compressed vmlinux.
Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
This patch adds clock data for IDE and also updates pin mux mask for ATA so as
to disable PCI when ATA is selected.
Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
1) Registers the platform devices for ASP on dm355, dm644x and dm646x
so that the machine driver can probe to get ASP related platform
data.
2) Move towards definition of the asp clocks using physical name(for
dm355 and dm644x)
3) Add platform data to board specific files.
Signed-off-by: Naresh Medisetty <naresh@ti.com>
Signed-off-by: Chaithrika U S <chaithrika@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Support DM365 GPIOs ... primarily by handling non-banked GPIO IRQs:
- Flag DM365 chips as using non-banked GPIO interrupts, using a
new soc_info field.
- Replace the gpio_to_irq() mapping logic. This now uses some
runtime infrastructure, keyed off that new soc_info field,
which doesn't handle irq_to_gpio().
- Provide a new irq_chip ... GPIO IRQs handled directly by AINTC
still need edge triggering managed by the GPIO controller.
DM365 chips no longer falsely report 104 GPIO IRQs as they boot.
Intelligence about IRQ muxing is missing, so for the moment this
only exposes the first eight DM365 GPIOs, which are never muxed.
The next eight are muxed, half with Ethernet (which uses most of
those pins anyway).
Tested on DM355 (10 unbanked IRQs _or_ 104 banked ones) and also
on DM365 (16 unbanked ones, only 8 made available).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Patch updates DM365 PINMUX by adding entries for Video, SPI 1 - 4,
PWM 0 - 3.
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Add support for the DA830/OMAP-L137 Evaluation Module (EVM)
from TI. The EVM has User Interface (UI) and Audio cards
that can be connected which contain various devices.
Support for those devices and ones on the EVM will be
added in subsequent patches.
Additional generalizations for future SoCs in da8xx family done by
Sudhakar Rajashekhara and Sekhar Nori.
Signed-off-by: Steve Chen <schen@mvista.com>
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
The da830/omap l137 is a new SoC from TI that is similar
to the davinci line. Since its so similar to davinci,
put the support for the da830 in the same directory as
the davinci code.
There are differences, however. Some of those differences
prevent support for davinci and da830 platforms to work
in the same kernel binary. Those differences are:
1) Different physical address for RAM. This is relevant
to Makefile.boot addresses and PHYS_OFFSET. The
Makefile.boot issue isn't truly a kernel issue but
it means u-boot won't work with a uImage including
both architectures. The PHYS_OFFSET issue is
addressed by the "Allow for runtime-determined
PHYS_OFFSET" patch by Lennert Buytenhek but it
hasn't been accepted yet.
2) Different uart addresses. This is only an issue
for the 'addruart' assembly macro when CONFIG_DEBUG_LL
is enabled. Since the code in that macro is called
so early (e.g., by _error_p in kernel/head.S when
the processor lookup fails), we can't determine what
platform the kernel is running on at runtime to use
the correct uart address.
These areas have compile errors intentionally inserted
to indicate to the builder they're doing something wrong.
A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added
to distinguish between a true davinci architecture and
the da830 architecture.
Note that the da830 currently has an issue with writeback
data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be
enabled when building a da830 kernel.
Additional generalizations for future SoCs in the da8xx family done by
Sudhakar Rajashekhara and Sekhar Nori.
Signed-off-by: Steve Chen <schen@mvista.com>
Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com>
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Add basic support for the CPLD on the DM365 EVM board:
- Read SW5 to set up NAND and keypad vs (someday) OneNAND
- Export MMC/SD card detect and writeprotect signals
- LED support (same layout as on DM355 EVM)
- Static config for video input:
* external HD imager precludes MMC1, Ethernet, audio
* else either tvp5146 (SD/default) or tvp7002 (HD)
The video input could actually be switched around dynamically;
change that if/when that's needed (and after those other video
inputs have driver support).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Patch adds support for MMC/SD in the DM365 EVM.
Pinmux for MMC/SD slot 1 on the DM365 EVM is also
configured.
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
The patch adds Support for EMAC in the DM365 SOC and
the DM365 EVM board.
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
This patch does the following
1) Adds entries to davinci_all_defconfig for DM365
2) Adds entries to the Makefile for DM365
3) Adds entries for DM365 in the Kconfig
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
The patch adds support for Evaluation Module (EVM) board for the dm365
SoC.
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
The patch adds base support for new TI SOC DM365, which s
similar to the dm355.
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
watchdog info is not needed in soc_info, platform_device can
be used directly in core code.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
CC arch/arm/mach-davinci/sram.o
arch/arm/mach-davinci/sram.c: In function 'sram_init':
arch/arm/mach-davinci/sram.c:63: warning: comparison of distinct pointer types lacks a cast
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
JTAG ID for DM644x silicon revision 2.1 has changed. An entry for the new
silicon revision needs to be added to the davinci_id structure. Without
this addition, EVMs with new silicon revision fail to boot the kernel.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
The davinci reset routine, davinci_watchdog_reset(), sets the
TCR register instead of the TGCR register as it should to put
the WDT into its "Initial State".
It also writes the WDTCR register without the proper WDKEY
which is pointless since the register will be write-protected.
Signed-off-by: David Griego <dgriego@mvista.com>
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Adds McASP clock support for the two instances of mcasp (mcasp0,mcasp1). This
patch is part of the audio support for dm646x series.
Signed-off-by: Naresh Medisetty <naresh@ti.com>
Signed-off-by: Chaithrika U S <chaithrika@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Enables module clock for DM646x EDMA channel controller and transfer
controller.
Signed-off-by: Naresh Medisetty <naresh@ti.com>
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
- restructure to support multiple channel controllers by using
additional struct resources for each CC
- interface changes visible to EDMA clients
Introduce macros to build IDs from controller and channel number,
and to extract them. Modify the edma_alloc_slot function to take an
extra argument for the controller.
Also update ASoC drivers to use API. ASoC changes
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
- Move queue related mappings to dm<soc>.c
EDMA in DM355 and DM644x has two transfer controllers while DM646x
has four transfer controllers. Moving the queue to tc mapping and
queue priority mapping to dm<soc>.c will be helpful to probe these
mappings from platform device so that the machine_is_* testing will
be avoided.
- add channel mapping logic
Channel mapping logic is introduced in dm646x EDMA. This implies
that there is no fixed association for a channel number to a
parameter entry number. In other words, using the DMA channel
mapping registers (DCHMAPn), a PaRAM entry can be mapped to any
channel. While in the case of dm644x and dm355 there is a fixed
mapping between the EDMA channel and Param entry number.
Signed-off-by: Naresh Medisetty <naresh@ti.com>
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Reviewed-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
|
|
In commit a8e7d49aa7be728c4ae241a75a2a124cdcabc0c5 ("Fix race in
create_empty_buffers() vs __set_page_dirty_buffers()"), I removed a test
for a NULL page mapping unintentionally when some of the code inside
__set_page_dirty() was moved to the callers.
That removal generally didn't matter, since a filesystem would serialize
truncation (which clears the page mapping) against writing (which marks
the buffer dirty), so locking at a higher level (either per-page or an
inode at a time) should mean that the buffer page would be stable. And
indeed, nothing bad seemed to happen.
Except it turns out that apparently reiserfs does something odd when
under load and writing out the journal, and we have a number of bugzilla
entries that look similar:
http://bugzilla.kernel.org/show_bug.cgi?id=13556
http://bugzilla.kernel.org/show_bug.cgi?id=13756
http://bugzilla.kernel.org/show_bug.cgi?id=13876
and it looks like reiserfs depended on that check (the common theme
seems to be "data=journal", and a journal writeback during a truncate).
I suspect reiserfs should have some additional locking, but in the
meantime this should get us back to the pre-2.6.29 behavior.
Pattern-pointed-out-by: Roland Kletzing <devzero@web.de>
Cc: stable@kernel.org (2.6.29 and 2.6.30)
Cc: Jeff Mahoney <jeffm@suse.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon: add GET_PARAM/INFO support for Z pipes
drm/radeon/kms: add r100/r200 OQ support.
drm: Fix sysfs device confusion.
drm/radeon/kms: implement the bo busy ioctl properly.
|
|
* 'btrfs' of git://git.kernel.dk/linux-2.6-block:
btrfs: fix inode rbtree corruption
|
|
As noted in 83d349f35e1ae72268c5104dbf9ab2ae635425d4 ("x86: don't send
an IPI to the empty set of CPU's"), some APIC's will be very unhappy
with an empty destination mask. That commit added a WARN_ON() for that
case, and avoided the resulting problem, but didn't fix the underlying
reason for why those empty mask cases happened.
This fixes that, by checking the result of 'cpumask_andnot()' of the
current CPU actually has any other CPU's left in the set of CPU's to be
sent a TLB flush, and not calling down to the IPI code if the mask is
empty.
The reason this started happening at all is that we started passing just
the CPU mask pointers around in commit 4595f9620 ("x86: change
flush_tlb_others to take a const struct cpumask"), and when we did that,
the cpumask was no longer thread-local.
Before that commit, flush_tlb_mm() used to create it's own copy of
'mm->cpu_vm_mask' and pass that copy down to the low-level flush
routines after having tested that it was not empty. But after changing
it to just pass down the CPU mask pointer, the lower level TLB flush
routines would now get a pointer to that 'mm->cpu_vm_mask', and that
could still change - and become empty - after the test due to other
CPU's having flushed their own TLB's.
See
http://bugzilla.kernel.org/show_bug.cgi?id=13933
for details.
Tested-by: Thomas Björnell <thomas.bjornell@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
When 'and'ing two bitmasks (where 'andnot' is a variation on it), some
cases want to know whether the result is the empty set or not. In
particular, the TLB IPI sending code wants to do cpumask operations and
determine if there are any CPU's left in the final set.
So this just makes the bitmask (and cpumask) functions return a boolean
for whether the result has any bits set.
Cc: stable@kernel.org (2.6.30, needed by TLB shootdown fix)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The default_send_IPI_mask_logical() function uses the "flat" APIC mode
to send an IPI to a set of CPU's at once, but if that set happens to be
empty, some older local APIC's will apparently be rather unhappy. So
just warn if a caller gives us an empty mask, and ignore it.
This fixes a regression in 2.6.30.x, due to commit 4595f9620 ("x86:
change flush_tlb_others to take a const struct cpumask"), documented
here:
http://bugzilla.kernel.org/show_bug.cgi?id=13933
which causes a silent lock-up. It only seems to happen on PPro, P2, P3
and Athlon XP cores. Most developers sadly (or not so sadly, if you're
a developer..) have more modern CPU's. Also, on x86-64 we don't use the
flat APIC mode, so it would never trigger there even if the APIC didn't
like sending an empty IPI mask.
Reported-by: Pavel Vilim <wylda@volny.cz>
Reported-and-tested-by: Thomas Björnell <thomas.bjornell@gmail.com>
Reported-and-tested-by: Martin Rogge <marogge@onlinehome.de>
Cc: Mike Travis <travis@sgi.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Needed for occlusion queries on rv530 chips.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Node may not be inserted over existing node. This causes inode tree
corruption and I was seeing crashes in inode_tree_del which I can not
reproduce after this patch.
The other way to fix this would be to tie inode lifetime in the rbtree
with inode while not in freeing state. I had a look at this but it is
not so trivial at this point. At least this patch gets things working again.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Cc: Chris Mason <chris.mason@oracle.com>
Acked-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
This adds the relocation necessary for OQ support on the r100/r200
chipsets.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The drm sysfs class suspend / resume methods could not distinguish
between different device types wich could lead to illegal type casts.
Use struct device_type and make sure the class suspend / resume callbacks
are aware of those. There is no per device-type suspend / resume. Only
new-style PM.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The previous patch assumes the ioctl already existed, when
it actually didn't.
It also didn't return the correct error code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
* 'i2c-fixes-rc6' of git://aeryn.fluff.org.uk/bjdooks/linux:
i2c-stu300: I2C STU300 stability updates
i2c-omap: Enable workaround for Errata 1.153 based on
i2c-omap: ACK pending [R/X]DR and [R/X]RDY interrupts
i2c-omap: Fix I2C status ACK
|
