Hi
On Fri, 13 Jul 2012, Rob Herring wrote:
> I'm not sure this is really a good use of aliases. UARTs use aliases
> because it is important that the UART number to tty number is known and
> fixed. IIUC, as an example you are picking timer1 because it has
> properties X, Y and Z. If so, then yo
> I'm not sure this is really a good use of aliases. UARTs use aliases
> because it is important that the UART number to tty number is known and
> fixed.
This brings up an issue that I've been meaning to comment on.
The use of phandle-valued properties in the aliases node causes real OFW
implemen
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
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
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 majord...@vg
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 look
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
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 secu
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 with/wit
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 look
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
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 secu
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
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 with/wit
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 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 with
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 subsys
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. Th
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
> > "CM
Calling the dmtimer function omap_dm_timer_set_source() fails if following a
call to pm_runtime_put() to disable the timer. For example the following
sequence would fail to set the parent clock ...
omap_dm_timer_stop(gptimer);
omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_32_KHZ
+ 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 basically a revert of
a819c4f16d5a2708c11e708fd59a96565c5384a8 ("ARM: OM
Hi Federico,
On Wed, Jul 11, 2012 at 10:14 AM, Federico Fuga wrote:
> it triggers a BUG() in drivers/base/driver.c line 169
Thanks for sharing this; it definitely makes sense now.
> The subsys_initcall indeed solve this issue
I agree. I'll take it, but will change the commit log to make it
oma
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 h
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
---
arch/arm/mach-omap2/cm-regbits-34xx.h |1 +
arch/arm
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
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 p
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 introduces
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
---
arch/arm/mach-omap2/cm-regbits-34xx.h |2 +
arch/arm/mach-omap2/
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 exa
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
Cc: Benoit Cousson
Cc: Rob Herring
Cc: Grant Likely
Cc: Felipe Balbi
Signed-off-by: Sour
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 m
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 fr
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.
Signed-off-b
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 CLKDM_SKIP_MANUAL_TRA
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 a
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 and
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 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
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/plat-omap/clock.c | 33 +++
arch/arm/plat-omap
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 w
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 Nishant, Rajendra,
On Fri, Jul 13, 2012 at 1:03 PM, Rajendra Nayak 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
>
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_W
Hi!
On Thu, Jun 14, 2012 at 4:53 PM, Jean Pihet 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 states,
> - protect th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 Jul 2012 23:57:00 -0700
Tony Lindgren wrote:
> * Dennis Gilmore [120711 06:53]:
> > On Wed, 11 Jul 2012 00:42:33 -0700
> > Tony Lindgren wrote:
> > >
> > > Sounds like it's some kind of issue with dtb getting overwritten
> > > by someth
OMAP4 sleep entry code even though itself don't use many CPU registers
makes call to the v7_flush_dcache_all() which uses them. Since
v7_flush_dcache_all() doesn't make use of stack, the caller must take
care of the stack frame. Otherwise it will lead to corrupted stack frame.
Fix it by saving use
Hello,
On Fri, Jul 13, 2012 at 02:32:02PM +0200, y...@pengutronix.de wrote:
This is utter non-sense, it was me who sent these mails (and pressed 'y'
when git send-email asked if "Uwe Kleine-König
" is the right sender). Please make sure
to correct this when replying to the patches.
Sorry for the
From: Uwe Kleine-König
This prepares of_device_id.data becoming const. Without this change
the following warning would occur:
drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_probe':
drivers/mmc/host/omap_hsmmc.c:1808: warning: initialization discards
qualifiers from point
From: Uwe Kleine-König
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 discards
qualifiers from pointer tar
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 wrote:
>>> This is a minimal cleanup series.
>> If there are no further comments can this series be queued?
> I just appli
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
> Changed the title from "optimise" to "
-Original Message-
From: Paul Walmsley
To: Joe Woodward
Cc: Kevin Hilman , "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 built with RTC?
> Hello Joe,
>
> On Thu, 12 Jul 2012, Joe Woodward wrote:
On Thursday 12 July 2012 05:49 PM, Wolfram Sang wrote:
>> Reviewed-by: Felipe Balbi
>> > Signed-off-by: Shubhrajyoti D
> Applied to next, thanks.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo in
On Thursday 12 July 2012 05:50 PM, Wolfram Sang wrote:
>> +#include
> 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 message to majo
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
>> > Signed-off-by: Jon Hunter
>> > Signed-off-by: Shubhrajyoti D
> Applied to next, thanks.
Thanks.
--
To unsubscribe from this li
On Thursday 12 July 2012 05:52 PM, Wolfram Sang wrote:
>> Signed-off-by: Vikram Pandita
>> > Signed-off-by: Jon Hunter
>> > Signed-off-by: Shubhrajyoti D
> This has to wait a little bit until I can spend time on the recovery
> framework (which is still in the queue, sadly :( ). There might be so
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 Nayak
Date: Thu, 5 Jul 2012 17:33:28 +0530
Subject: [RFC] ARM: OMAP: Powerdomain: cont
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 OMAP5
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 w
On Fri, Jul 13, 2012 at 3:38 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 po
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
> Signed-off-by: Mans Rullgard
>
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 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
On Thursday 05 July 2012, Rajendra Nayak wrote:
[..]
> From 5f5e4eb342110286bf719c7d9d7c1959f53e34f9 Mon Sep 17 00:00:00 2001
> From: Rajendra Nayak
> Date: Thu, 5 Jul 2012 17:33:28 +0530
> Subject: [RFC] ARM: OMAP: Powerdomain: control memory and logic bits
> internally
>
> Powerdomain framework
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
Reviewed-by: Vaibhav Bedi
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 suppor
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 cy
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 pos
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
* Tony Lindgren [120712 23:46]:
> * Mohammed, Afzal [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)
> > >
On Fri, Jul 13, 2012 at 2:18 AM, Jean Pihet 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 it ...
> mainly beca
Hi!
On Fri, Jul 13, 2012 at 7:29 AM, Menon, Nishanth wrote:
> On Fri, Jul 13, 2012 at 12:26 AM, Rajendra Nayak 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 cpuidle to use
On Fri, Jul 13, 2012 at 2:07 AM, Jean Pihet 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 rest of the series.
Hi Nishant,
On Fri, Jul 13, 2012 at 5:01 AM, Menon, Nishanth wrote:
> On Thu, Jun 14, 2012 at 9:53 AM, Jean Pihet wrote:
> [..]
>> --- a/arch/arm/mach-omap2/powerdomain-common.c
>> +++ b/arch/arm/mach-omap2/powerdomain-common.c
>> @@ -108,3 +108,74 @@ u32 omap2_pwrdm_get_mem_bank_stst_mask(u8 ba
* Tony Lindgren [120712 23:48]:
> * Kevin Hilman [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:
>
80 matches
Mail list logo
