Hi,
Here is an initial set of fixes for power management and OMAP core
infrastructure for 3.5-rc. Most of these patches address boot
warnings and power management problems on OMAP4, although a few of
them address more general issues.
Compile-test information is below. The patches been
After reset, some IP blocks cannot indicate to the PRCM that they are
inactive until they are configured. One example on OMAP4 is the AESS
IP block.
To fix this cleanly, this patch adds another optional function
pointer, setup_preprogram, to the IP block's hwmod data. The function
that is
From: Tero Kristo t-kri...@ti.com
Add a custom reset function for the usb_host_fs/fsusb IP block, and
connect it to the OMAP4 FSUSB block.
This is the first of two fixes required to get rid of the boot
warning:
omap_hwmod: usb_host_fs: _wait_target_disable failed
and to allow the module to
Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
(ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database) broke CORE idle on OMAP3. This prevents device low power
states.
The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and
On boot, the sl2if module can't be enabled. The following message is
logged:
omap_hwmod: sl2if: cannot be enabled for reset (3)
This is probably because the SL2IF is still being held in hardreset.
The SL2IF's hardreset line is shared with one of the IVAHD's hardreset
lines; see for example
From: Djamil Elaidi d-ela...@ti.com
If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature
the
IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup.
Signed-off-by: Djamil Elaidi d-ela...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
Resolve this kernel boot message:
omap_hwmod: mcpdm: cannot be enabled for reset (3)
It appears that the McPDM on OMAP4 can only receive its functional
clock from an off-chip source. This source is not guaranteed to be
present on the board, and when present, it is controlled by I2C. This
would
Add HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is
dependent on an off-chip functional clock that is not guaranteed to be
present during initialization. IP blocks marked with this flag are
left in the INITIALIZED state during kernel init.
This is a workaround for a hardware
Increase the timeout for disabling an IP block to five milliseconds.
This is to handle the usb_host_fs idle latency, which takes almost
four milliseconds after a host controller reset.
This is the second of two patches needed to resolve the following
boot warning:
omap_hwmod: usb_host_fs:
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it. This
patch populates some clock structure clockdomain names to resolve the
following warnings
From: Todd Poynor toddpoy...@google.com
Commit a53025724052b2b1edbc982a4a248784638f563d (OMAP: Add debugfs
node to show the summary of all clocks) introduced clock summary,
however, we are interested in seeing snapshot of the clock state, not
in dynamically changing clock configurations as the
Enable the AESS auto-gating control bit during AESS hwmod setup. This
fixes the following boot warning on OMAP4:
omap_hwmod: aess: _wait_target_disable failed
Without this patch, the AESS IP block does not indicate to the PRCM
that it is idle after it is reset. This prevents some types of SoC
Hi Paul,
On Thursday 17 May 2012 03:54 PM, Rajendra Nayak wrote:
clkdm assocations with clocks in the clock framework are useful
only for 'gate' clocks which have enable/disable ops populated.
Get rid of the clkdm_names populated in any other type of clocks.
Any comments on this one?
On Thursday 07 June 2012 11:43 AM, Paul Walmsley wrote:
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it. This
patch populates some clock structure
On Thu, Jun 07, 2012 at 11:43:10, Paul Walmsley wrote:
Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
(ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database) broke CORE idle on OMAP3. This prevents device low power
states.
The root cause is that the 32K
Hi
On Thu, 7 Jun 2012, Rajendra Nayak wrote:
On Thursday 17 May 2012 03:54 PM, Rajendra Nayak wrote:
clkdm assocations with clocks in the clock framework are useful
only for 'gate' clocks which have enable/disable ops populated.
Get rid of the clkdm_names populated in any other type of
Hi
On Thu, 7 Jun 2012, Hiremath, Vaibhav wrote:
Isn't this impact AM33xx devices, where we do not support smart idle mode???
Anyway, I will also test it on both OMAP3EVM and AM33xx platform now...
Thanks, please let me know how your tests go. If it doesn't work, we'll
go back to the
* Paul Walmsley p...@pwsan.com [120606 23:26]:
Enable the AESS auto-gating control bit during AESS hwmod setup. This
fixes the following boot warning on OMAP4:
omap_hwmod: aess: _wait_target_disable failed
Without this patch, the AESS IP block does not indicate to the PRCM
that it is
* Paul Walmsley p...@pwsan.com [120606 23:26]:
From: Tero Kristo t-kri...@ti.com
Add a custom reset function for the usb_host_fs/fsusb IP block, and
connect it to the OMAP4 FSUSB block.
This is the first of two fixes required to get rid of the boot
warning:
omap_hwmod: usb_host_fs:
On Thu, 7 Jun 2012, Tony Lindgren wrote:
It seems that most/many IP blocks need their custom reset hacks, and
it's not limited to just few instances?
Only four out of the fifty-seven omap_hwmod_classes defined in
mach-omap2/omap_hwmod_44xx_data.c after this series have custom reset
Hi,
On Thu, Jun 07, 2012 at 12:31:13AM -0700, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120606 23:26]:
From: Tero Kristo t-kri...@ti.com
Add a custom reset function for the usb_host_fs/fsusb IP block, and
connect it to the OMAP4 FSUSB block.
This is the first of two
On Thu, 7 Jun 2012, Tony Lindgren wrote:
Here too I think driver like features like this should live in the
driver init for omap OHCI driver. In the likely case that FS OHCI is
not in use on the board, the OHCI glue can just reset it.
What if the driver is not compiled into the kernel, but
* Paul Walmsley p...@pwsan.com [120607 00:35]:
On Thu, 7 Jun 2012, Tony Lindgren wrote:
It seems that most/many IP blocks need their custom reset hacks, and
it's not limited to just few instances?
Only four out of the fifty-seven omap_hwmod_classes defined in
* Paul Walmsley p...@pwsan.com [120607 00:44]:
On Thu, 7 Jun 2012, Tony Lindgren wrote:
Here too I think driver like features like this should live in the
driver init for omap OHCI driver. In the likely case that FS OHCI is
not in use on the board, the OHCI glue can just reset it.
What
* Felipe Balbi ba...@ti.com [120607 00:39]:
Hi,
On Thu, Jun 07, 2012 at 12:31:13AM -0700, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120606 23:26]:
From: Tero Kristo t-kri...@ti.com
Add a custom reset function for the usb_host_fs/fsusb IP block, and
connect it to the
On 6/7/2012 9:55 AM, Felipe Balbi wrote:
On Thu, Jun 07, 2012 at 12:51:58AM -0700, Tony Lindgren wrote:
* Paul Walmsleyp...@pwsan.com [120607 00:44]:
On Thu, 7 Jun 2012, Tony Lindgren wrote:
Here too I think driver like features like this should live in the
driver init for omap OHCI driver.
* Cousson, Benoit b-cous...@ti.com [120607 01:07]:
On 6/7/2012 9:55 AM, Felipe Balbi wrote:
On Thu, Jun 07, 2012 at 12:51:58AM -0700, Tony Lindgren wrote:
* Paul Walmsleyp...@pwsan.com [120607 00:44]:
On Thu, 7 Jun 2012, Tony Lindgren wrote:
Here too I think driver like features like this
On Thu, Jun 07, 2012 at 10:02:51AM +0200, Cousson, Benoit wrote:
On 6/7/2012 9:55 AM, Felipe Balbi wrote:
On Thu, Jun 07, 2012 at 12:51:58AM -0700, Tony Lindgren wrote:
* Paul Walmsleyp...@pwsan.com [120607 00:44]:
On Thu, 7 Jun 2012, Tony Lindgren wrote:
Here too I think driver like
Hi ,
On Wed, Jun 06, 2012 at 13:21:23, CF Adad wrote:
Thanks again. I'm really starting to think the GPMC almost has to be
contributing.
Does adding cycle2cycle delay / bus turnaround prevent the issue ?,
SMSC datasheet mentions about special restrictions on back to back read
and
On Thu, 7 Jun 2012, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120607 00:44]:
On Thu, 7 Jun 2012, Tony Lindgren wrote:
Here too I think driver like features like this should live in the
driver init for omap OHCI driver. In the likely case that FS OHCI is
not in use on the
I am intending to post the _entire_ set of DMA patches I have so far.
I'm going to be doing this in a slightly different way to normal,
because of the way the branches are structured.
What will come first is a set of three common patches to all the
branches. Following on from that will be the
Add a function to find a descriptor within the depths of the
virtualized DMA channel support. Needed for tx_status functionality.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/virt-dma.c | 13 +
drivers/dma/virt-dma.h |2 +-
2 files changed, 14
Add support for cyclic DMA's periodic callbacks. Drivers are expected
to call vchan_cyclic_callback() when a period has completed, which will
schedule the tasklet to make the callback into the driver.
As callbacks are made from tasklet context, it is important to realise
that we don't guarantee
Updates to the SA11x0 DMA engine driver. This fixes the residue
calculation, and implements cyclic transfers.
drivers/dma/sa11x0-dma.c | 153 --
1 files changed, 121 insertions(+), 32 deletions(-)
--
To unsubscribe from this list: send the line
The semantics now implemented are:
- If the cookie has completed successfully, the residue will be zero.
- If the cookie is in progress or the channel is paused, it will be the
number of bytes yet to be transferred. [*]
- If the cookie is queued, it will be the number of bytes in the
Add support for cyclic DMA on sa11x0 platforms. This follows the
discussed behaviour that the callback will be called at some point
after period expires, and may coalesce multiple period expiries into
one callback (due to the tasklet behaviour.)
Signed-off-by: Russell King
On Thu, 7 Jun 2012, Tony Lindgren wrote:
OK so that's not too bad then. But there's also the
omap2_wd_timer_disable pre_shutdown too. And there's also the sysconfig
autoidle bit for each driver that we're tweaking in the bus level code?
I think I lost your point here. The ioremap() issue
Here's the PL08x patches.
drivers/dma/Kconfig|1 +
drivers/dma/amba-pl08x.c | 941 ++--
include/linux/amba/pl08x.h | 156 +---
3 files changed, 482 insertions(+), 616 deletions(-)
--
To unsubscribe from this list: send the line
The runtime PM support conflicts with the generic AMBA bus PM, and also
causes a potential deadlock with the PL011 driver as it results in
interrupts being enabled beneath a spinlock.
I don't presently see any solution to this other than by removing the
runtime PM support entirely from the DMA
db8196df4 (dmaengine: move drivers to dma_transfer_direction) missed
fixing up the DMA_NONE case.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
The pl08x_driver_data spinlock is only ever initialized. Nothing else
uses it. Let's get rid of it.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
Circular buffers are not handled in this way; we have a separate API
call now to setup circular buffers. So lets not mislead people with
this bool.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c |7
Try to avoid dereferencing the DMA engine's channel struct in these
platform helpers; instead, pass a pointer to the channel data into
get_signal(), and the returned signal number to put_signal().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c |4 ++--
Move the driver private data structures into the driver itself, rather
than having them exposed to everyone in a header file.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c | 136
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c |2 +-
include/linux/amba/pl08x.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c
Add a dma_slave_config struct to struct pl08x_dma_chan, and move the
src_addr/dst_addr arguments into this struct. This is a step away
from using the dma_slave_config's direction member.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
As we now store the dma_slave_config in pl08x_dma_chan, we don't need
to store this separately. Use the one in dma_slave_config directly.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c |8 +---
1
Move the bus and transfer increment selection to the DMA prepare
function rather than the slave configuration function.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c | 26 ++
1 files
Extract the functionality from dma_slave_config to generate the cctl
values for a given bus width and burst size. This allows us to use
this elsewhere in the driver, namely the prepare functions.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King
Ignore the direction argument in dma_slave_config, and configure both
directions independently. We still check that the configuration for
the intended direction is valid; this check will eventually be dropped.
This check is just for debugging at present.
Acked-by: Linus Walleij
Get rid of the unnecessary checks in dma_slave_config utilizing
the DMA direction. This allows us to move the computation of
cctl to the prepare function.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c |
Split the DMA request mux signal handling from the physical channel
allocation code. The physical channel has very little to do with the
DMA request input which will be used, so these should be two separate
operations.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King
Move the signal handling out of the physical channel structure into
the virtual channel structure, where it should belong as it has more
to do with the virtual channel than the physical one.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Keep track of the number of descriptors currently using a MUX setting
on a per-channel basis. This allows us to know when we have descriptors
queued somewhere which have been assigned a DMA request signal.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King
Convert PL08x to use a list of completed descriptors rather than
merely relying upon a single pointer. This makes it possible to
schedule the tasklet for other purposes, and makes our behaviour
similar to virt-dma.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King
Move the DMA request muxing into the slave prepare code and txd
release/completion code. This means we only hold the DMA request
mux while there are descriptors waiting to be started or are in
progress.
This leaves txd-direction as a write-only variable; remove it.
Acked-by: Linus Walleij
As we no longer need to pass a descriptor to prep_phy_channel(), we
don't need to keep track of the descriptor which is waiting for a
channel to become available. So let's get rid of it.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
* Paul Walmsley p...@pwsan.com [120607 03:24]:
On Thu, 7 Jun 2012, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120607 00:44]:
On Thu, 7 Jun 2012, Tony Lindgren wrote:
Here too I think driver like features like this should live in the
driver init for omap OHCI driver.
Rather than code the de-queue of the txd several times, move that into
the start_txd function. Rename this to better illustrate what it's
now doing, and call this function when starting a delayed memcpy().
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King
On Thu, 7 Jun 2012, Cousson, Benoit wrote:
In fact we should delay the reset to the very last moment and
potentially reset the IPs not under driver control later after a couple
of second for example. It will avoid reseting every IP that will be
handled properly by drivers.
We discussed
Our behaviour wasn't correct; issue_pending is supposed to be called
before any submitted descriptors are available for processing by the
DMA engine. Split the pend_list in two, one for submitted descriptors
and another list for issued descriptors.
Acked-by: Linus Walleij
Hi Paul,
On Thursday 07 June 2012 12:37 PM, Paul Walmsley wrote:
Hi
On Thu, 7 Jun 2012, Rajendra Nayak wrote:
On Thursday 17 May 2012 03:54 PM, Rajendra Nayak wrote:
clkdm assocations with clocks in the clock framework are useful
only for 'gate' clocks which have enable/disable ops
Rather than waiting for the tasklet to run, we can start the next
descriptor from interrupt context, as soon as we know that the
previous descriptor has completed.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
Rework the physical channel allocation mechanism to only allocate
physical channels to virtual channels when they're about to be used.
This eliminates all the complexity with holding channels while
descriptors are being prepared, which is completely unnecessary.
This also brings this driver to a
Convert PL08x to use the virt-dma structures.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c | 57 +++--
1 files changed, 29 insertions(+), 28 deletions(-)
diff --git
Initialize the vchan struct, and use the provided spinlock rather than
our own.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/Kconfig |1 +
drivers/dma/amba-pl08x.c | 45
Convert to use the virtual dma channel submitted/issued descriptor
lists rather than our own private lists, and use the virtual dma
channel support functions to manage these lists.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
This function is now unnecessary; we can move its internals inline
instead.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c | 32 +---
1 files changed, 9 insertions(+), 23
The free function says the pl08x lock should be taken before calling
it. However, the DMA pool allocation/freeing is already properly
locked. The only thing that would need this is pool_ctr, which
happens to be a write-only variable.
Let's get rid of this, and eliminate any need for additional
Now that we're converted to use the generic vchan support, we can fix
the residue return from tx_status to be compliant with dmaengine. This
returns the number of bytes remaining for the _specified_ cookie, not
the number of bytes in all pending transfers on the channel.
Acked-by: Linus Walleij
Ensure all queued descriptors are freed when the channel is released,
ensuring we don't leak memory
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
And the last set - the OMAP patches.
Documentation/feature-removal-schedule.txt | 11 +
arch/arm/mach-omap1/board-h2-mmc.c |1 -
arch/arm/mach-omap1/board-h3-mmc.c |1 -
arch/arm/mach-omap1/board-nokia770.c |1 -
arch/arm/mach-omap2/board-n8x0.c |
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/Kconfig |6 +
drivers/dma/Makefile |1 +
drivers/dma/omap-dma.c | 522 ++
include/linux/omap-dma.h | 24 ++
4 files
Add DMA engine support to the OMAP HSMMC driver. This supplements the
private DMA API implementation contained within this driver, and the
driver can be switched at build time between using DMA engine and the
private DMA API.
Tested-by: Grazvydas Ignotas nota...@gmail.com
Signed-off-by: Russell
Remove the private DMA API implementation from omap_hsmmc, making it
use entirely the DMA engine API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/mmc/host/omap_hsmmc.c | 265 ++---
1 files changed, 64 insertions(+), 201 deletions(-)
Add DMA engine support to the OMAP driver. This supplements the
private DMA API implementation contained within this driver, and the
driver can be switched at build time between using DMA engine and the
private DMA API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
Remove the private DMA API implementation from omap, making it use
entirely the DMA engine API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/mmc/host/omap.c | 235 +-
1 files changed, 6 insertions(+), 229 deletions(-)
diff
DMAengine uses the DMA engine device structure when mapping/unmapping
memory for DMA, so the MMC devices do not need their DMA masks
initialized (this reflects hardware: the MMC device is not the device
doing DMA.)
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
Add DMA engine support to the OMAP SPI driver. This supplements the
private DMA API implementation contained within this driver, and the
driver can be independently switched at build time between using DMA
engine and the private DMA API for the transmit and receive sides.
Tested-by: Shubhrajyoti
* Paul Walmsley p...@pwsan.com [120607 03:49]:
On Thu, 7 Jun 2012, Tony Lindgren wrote:
OK so that's not too bad then. But there's also the
omap2_wd_timer_disable pre_shutdown too. And there's also the sysconfig
autoidle bit for each driver that we're tweaking in the bus level code?
Remove the private DMA API implementation from spi-omap2-mcspi.c,
making it use entirely the DMA engine API.
Acked-by: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/spi/spi-omap2-mcspi.c | 104 ++---
Add DMA engine support to the OMAP2 NAND driver. This supplements the
private DMA API implementation contained within this driver, and the
driver can be independently switched at build time between using DMA
engine and the private DMA API.
Tested-by: Grazvydas Ignotas nota...@gmail.com
Remove the private DMA API implementation from nand/omap2.c
making it use entirely the DMA engine API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/mtd/nand/omap2.c | 136 +-
1 files changed, 26 insertions(+), 110 deletions(-)
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
Documentation/feature-removal-schedule.txt | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt
+ Ohad
On 6/7/2012 12:52 PM, Paul Walmsley wrote:
On Thu, 7 Jun 2012, Cousson, Benoit wrote:
In fact we should delay the reset to the very last moment and
potentially reset the IPs not under driver control later after a couple
of second for example. It will avoid reseting every IP that will
On Thu, Jun 7, 2012 at 4:36 PM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/Kconfig | 6 +
drivers/dma/Makefile | 1 +
drivers/dma/omap-dma.c | 522
On Thu, 2012-06-07 at 12:09 +0100, Russell King wrote:
Add DMA engine support to the OMAP2 NAND driver. This supplements the
private DMA API implementation contained within this driver, and the
driver can be independently switched at build time between using DMA
engine and the private DMA
On Thu, Jun 7, 2012 at 6:10 PM, S, Venkatraman svenk...@ti.com wrote:
On Thu, Jun 7, 2012 at 4:36 PM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/Kconfig | 6 +
On Thu, Jun 07, 2012 at 03:49:35PM +0300, Artem Bityutskiy wrote:
On Thu, 2012-06-07 at 12:09 +0100, Russell King wrote:
Add DMA engine support to the OMAP2 NAND driver. This supplements the
private DMA API implementation contained within this driver, and the
driver can be independently
On Thu, 2012-06-07 at 14:11 +0100, Russell King - ARM Linux wrote:
No, it makes sense to get this stuff via a single tree all together,
because, as you can see from the thread structure, it isn't purely
an OMAP thing.
The OMAP stuff depends on a core set, as does a bunch of PL08x and
SA11x0
Hi,
On Mon, Jun 04, 2012 at 12:15:01, Mohammed, Afzal wrote:
Hi,
This series cleans up gpmc mtd interactions so that GPMC driver
conversion which is going to happen shortly would happen smoothly
by not creating much disturbance outside of arch/arm/*omap*/
This series,
1. provides the
Hi
While converting platform device registry to Hwmod for CPSW Ethernet driver
which is present in AM335X (OMAP2+), I am not finding a way to specify
dma_mask and coherent_dma_mask.
Is there a way to specify dma_mask and coherent_dma_mask in hwmod?
---
Regards,
Mugunthan V N.
--
To
* Russell King rmk+ker...@arm.linux.org.uk [120607 04:11]:
Add DMA engine support to the OMAP HSMMC driver. This supplements the
private DMA API implementation contained within this driver, and the
driver can be switched at build time between using DMA engine and the
private DMA API.
* Russell King rmk+ker...@arm.linux.org.uk [120607 04:11]:
Remove the private DMA API implementation from omap_hsmmc, making it
use entirely the DMA engine API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Tested-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list:
* Russell King rmk+ker...@arm.linux.org.uk [120607 04:12]:
Remove the private DMA API implementation from omap, making it use
entirely the DMA engine API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Tested-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send
* Russell King rmk+ker...@arm.linux.org.uk [120607 04:12]:
DMAengine uses the DMA engine device structure when mapping/unmapping
memory for DMA, so the MMC devices do not need their DMA masks
initialized (this reflects hardware: the MMC device is not the device
doing DMA.)
Signed-off-by:
* Russell King rmk+ker...@arm.linux.org.uk [120607 04:14]:
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Tony Lindgren t...@atomide.com
---
Documentation/feature-removal-schedule.txt | 11 +++
1 files changed,
* Artem Bityutskiy dedeki...@gmail.com [120607 06:28]:
On Thu, 2012-06-07 at 14:11 +0100, Russell King - ARM Linux wrote:
No, it makes sense to get this stuff via a single tree all together,
because, as you can see from the thread structure, it isn't purely
an OMAP thing.
The OMAP
On Thu, Jun 7, 2012 at 4:37 PM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
Remove the private DMA API implementation from omap_hsmmc, making it
use entirely the DMA engine API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Tested this on 4430SDP with rootfs usage, untarring the
On Thu, Jun 07, 2012 at 12:38:50, Paul Walmsley wrote:
Hi
On Thu, 7 Jun 2012, Hiremath, Vaibhav wrote:
Isn't this impact AM33xx devices, where we do not support smart idle mode???
Anyway, I will also test it on both OMAP3EVM and AM33xx platform now...
Thanks, please let me know how
1 - 100 of 126 matches
Mail list logo
