* Kevin Hilman khil...@ti.com [120711 14:34]:
Omar Ramirez Luna omar.l...@linaro.org writes:
On 11 July 2012 12:07, Kevin Hilman khil...@ti.com wrote:
...
[2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
[2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA
* Mohammed, Afzal af...@ti.com [120712 23:19]:
Hi Tony,
On Tue, Jul 10, 2012 at 18:35:55, Tony Lindgren wrote:
The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678:
Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)
are available in the git repository at:
* Kevin Hilman khil...@ti.com [120711 13:15]:
Hi Tony,
In your current master branch, commit 3dd50d054 (Merge tag
'omap-cleanup-for-v3.6' into tmp-merge) added back the mpu_3xxx_clkdm
into the common clockdomains that was removed by commit 16e5e2c47 (ARM:
OMAP AM35x: clockdomain data: Fix
On Wed, 2012-06-27 at 15:20 +, Arnd Bergmann wrote:
Back from vacation... so restart the pending discussion
Sorry, I believe I was just using the wrong terminology, and what I named
the slave here would just be the client.
This may have contributed to a lot of confusion before, so
* Kevin Hilman khil...@ti.com [120712 10:55]:
Paul Walmsley p...@pwsan.com writes:
Commit 3dd50d0545bd5a8ad83d4339f07935cd3e883271 (Merge tag
'omap-cleanup-for-v3.6' into tmp-merge) inadvertently caused a
clockdomain to be registered twice on OMAP3 boards. This causes warnings
on
Hi,
* Raphael Assenat r...@8d.com [120712 14:28]:
Hello,
We have designed a board based on the AM3505 to use in one of our products,
an unattended payment terminal. I am wondering if it would be meaningful
to clean up and submit our patches to add support for our board in the
mainline.
On Fri, 2012-07-06 at 13:36 +0200, Guennadi Liakhovetski wrote:
On Mon, 25 Jun 2012, Arnd Bergmann wrote:
[snip]
The channel data in the device tree is still in a format
that is specific to that dmaengine driver and interpreted
by it. Using the regular dma_filter_fn prototype is not
* Dennis Gilmore den...@ausil.us [120711 06:53]:
On Wed, 11 Jul 2012 00:42:33 -0700
Tony Lindgren t...@atomide.com wrote:
Sounds like it's some kind of issue with dtb getting overwritten
by something. We had an issue where kernel BSS was overlapping dtb
in some cases, but those should
* Tony Lindgren t...@atomide.com [120712 23:48]:
* Kevin Hilman khil...@ti.com [120711 13:15]:
Hi Tony,
In your current master branch, commit 3dd50d054 (Merge tag
'omap-cleanup-for-v3.6' into tmp-merge) added back the mpu_3xxx_clkdm
into the common clockdomains that was removed by
Hi Nishant,
On Fri, Jul 13, 2012 at 5:01 AM, Menon, Nishanth n...@ti.com wrote:
On Thu, Jun 14, 2012 at 9:53 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
[..]
--- a/arch/arm/mach-omap2/powerdomain-common.c
+++ b/arch/arm/mach-omap2/powerdomain-common.c
@@ -108,3 +108,74 @@ u32
On Fri, Jul 13, 2012 at 2:07 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
my Crib about the above apis are lack of logic power state handling :(
which forces code like cpuidle to use different apis for logic
power state and force them to use these apis just for pwrst.
Please look at the
Hi!
On Fri, Jul 13, 2012 at 7:29 AM, Menon, Nishanth n...@ti.com wrote:
On Fri, Jul 13, 2012 at 12:26 AM, Rajendra Nayak rna...@ti.com wrote:
On Friday 13 July 2012 08:31 AM, Menon, Nishanth wrote:
my Crib about the above apis are lack of logic power state handling:(
which forces code like
On Fri, Jul 13, 2012 at 2:18 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
[..]
Santosh pointed me to the thread offline. This is indeed a much better
approach IMHO than having 3 conflicting options inside powerdomain
framework.
After looking at the code and having sent my comments, I like
* Tony Lindgren t...@atomide.com [120712 23:46]:
* Mohammed, Afzal af...@ti.com [120712 23:19]:
Hi Tony,
On Tue, Jul 10, 2012 at 18:35:55, Tony Lindgren wrote:
The following changes since commit
6887a4131da3adaab011613776d865f4bcfb5678:
Linux 3.5-rc5 (2012-06-30 16:08:57
On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
Manufacturers can opt to use different codec than twl6040 and also can add
audio related IC to the bus (external amplifier for example on SDP4430).
Make it possible to add differnet set of additional devices to i2c1 bus on
Hello,
On 07/13/2012 10:01 AM, Peter Ujfalusi wrote:
On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
Manufacturers can opt to use different codec than twl6040 and also can add
audio related IC to the bus (external amplifier for example on SDP4430).
Make it
On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
Manufacturers can opt to use different codec than twl6040 and also can add
audio related IC to the bus (external amplifier for example on SDP4430).
Make it possible to add differnet set of additional devices to i2c1 bus on
This patch series adds support for PWM driver support for EHRPWM
and ECAP modules which has been present on AM335x SOC. AM335X SOC has 3
instances of ECAP EHRPWM.
EHRPWM device can be used to generate PWM waveforms. It has 2 channels of PWM
output and each can be configured for different duty
ECAP hardware on AM33XX SOC supports auxiliary PWM (APWM) feature. This
commit adds PWM driver support for ECAP hardware on AM33XX SOC.
In the ECAP hardware, each PWM pin can also be configured to be in
capture mode. Current implementation only supports PWM mode of
operation. Also, hardware
Enhanced high resolution PWM module (EHRPWM) hardware can be used to
generate PWM output over 2 channels. This commit adds PWM driver support
for EHRPWM device present on AM33XX SOC. Current implementation supports
simple PWM functionality.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
On Thursday 05 July 2012, Rajendra Nayak wrote:
[..]
From 5f5e4eb342110286bf719c7d9d7c1959f53e34f9 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak rna...@ti.com
Date: Thu, 5 Jul 2012 17:33:28 +0530
Subject: [RFC] ARM: OMAP: Powerdomain: control memory and logic bits
internally
Powerdomain
On Fri, Jul 13, 2012 at 05:43:30AM +, AnilKumar, Chimata wrote:
Thanks much, are you going to push reset of the patches in this series?
No, there's no dependency so I'd expect them to be applied by the
architecture maintainers.
signature.asc
Description: Digital signature
Hi,
I have started working on Audio support for TI AM335x SOC.
It uses the same McASP IP as in Davinci platform.
The mcasp driver (davinci-pcm) uses SRAM api's.
Currently OMAP Davinci have their own allocation systems, and both with
their own ways of copying functions into the SRAM.
A Patch
On Thu, Jul 12, 2012 at 03:08:16PM +0200, Guillaume Gardet wrote:
This patch add missing modules aliases to get sound working on omap devices.
Tested on Beagleboard xM rev. B.
This patch is against 3.5-rc6 vanilla.
Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Signed-off-by:
On Fri, Jul 13, 2012 at 3:38 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
Manufacturers can opt to use different codec than twl6040 and also can add
audio related IC to the bus (external amplifier for example on
On 07/13/2012 12:14 PM, Menon, Nishanth wrote:
We still need a way to switch to I2C highspeed mode
omap4_pmic_init still does register in 400KHz mode, while setting a bit in
6040
should let us talk 3.3MHz on the bus.
We need to have a way to do this runtime I think. The twl6040 comes up with
The random config builds with PM and !ARM_CPU_SUSPEND breaks with below
error on omap2plus_defconfig.
arch/arm/mach-omap2/sleep44xx.S:323: undefined reference to `cpu_resume'
arch/arm/mach-omap2/omap-mpuss-lowpower.c:278: undefined reference to
`cpu_suspend'
This is because recently merged
Hi Nishanth,
On Friday 13 July 2012 03:21 PM, Menon, Nishanth wrote:
On Thursday 05 July 2012, Rajendra Nayak wrote:
[..]
From 5f5e4eb342110286bf719c7d9d7c1959f53e34f9 Mon Sep 17 00:00:00 2001
From: Rajendra Nayakrna...@ti.com
Date: Thu, 5 Jul 2012 17:33:28 +0530
Subject: [RFC] ARM: OMAP:
On Thursday 12 July 2012 05:52 PM, Wolfram Sang wrote:
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
This has to wait a little bit until I can spend time on the recovery
framework (which is
On Thursday 12 July 2012 05:51 PM, Wolfram Sang wrote:
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Applied to next, thanks.
On Thursday 12 July 2012 05:50 PM, Wolfram Sang wrote:
+#include plat/omap_hwmod.h
Hmmm, so far the driver has no plat/mach dependencies and now this gets
added. Need to think about it a bit more...
OK .
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
On Thursday 12 July 2012 05:49 PM, Wolfram Sang wrote:
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Applied to next, thanks.
Thanks
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
-Original Message-
From: Paul Walmsley p...@pwsan.com
To: Joe Woodward j...@terrafix.co.uk
Cc: Kevin Hilman khil...@ti.com, linux-omap@vger.kernel.org
linux-omap@vger.kernel.org
Date: Thu, 12 Jul 2012 13:35:14 -0600 (MDT)
Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not
On Thursday 12 July 2012 05:48 PM, Wolfram Sang wrote:
On Thu, Jun 28, 2012 at 08:41:27PM +0530, Shubhrajyoti D wrote:
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Changed the title from
On Thursday 12 July 2012 06:22 PM, Wolfram Sang wrote:
On Mon, Jul 09, 2012 at 05:17:07PM +0530, Shubhrajyoti Datta wrote:
On Thu, Jun 28, 2012 at 8:41 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
This is a minimal cleanup series.
If there are no further comments can this series be queued?
I
From: Uwe Kleine-König u.kleine-koe...@pengutronix.de
This prepares of_device_id.data becoming const. Without this change
the following warning would occur:
drivers/i2c/busses/i2c-omap.c: In function 'omap_i2c_probe':
drivers/i2c/busses/i2c-omap.c:1025: warning: assignment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 Jul 2012 23:57:00 -0700
Tony Lindgren t...@atomide.com wrote:
* Dennis Gilmore den...@ausil.us [120711 06:53]:
On Wed, 11 Jul 2012 00:42:33 -0700
Tony Lindgren t...@atomide.com wrote:
Sounds like it's some kind of issue with
Hi!
On Thu, Jun 14, 2012 at 4:53 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
Here is a re-spin after some comments after an internal review and some
testing on
OMAP4 with device OFF support.
Implement the functional states for the power domains:
- unify the API to use the functional
Hi Paul,
On 07/12/2012 04:17 PM, Paul Walmsley wrote:
Hello Jon
On Thu, 7 Jun 2012, Jon Hunter wrote:
By removing the CLKDM_CAN_ENABLE_AUTO flag, the EMU clock domain will always
remain on and hence, this will break low-power modes. The EMU clock domain
only
support the SW_WKUP and
Hi Nishant, Rajendra,
On Fri, Jul 13, 2012 at 1:03 PM, Rajendra Nayak rna...@ti.com wrote:
Hi Nishanth,
On Friday 13 July 2012 03:21 PM, Menon, Nishanth wrote:
On Thursday 05 July 2012, Rajendra Nayak wrote:
[..]
From 5f5e4eb342110286bf719c7d9d7c1959f53e34f9 Mon Sep 17 00:00:00 2001
Jon,
[cutting out realms of context!]
On Fri, Jul 13, 2012 at 02:54:59PM +0100, Jon Hunter wrote:
Another proposal I also thought of is re-working the flags to describe
the HW mode to be used when turning on the CLKDM, when the CLKDM is
active and when the CLKDM is shut down. So instead of
Hi Will,
On 07/13/2012 09:00 AM, Will Deacon wrote:
Jon,
[cutting out realms of context!]
Thanks! My inbox thanks you too ;-)
On Fri, Jul 13, 2012 at 02:54:59PM +0100, Jon Hunter wrote:
Another proposal I also thought of is re-working the flags to describe
the HW mode to be used when
This works similarly to e.g. pwrdm_for_each(). Needed by enhanced
usecounting debug functionality that will be added to pm-debug.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/clock.c | 33
These are updated based on powerdomain usecounts. Also added support
for voltdm-sleep and voltdm-wakeup calls that will be invoked once
voltagedomain enters sleep or wakes up based on usecount numbers. These
will be used for controlling voltage scaling functionality.
Signed-off-by: Tero Kristo
This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of really active
clients on each domain. This patch also adds support for usecount
tracking on powerdomain level
mpu / core powerdomain usecounts are now statically increased
by 1 during MPU activity. This allows the domains to reflect
actual usage, and will allow the usecount to reach 0 just before
all CPUs are ready to idle. Proper powerdomain usecounts are
propageted to voltagedomain level also, and will
Some clockdomains bug out if their autodeps are deleted before idle.
This happens namely with OMAP3 PER domain, it will bug out if it
doesn't have wakedeps enabled when it enters off-mode. This patch
adds support for new flag 'CLKDM_NO_AUTODEP_DISABLE' which does this.
Signed-off-by: Tero Kristo
Hi,
Changes compared to previous version:
- added kerneldoc comments to new API functions
- added autoidle flagging support for omap3 dplls
- modified the clkdm code tweak required to fix omap3 per domain problems
* moved implementation to _clkdm_del_autodeps
* renamed the
sdrc_ick doesn't have autoidle flag on HW, but is always automatically
idled. Thus mark the autoidle flag statically as true for it to reflect
hardware behavior. The clock will no longer show as active in usecount
dumps and will allow the voltdm-sleep / wakeup calls to work properly.
Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to
their own file, 'usecount'. This file shows the usecounts for every
active domain and their children recursively. 'count' file now only
shows power state counts for powerdomains.
This patch also provices a way to do printk dumps
Previously, PER clock domain was always enabled, as the usecounts
for this domain incorrectly always showed positive value. On HW
level though, the domain enters idle as it is set in HW supervised
mode. Now, when the usecounts reflect real values, PER domain
will be put to HWSUP sleep mode, which
Add keypad data node in omap4 device tree file.
Also fill the device tree binding parameters
with the required value in omap4-sdp dts file.
Tested on omap4430 sdp with 3.5-rc6 kernel.
Cc: Tony Lindgren t...@atomide.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
If IVA2 DPLL is in low power stop mode, this will prevent IVA2
powerdomain sleep transition. Typically the DPLL is in locked
autoidle mode, which will allow sleep. With the wrong config,
the DPLL will end up in the wrong mode if IVA2 clock is first
enabled, then disabled by SW. This happens for
SAD2D stands for the die to die interface, and is used for communicating
with the optional stacked modem. This hwmod is added in preparation for
the d2d_idle move from pm34xx.c to hwmod data.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm-regbits-34xx.h |2 +
SAD2D module must be properly put to idle mode during boot, as if
there is no stacked modem with OMAP3, the pads can be left in a wrong
mode by the bootloader and this can prevent idle. Previously this
was done within pm34xx.c, but the code is now moved to the right
location.
This patch
Hi,
Following set moves some PRM related code away from PM core code to
PRM / HWMOD. This requires the hwmod cleanup set from Paul that
implements the setup_preprogram hooks for hwmods. Sending as RFC for
initial commenting.
This set does following:
- gets rid of the prcm interrupt handler from
PM code doesn't really care about the PRCM wakeup + io interrupts on
OMAP3, as these are used only for acking PRCM internal events, and the
IO chain handler is taken care of by hwmod code. Thus move the interrupt
handling logic from pm34xx.c to prm2xxx_3xxx.c file. This patch also
includes a minor
IVA2 hwmod resets were missing the status bit offsets. Also, as the
hwmod itself didn't have prcm info at all, resetting iva hwmod was
accessing some bogus memory addresses. Added both infos to fix this.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm-regbits-34xx.h |
IVA2 module must be properly put to idle mode during boot, as it is
possible that it is enabled by bootloader, and this will prevent
core retention/off. Previously this was done by an init time hook
from pm34xx.c file, but this functionality is now moved within
hwmod setup_preprogram hook for iva
Hi Jon
On Fri, 13 Jul 2012, Jon Hunter wrote:
On 07/12/2012 04:17 PM, Paul Walmsley wrote:
On Thu, 7 Jun 2012, Jon Hunter wrote:
Hmm, it would be nice if we could keep the CLKDM_CAN_* flags matching the
hardware capabilities. Looking at the 4430 TRM Rev X Table 3-744
On Fri, Jul 13, 2012 at 12:26:13PM -0600, Paul Walmsley wrote:
+ Mark
On Fri, 13 Jul 2012, Joe Woodward wrote:
Thanks Paul,
That patch does indeed seem to fix all my problems!
With it I can now suspend, and all power domains hit the target states.
OK, great. That patch is
Hi Vinod
On Fri, 13 Jul 2012, Vinod Koul wrote:
On Wed, 2012-06-27 at 15:20 +, Arnd Bergmann wrote:
[snip]
Do you mean there must be a global table, or are you ok with putting
the information about a channel into the device that uses the channel,
as we do for most other subsystems
This series adds device-tree support for the dmtimers on OMAP3/4 devices. Once
everyone is happy with the implementation I can add support for OMAP2/5 devices
too.
Testing:
- I have tested the all the dmtimers (not used by the kernel as sys-timers) on
both OMAP3430 Beagle and OMAP4460 Panda
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add documentation for timer properties specific to OMAP.
For each timer an alias is being added. The purpose for doing this is because
the OMAP dmtimer driver uses an ID to distinguish between the different
This series adds device-tree support for the timers on OMAP3/4 devices. Once
everyone is happy with the implementation I can add support for OMAP2/5 devices
too.
Testing:
- I have tested the all the timers (not used by the kernel as sys-timers) on
both OMAP3430 Beagle and OMAP4460 Panda
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add documentation for timer properties specific to OMAP.
For each timer an alias is being added. The purpose for doing this is because
the OMAP dmtimer driver uses an ID to distinguish between the different
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add documentation for timer properties specific to OMAP.
For each timer an alias is being added. The purpose for doing this is because
the OMAP dmtimer driver uses an ID to distinguish between the different
OMAP3 devices may or may not have security features enabled. Security enabled
devices are known as high-secure (HS) and devices without security are known as
general purpose (GP).
For OMAP3 devices there are 12 general purpose timers available. On secure
devices the 12th timer is reserved for
In order to add device-tree support to the timer driver the following changes
were made ...
1. If DT blob is present, then let HWMOD create the timer devices dynamically.
2. When device-tree is present the id field in the platform_device structure
(pdev-id) is initialised to -1 and the timer
In order to add device-tree support to the timer driver the following changes
were made ...
1. If DT blob is present, then let HWMOD create the timer devices dynamically.
2. When device-tree is present the id field in the platform_device structure
(pdev-id) is initialised to -1 and the timer
For OMAP4, the dmtimers are located in the Wake-up, ABE and Peripheral (PER)
power domains. Hence, when the dmtimer is configured to use the timer_sys_ck
as its functional clock the actual clock used is different depending on whether
the clock is in the Wake-up, ABE or PER domain. So when we
This series adds device-tree support for the timers on OMAP3/4 devices. Once
everyone is happy with the implementation I can add support for OMAP2/5 devices
too.
Testing:
- I have tested the all the timers (not used by the kernel as sys-timers) on
both OMAP3430 Beagle and OMAP4460 Panda
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add documentation for timer properties specific to OMAP.
For each timer an alias is being added. The purpose for doing this is because
the OMAP dmtimer driver uses an ID to distinguish between the different
OMAP3 devices may or may not have security features enabled. Security enabled
devices are known as high-secure (HS) and devices without security are known as
general purpose (GP).
For OMAP3 devices there are 12 general purpose timers available. On secure
devices the 12th timer is reserved for
Sorry for all the noise. I was having network problems in the midst of
sending and then I royally screwed it up by deciding to make some last
minute edits. So ignore this version of the series.
Jon
On 07/13/2012 05:19 PM, Jon Hunter wrote:
This series adds device-tree support for the timers on
For OMAP4, the dmtimers are located in the Wake-up, ABE and Peripheral (PER)
power domains. Hence, when the dmtimer is configured to use the timer_sys_ck
as its functional clock the actual clock used is different depending on whether
the clock is in the Wake-up, ABE or PER domain. So when we
In order to add device-tree support to the timer driver the following changes
were made ...
1. If DT blob is present, then let HWMOD create the timer devices dynamically.
2. When device-tree is present the id field in the platform_device structure
(pdev-id) is initialised to -1 and the timer
Hi
On Fri, 13 Jul 2012, Jon Hunter wrote:
1. If DT blob is present, then let HWMOD create the timer devices dynamically.
This probably should read is _not_ present, yes?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On 07/13/2012 06:41 PM, Paul Walmsley wrote:
Hi
On Fri, 13 Jul 2012, Jon Hunter wrote:
1. If DT blob is present, then let HWMOD create the timer devices
dynamically.
This probably should read is _not_ present, yes?
Yes, you are right. What a balls-up ...
Thanks
Jon
--
To unsubscribe
On 07/13/2012 05:26 PM, Jon Hunter wrote:
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add documentation for timer properties specific to OMAP.
For each timer an alias is being added. The purpose for doing this is because
the OMAP dmtimer
80 matches
Mail list logo
