On Thu, Jun 07, 2012 at 11:47:23AM +0100, Russell King wrote:
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
Dan, Vinod,
There's a change I would like to do to the DMA slave configuration.
It's currently a pain to have the source and destination parameters in
the dma_slave_config structure as separate elements; it means when you
want to extract them, you end up with code in DMA engine drivers like:
+
2012/6/10 Russell King - ARM Linux li...@arm.linux.org.uk:
Dan, Vinod,
There's a change I would like to do to the DMA slave configuration.
It's currently a pain to have the source and destination parameters in
the dma_slave_config structure as separate elements; it means when you
want to
On Sun, Jun 10, 2012 at 07:19:47PM +0800, Barry Song wrote:
2012/6/10 Russell King - ARM Linux li...@arm.linux.org.uk:
Dan, Vinod,
There's a change I would like to do to the DMA slave configuration.
It's currently a pain to have the source and destination parameters in
the
farm is down at the moment, so I'm unable to do further
testing on other boards. Boot logs, such as they are, are available
from:
http://www.pwsan.com/omap/bootlogs/20120610/omap_fixes_a_3.5rc__1869336b045e205b874e178443213815a8561cd1/
These patches are available via git from git://git.pwsan.com
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
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
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:
Add a custom setup_preprogram 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 idle.
It may be necessary
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
---
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
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
The 32k sync timer IP block target idle modes are incorrect in the
hwmod data are incorrect. The IP block does not support any
smart-idle modes. Update the data to reflect the correct modes.
This problem was initially identified and a diff fragment posted to
the lists by Benoît Cousson
After reset, some IP blocks cannot indicate to the PRCM that they are
inactive until they are configured. Some examples on OMAP4 include
the AESS and FSUSB IP blocks.
To fix this cleanly, this patch adds another optional function
pointer, setup_preprogram, to the IP block's hwmod data. The
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
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
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 Vaibhav, Afzal, Tony,
On Mon, 21 May 2012, Paul Walmsley wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Currently dummy voltage domain data is being created
in order to succeed boot process, nothing has been done
w.r.t actual hardware (voltage control).
Also, hook up the AM33XX
On Sun, 2012-06-10 at 12:22 +0100, Russell King - ARM Linux wrote:
On Sun, Jun 10, 2012 at 07:19:47PM +0800, Barry Song wrote:
2012/6/10 Russell King - ARM Linux li...@arm.linux.org.uk:
Dan, Vinod,
There's a change I would like to do to the DMA slave configuration.
It's currently a
19 matches
Mail list logo
