| Age | Commit message (Collapse) | Author |
|---|
|
Trivial build fix for when sysfs is disabled.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
The current SH DMA API is somewhat broken, not correctly matching
virtual channel to the correct SH DMAC. This wasn't noticeable when
using g2 DMA for the sound driver - one channel 0 is as good as any
other! - but caused the pvr2 driver to fail.
This patch fixes the pvr2 problem and consequently fixes the sound
driver to ensure it continues to function.
Signed-off by: Adrian McMenamin <adrian@mcmen.demon.co.uk>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
Several errors were spotted during building for custom config (SMP
included). Although SMP still does not compile (no ipi and
__smp_call_function) and does not work, this looks a bit cleaner.
Some other errors obtained via gcc-4.1.0 build.
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
This extends the SH DMA API for allowing handling of DMA
channels based off of their respective capabilities.
A couple of functions are added to the existing API,
the core bits are register_chan_caps() for registering
channel capabilities, and request_dma_bycap() for fetching
a channel dynamically based off of a capability set.
Signed-off-by: Mark Glaisher <mark.glaisher@st.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
Nothing exciting here, just trivial fixes..
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
|
|
This extends the current SH DMA API somewhat to support a proper virtual
channel abstraction, and also works to represent this through the driver model
by giving each DMAC its own platform device.
There's also a few other minor changes to support a few new CPU subtypes, and
make TEI generation for the SH DMAC configurable.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
