* [PATCH v2 0/5] zynq clk support
From: Soren Brinkmann @ 2012-11-08 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1352400580.git.josh.cartwright@ni.com>
Hi Josh,
did you also have a look at what is available in the Xilinx git repository?
There are also quite some patches to support common clock and port drivers over
to using it.
It would be great if we could combine our efforts instead of ending up with
competing solutions.
Thanks,
Soren
^ permalink raw reply
* [PATCH 14/26] ARM: OMAP3: clock: Add 3xxx data using common struct clk
From: Paul Walmsley @ 2012-11-09 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211082158310.20703@utopia.booyaka.com>
On Thu, 8 Nov 2012, Paul Walmsley wrote:
> On Thu, 8 Nov 2012, Paul Walmsley wrote:
>
> > Am seeing warnings during the disable-unused-clocks phase of the boot on
> > the OMAP3 test boards here.
>
> Similar problems during system suspend on 3530ES3 Beagle. Not sure
> what's causing these yet. At this point the clockdomain usecounts
> should be accurate.
Here's a redacted debugging log for these cases. The suspend events start
around the 30 second mark.
One observation is that dpll4_m5x2_ck and dpll4_m6x2_ck are never enabled.
The tracebacks occur when something in the suspend path tries to disable
those clocks.
- Paul
[ 0.135528] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
[ 0.135559] clockdomain: dpll4_clkdm: enabled
[ 0.135589] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[ 0.135681] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
[ 0.135681] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck
[ 0.135711] clockdomain: dpll4_clkdm: disabled
[ 0.135772] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
[ 0.135803] clockdomain: dpll4_clkdm: enabled
[ 0.135833] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[ 0.135894] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
[ 0.135925] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck
[ 0.135955] clockdomain: dpll4_clkdm: disabled
[ 0.135986] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
[ 0.136016] clockdomain: dpll4_clkdm: enabled
[ 0.136047] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[ 0.136138] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
[ 0.136169] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck
[ 0.136169] clockdomain: dpll4_clkdm: disabled
[ 0.136260] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
[ 0.136291] clockdomain: dpll4_clkdm: enabled
[ 0.136322] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[ 0.140594] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck
[ 0.140686] enabling clkdm dpll4_clkdm during enable of clk dpll4_m3x2_ck
[ 0.140838] disabling clkdm dpll4_clkdm during disable of clk dpll4_m3x2_ck
[ 0.140930] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck
[ 0.141479] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck
[ 0.141571] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck
[ 0.141601] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck
[ 0.141662] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck
[ 0.141693] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck
[ 0.141784] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck
[ 0.141815] enabling clkdm dpll4_clkdm during enable of clk dpll4_m3x2_ck
[ 0.141876] disabling clkdm dpll4_clkdm during disable of clk dpll4_m3x2_ck
[ 3.399200] disabling clkdm dpll4_clkdm during disable of clk dpll4_m6x2_ck
[ 3.417694] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
[ 3.445251] ---[ end trace 72e2d7bdcf98ea8b ]---
[ 3.450134] disabling clkdm dpll4_clkdm during disable of clk dpll4_m5x2_ck
[ 3.453918] clockdomain: dpll4_clkdm: disabled
[ 3.477569] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
[ 3.505096] ---[ end trace 72e2d7bdcf98ea8c ]---
[ 3.531280] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
[ 3.558807] ---[ end trace 72e2d7bdcf98ea8d ]---
[ 38.999145] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
[ 38.999267] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
[ 38.999816] ---[ end trace 72e2d7bdcf98ea8e ]---
[ 38.999816] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck
[ 38.999908] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
[ 39.000366] ---[ end trace 72e2d7bdcf98ea8f ]---
[ 42.169647] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
[ 42.169647] clockdomain: dpll4_clkdm: enabled
[ 42.169677] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[ 45.730346] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
[ 45.795654] ---[ end trace 72e2d7bdcf98ea90 ]---
^ permalink raw reply
* [PATCH] ARM: OMAP: Fix kernel panic in dmtimer probe
From: Jon Hunter @ 2012-11-09 0:17 UTC (permalink / raw)
To: linux-arm-kernel
When booting with device-tree the kernel is panicing in the probe of the
DMTIMER driver. The panic is caused because the pointer to platform_data
structure is NULL when booting with device-tree and the driver is
attempting to access the structure without checking if the pointer is
valid.
Fix this by moving the code that accesses the platform data structure
under the "else" clause of the "if (dev->of_node)" statement because
here the pointer to platform_data is guaranteed to be valid. The code
accessing the "timer_capability" member of the platform data is simply
removed as this is already handled under the else clause.
This regression was introduced while integrating commit "ARM: OMAP: Add
DT support for timer driver" to add device-tree support to the DMTIMER
driver and commit "ARM: OMAP: Move omap-pm-noop.c local to mach-omap2"
to prepare for single zImage support.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/plat-omap/dmtimer.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 38c12ef..9dca23e 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
timer->id = pdev->id;
timer->capability = pdata->timer_capability;
timer->reserved = omap_dm_timer_reserved_systimer(timer->id);
+ timer->get_context_loss_count = pdata->get_context_loss_count;
}
timer->irq = irq->start;
timer->pdev = pdev;
- timer->capability = pdata->timer_capability;
- timer->get_context_loss_count = pdata->get_context_loss_count;
/* Skip pm_runtime_enable for OMAP1 */
if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
--
1.7.9.5
^ permalink raw reply related
* [GIT PULL] ARM: OMAP: Timer and Counter DT Updates for v3.8
From: Jon Hunter @ 2012-11-09 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509C0C3E.6070204@ti.com>
On 11/08/2012 01:47 PM, Jon Hunter wrote:
> Do you want to generate the patch or me?
Patch posted here ...
http://marc.info/?l=linux-omap&m=135242025202171&w=2
Cheers
Jon
^ permalink raw reply
* [PATCH 14/26] ARM: OMAP3: clock: Add 3xxx data using common struct clk
From: Paul Walmsley @ 2012-11-09 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211090002380.20703@utopia.booyaka.com>
On Fri, 9 Nov 2012, Paul Walmsley wrote:
> One observation is that dpll4_m5x2_ck and dpll4_m6x2_ck are never enabled.
> The tracebacks occur when something in the suspend path tries to disable
> those clocks.
Sorry, this part is inaccurate - I misread the trace. The suspend path
errors are coming from a disable of dpll4_m2x2_ck which is probably caused
by the disable of i2c1_fck. Here's the unredacted trace of this section.
The enables and disables of dpll4_m2x2_ck from the entire log appear to be balanced:
[ 0.135589] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[ 0.135681] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
[ 0.135833] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[ 0.135894] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
[ 0.136047] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[ 0.136138] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
[ 0.136322] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
[ 38.999145] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
- Paul
[ 38.986267] PM: suspend of devices complete after 129.760 msecs
[ 38.991668] PM: late suspend of devices complete after 5.340 msecs
[ 38.996459] disabling clkdm core_l4_clkdm during disable of clk mmchs1_fck
[ 38.998718] disabling clkdm per_clkdm during disable of clk uart3_fck
[ 38.998840] disabling clkdm core_l4_clkdm during disable of clk uart2_fck
[ 38.998931] disabling clkdm core_l4_clkdm during disable of clk uart1_fck
[ 38.999114] disabling clkdm core_l4_clkdm during disable of clk i2c1_fck
[ 38.999145] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
[ 38.999145] ------------[ cut here ]------------
[ 38.999206] WARNING: at arch/arm/mach-omap2/clockdomain.c:962 _clkdm_clk_hwmod_disable+0xa4/0xf8()
[ 38.999206] Modules linked in:
[ 38.999267] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
[ 38.999298] [<c0043680>] (warn_slowpath_common+0x4c/0x64) from [<c00436b4>] (warn_slowpath_null+0x1c/0x24)
[ 38.999328] [<c00436b4>] (warn_slowpath_null+0x1c/0x24) from [<c003695c>] (_clkdm_clk_hwmod_disable+0xa4/0xf8)
[ 38.999359] [<c003695c>] (_clkdm_clk_hwmod_disable+0xa4/0xf8) from [<c0437d38>] (__clk_disable+0x70/0xac)
[ 38.999389] [<c0437d38>] (__clk_disable+0x70/0xac) from [<c0437d94>] (clk_disable+0x20/0x34)
[ 38.999420] [<c0437d94>] (clk_disable+0x20/0x34) from [<c002a330>] (_disable_clocks+0x18/0x68)
[ 38.999420] [<c002a330>] (_disable_clocks+0x18/0x68) from [<c002b09c>] (_idle+0xf8/0x1b4)
[ 38.999450] [<c002b09c>] (_idle+0xf8/0x1b4) from [<c002bf08>] (omap_hwmod_idle+0x24/0x40)
[ 38.999481] [<c002bf08>] (omap_hwmod_idle+0x24/0x40) from [<c002ce34>] (omap_device_idle_hwmods+0x24/0x3c)
[ 38.999511] [<c002ce34>] (omap_device_idle_hwmods+0x24/0x3c) from [<c002d024>] (_omap_device_deactivate+0x9c/0x138)
[ 38.999511] [<c002d024>] (_omap_device_deactivate+0x9c/0x138) from [<c002d984>] (omap_device_idle+0x28/0x54)
[ 38.999542] [<c002d984>] (omap_device_idle+0x28/0x54) from [<c002da48>] (_od_suspend_noirq+0x74/0x7c)
[ 38.999572] [<c002da48>] (_od_suspend_noirq+0x74/0x7c) from [<c034cc6c>] (dpm_run_callback.clone.9+0x30/0xb4)
[ 38.999603] [<c034cc6c>] (dpm_run_callback.clone.9+0x30/0xb4) from [<c034d4c0>] (dpm_suspend_end+0x364/0x554)
[ 38.999603] [<c034d4c0>] (dpm_suspend_end+0x364/0x554) from [<c0084f48>] (suspend_devices_and_enter+0xbc/0x2d0)
[ 38.999633] [<c0084f48>] (suspend_devices_and_enter+0xbc/0x2d0) from [<c00852e8>] (pm_suspend+0x18c/0x208)
[ 38.999664] [<c00852e8>] (pm_suspend+0x18c/0x208) from [<c008457c>] (state_store+0x120/0x134)
[ 38.999694] [<c008457c>] (state_store+0x120/0x134) from [<c02d2a38>] (kobj_attr_store+0x14/0x20)
[ 38.999725] [<c02d2a38>] (kobj_attr_store+0x14/0x20) from [<c017a6b8>] (sysfs_write_file+0x100/0x184)
[ 38.999755] [<c017a6b8>] (sysfs_write_file+0x100/0x184) from [<c01166b8>] (vfs_write+0xb4/0x148)
[ 38.999755] [<c01166b8>] (vfs_write+0xb4/0x148) from [<c011693c>] (sys_write+0x40/0x6c)
[ 38.999786] [<c011693c>] (sys_write+0x40/0x6c) from [<c0013ee0>] (ret_fast_syscall+0x0/0x3c)
[ 38.999816] ---[ end trace 72e2d7bdcf98ea8e ]---
[ 38.999816] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck
[ 38.999847] ------------[ cut here ]------------
[ 38.999847] WARNING: at arch/arm/mach-omap2/clockdomain.c:962 _clkdm_clk_hwmod_disable+0xa4/0xf8()
[ 38.999877] Modules linked in:
[ 38.999908] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
[ 38.999938] [<c0043680>] (warn_slowpath_common+0x4c/0x64) from [<c00436b4>] (warn_slowpath_null+0x1c/0x24)
[ 38.999938] [<c00436b4>] (warn_slowpath_null+0x1c/0x24) from [<c003695c>] (_clkdm_clk_hwmod_disable+0xa4/0xf8)
[ 38.999969] [<c003695c>] (_clkdm_clk_hwmod_disable+0xa4/0xf8) from [<c0437d38>] (__clk_disable+0x70/0xac)
[ 38.999999] [<c0437d38>] (__clk_disable+0x70/0xac) from [<c0437d94>] (clk_disable+0x20/0x34)
[ 38.999999] [<c0437d94>] (clk_disable+0x20/0x34) from [<c002a330>] (_disable_clocks+0x18/0x68)
[ 39.000030] [<c002a330>] (_disable_clocks+0x18/0x68) from [<c002b09c>] (_idle+0xf8/0x1b4)
[ 39.000061] [<c002b09c>] (_idle+0xf8/0x1b4) from [<c002bf08>] (omap_hwmod_idle+0x24/0x40)
[ 39.000061] [<c002bf08>] (omap_hwmod_idle+0x24/0x40) from [<c002ce34>] (omap_device_idle_hwmods+0x24/0x3c)
[ 39.000091] [<c002ce34>] (omap_device_idle_hwmods+0x24/0x3c) from [<c002d024>] (_omap_device_deactivate+0x9c/0x138)
[ 39.000122] [<c002d024>] (_omap_device_deactivate+0x9c/0x138) from [<c002d984>] (omap_device_idle+0x28/0x54)
[ 39.000152] [<c002d984>] (omap_device_idle+0x28/0x54) from [<c002da48>] (_od_suspend_noirq+0x74/0x7c)
[ 39.000152] [<c002da48>] (_od_suspend_noirq+0x74/0x7c) from [<c034cc6c>] (dpm_run_callback.clone.9+0x30/0xb4)
[ 39.000183] [<c034cc6c>] (dpm_run_callback.clone.9+0x30/0xb4) from [<c034d4c0>] (dpm_suspend_end+0x364/0x554)
[ 39.000213] [<c034d4c0>] (dpm_suspend_end+0x364/0x554) from [<c0084f48>] (suspend_devices_and_enter+0xbc/0x2d0)
[ 39.000213] [<c0084f48>] (suspend_devices_and_enter+0xbc/0x2d0) from [<c00852e8>] (pm_suspend+0x18c/0x208)
[ 39.000244] [<c00852e8>] (pm_suspend+0x18c/0x208) from [<c008457c>] (state_store+0x120/0x134)
[ 39.000274] [<c008457c>] (state_store+0x120/0x134) from [<c02d2a38>] (kobj_attr_store+0x14/0x20)
[ 39.000274] [<c02d2a38>] (kobj_attr_store+0x14/0x20) from [<c017a6b8>] (sysfs_write_file+0x100/0x184)
[ 39.000305] [<c017a6b8>] (sysfs_write_file+0x100/0x184) from [<c01166b8>] (vfs_write+0xb4/0x148)
[ 39.000335] [<c01166b8>] (vfs_write+0xb4/0x148) from [<c011693c>] (sys_write+0x40/0x6c)
[ 39.000366] [<c011693c>] (sys_write+0x40/0x6c) from [<c0013ee0>] (ret_fast_syscall+0x0/0x3c)
[ 39.000366] ---[ end trace 72e2d7bdcf98ea8f ]---
[ 39.000823] disabling clkdm wkup_clkdm during disable of clk gpio1_ick
[ 39.000976] PM: noirq suspend of devices complete after 9.307 msecs
[ 39.001068] Disabling non-boot CPUs ...
^ permalink raw reply
* [PATCH 14/26] ARM: OMAP3: clock: Add 3xxx data using common struct clk
From: Paul Walmsley @ 2012-11-09 0:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211090028250.20703@utopia.booyaka.com>
On Fri, 9 Nov 2012, Paul Walmsley wrote:
> The enables and disables of dpll4_m2x2_ck from the entire log appear to be balanced:
Looks like this is an artifact of the disable-unused-clocks problem. The
disable of dpll4_m6x2_ck during that phase removes the usecount that was
previously added by the enable of dpll4_m2x2_ck. So fixing that problem
should clean this one up.
- Paul
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Jon Hunter @ 2012-11-09 0:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB686AC@DBDE01.ent.ti.com>
On 11/08/2012 12:06 PM, Hiremath, Vaibhav wrote:
> On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote:
>>
>> On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote:
>>> On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote:
>>
>> [snip]
>>
>>>> I think you are missing the point here. For OMAP devices we have two
>>>> main external clock sources which are the 32kHz clock and the sys_clk
>>>> (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is
>>>> for OMAP these clock sources are always present and AFAIK there is no
>>>> h/w configuration that allows you not to have the 32kHz clock source.
>>>> PRCM needs it and I think for OMAP1 the reset logic needs it (if memory
>>>> serves).
>>>>
>>>> Igor was mentioning a h/w scenario where the 32kHz source is not
>>>> present. However, I am not sure which devices support this and is
>>>> applicable too.
>>>>
>>>> So we are not discussing the 32k-sync-timer here. We are discussing
>>>> whether there are any device configurations where a 32k clock source
>>>> would not be available for the gptimer.
>>>>
>>>
>>> Exactly that is the point I am trying to make here,
>>>
>>> In case of AM33xx, it is certainly possible to build the system without
>>> this 32Khz clock.
>>>
>>> Interesting point here is, this 32KHz clock is external clock coming from
>>> crystal connected to in-built RTC module.
>>
>> Thanks. Looking at the AM3358 data manual it states ...
>>
>> "The OSC1 oscillator provides a 32.768-kHz reference clock to the
>> real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT
>> terminals. OSC1 is disabled by default after power is applied. This
>> clock input is optional and may not be required if the RTC is configured
>> to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or
>> peripheral PLL (CLK_32KHZ) which receives a reference clock from the
>> OSC0 input."
>>
>> So what is clear to me that an external 32k clock source is optional.
>> However, it still appears that you will always have an internal 32k
>> source and so regardless of the h/w configuration, a gptimer will always
>> have an 32k clock available on the AM335x devices. Is that correct?
>>
>
> Internal RC oscillator is not accurate at all, so not guaranteed to give
> accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz.
>
> So it may not be useful as a system clocks, right?
By the way, according to the AM3358 data manual (paragraph above), even
if there is no external 32k clock source and if you don't use the
internal 32k oscillator, you can still generate a 32k clock from the PER
PLL (CLK_32KHZ). So therefore, there should always be a 32k clock source
available for the gptimer. Is that correct?
At the end of the day, I am just trying to understand if any OMAP/AM
device supports a h/w configuration where there is no 32k clock source
available for the gptimer.
Jon
^ permalink raw reply
* [PATCH 14/26] ARM: OMAP3: clock: Add 3xxx data using common struct clk
From: Mike Turquette @ 2012-11-09 0:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211090002380.20703@utopia.booyaka.com>
Quoting Paul Walmsley (2012-11-08 16:11:12)
> On Thu, 8 Nov 2012, Paul Walmsley wrote:
>
> > On Thu, 8 Nov 2012, Paul Walmsley wrote:
> >
> > > Am seeing warnings during the disable-unused-clocks phase of the boot on
> > > the OMAP3 test boards here.
> >
> > Similar problems during system suspend on 3530ES3 Beagle. Not sure
> > what's causing these yet. At this point the clockdomain usecounts
> > should be accurate.
>
> Here's a redacted debugging log for these cases. The suspend events start
> around the 30 second mark.
>
> One observation is that dpll4_m5x2_ck and dpll4_m6x2_ck are never enabled.
> The tracebacks occur when something in the suspend path tries to disable
> those clocks.
Hi Paul,
My instrumentation shows that dpll4_ck & dpll4_m2x2_ck are triggering
the WARNs:
[ 25.214599] _clkdm_clk_hwmod_disable: dpll4_m2x2_ck
[ 25.214599] ------------[ cut here ]------------
[ 25.214660] WARNING: at arch/arm/mach-omap2/clockdomain.c:967
_clkdm_clk_hwmod_disable+0xd0/0x118()
...
[ 25.215209] _clkdm_clk_hwmod_disable: dpll4_ck
[ 25.215209] ------------[ cut here ]------------
[ 25.215240] WARNING: at arch/arm/mach-omap2/clockdomain.c:967
_clkdm_clk_hwmod_disable+0xd0/0x118()
Patch that give that information:
diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
index 64e5046..a9d5965 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -947,7 +947,8 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)
return 0;
}
-static int _clkdm_clk_hwmod_disable(struct clockdomain *clkdm)
+static int _clkdm_clk_hwmod_disable(struct clockdomain *clkdm,
+ struct clk *clk)
{
unsigned long flags;
@@ -957,6 +958,9 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain *clkdm)
spin_lock_irqsave(&clkdm->lock, flags);
if (atomic_read(&clkdm->usecount) == 0) {
+ if (clk)
+ pr_err("%s: %s\n", __func__, __clk_get_name(clk));
+
spin_unlock_irqrestore(&clkdm->lock, flags);
WARN_ON(1); /* underflow */
return -ERANGE;
@@ -1026,7 +1030,7 @@ int clkdm_clk_disable(struct clockdomain *clkdm, struct clk *clk)
if (!clk)
return -EINVAL;
- return _clkdm_clk_hwmod_disable(clkdm);
+ return _clkdm_clk_hwmod_disable(clkdm, clk);
}
/**
@@ -1089,6 +1093,6 @@ int clkdm_hwmod_disable(struct clockdomain *clkdm, struct omap_hwmod *oh)
if (!oh)
return -EINVAL;
- return _clkdm_clk_hwmod_disable(clkdm);
+ return _clkdm_clk_hwmod_disable(clkdm, NULL);
}
Regards,
Mike
>
>
> - Paul
>
> [ 0.135528] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
> [ 0.135559] clockdomain: dpll4_clkdm: enabled
> [ 0.135589] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
> [ 0.135681] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
> [ 0.135681] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck
> [ 0.135711] clockdomain: dpll4_clkdm: disabled
> [ 0.135772] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
> [ 0.135803] clockdomain: dpll4_clkdm: enabled
> [ 0.135833] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
> [ 0.135894] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
> [ 0.135925] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck
> [ 0.135955] clockdomain: dpll4_clkdm: disabled
> [ 0.135986] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
> [ 0.136016] clockdomain: dpll4_clkdm: enabled
> [ 0.136047] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
> [ 0.136138] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
> [ 0.136169] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck
> [ 0.136169] clockdomain: dpll4_clkdm: disabled
> [ 0.136260] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
> [ 0.136291] clockdomain: dpll4_clkdm: enabled
> [ 0.136322] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
> [ 0.140594] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck
> [ 0.140686] enabling clkdm dpll4_clkdm during enable of clk dpll4_m3x2_ck
> [ 0.140838] disabling clkdm dpll4_clkdm during disable of clk dpll4_m3x2_ck
> [ 0.140930] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck
> [ 0.141479] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck
> [ 0.141571] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck
> [ 0.141601] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck
> [ 0.141662] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck
> [ 0.141693] enabling clkdm dpll4_clkdm during enable of clk dpll4_m4x2_ck
> [ 0.141784] disabling clkdm dpll4_clkdm during disable of clk dpll4_m4x2_ck
> [ 0.141815] enabling clkdm dpll4_clkdm during enable of clk dpll4_m3x2_ck
> [ 0.141876] disabling clkdm dpll4_clkdm during disable of clk dpll4_m3x2_ck
> [ 3.399200] disabling clkdm dpll4_clkdm during disable of clk dpll4_m6x2_ck
> [ 3.417694] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
> [ 3.445251] ---[ end trace 72e2d7bdcf98ea8b ]---
> [ 3.450134] disabling clkdm dpll4_clkdm during disable of clk dpll4_m5x2_ck
> [ 3.453918] clockdomain: dpll4_clkdm: disabled
> [ 3.477569] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
> [ 3.505096] ---[ end trace 72e2d7bdcf98ea8c ]---
> [ 3.531280] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
> [ 3.558807] ---[ end trace 72e2d7bdcf98ea8d ]---
> [ 38.999145] disabling clkdm dpll4_clkdm during disable of clk dpll4_m2x2_ck
> [ 38.999267] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
> [ 38.999816] ---[ end trace 72e2d7bdcf98ea8e ]---
> [ 38.999816] disabling clkdm dpll4_clkdm during disable of clk dpll4_ck
> [ 38.999908] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
> [ 39.000366] ---[ end trace 72e2d7bdcf98ea8f ]---
> [ 42.169647] enabling clkdm dpll4_clkdm during enable of clk dpll4_ck
> [ 42.169647] clockdomain: dpll4_clkdm: enabled
> [ 42.169677] enabling clkdm dpll4_clkdm during enable of clk dpll4_m2x2_ck
> [ 45.730346] [<c001c1cc>] (unwind_backtrace+0x0/0xf0) from [<c0043680>] (warn_slowpath_common+0x4c/0x64)
> [ 45.795654] ---[ end trace 72e2d7bdcf98ea90 ]---
^ permalink raw reply related
* [PATCH] ARM: OMAP2+: clockdomain: disabling unused clks
From: Paul Walmsley @ 2012-11-09 0:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352417516-15213-1-git-send-email-mturquette@ti.com>
On Thu, 8 Nov 2012, Mike Turquette wrote:
> The OMAP port to the common clk framework[1] resulted in spurious WARNs
> while disable unused clocks. This is due to _clkdm_clk_hwmod_disable
> catching clkdm->usecount's with a value of zero. Even less desirable it
> would not allow the clkdm_clk_disable function pointer to get called due
> to an early return of -ERANGE.
>
> This patch adds a check for such a corner case by skipping the WARN and
> early return in the event that clkdm->usecount and clk->enable_usecount
> are both zero. Presumably this could only happen during the check for
> unused clocks at boot-time.
>
> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/88824
>
> Signed-off-by: Mike Turquette <mturquette@ti.com>
I don't think this is going to work, as it currently stands. The code
will just bypass the warning and the error return. The clockdomain
usecount still will be decremented, which is going to cause problems since
the usecount will be inaccurate.
- Paul
^ permalink raw reply
* [PATCH] ARM: OMAP: Fix kernel panic in dmtimer probe
From: Jon Hunter @ 2012-11-09 1:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352420243-31803-1-git-send-email-jon-hunter@ti.com>
On 11/08/2012 06:17 PM, Jon Hunter wrote:
> When booting with device-tree the kernel is panicing in the probe of the
> DMTIMER driver. The panic is caused because the pointer to platform_data
> structure is NULL when booting with device-tree and the driver is
> attempting to access the structure without checking if the pointer is
> valid.
>
> Fix this by moving the code that accesses the platform data structure
> under the "else" clause of the "if (dev->of_node)" statement because
> here the pointer to platform_data is guaranteed to be valid. The code
> accessing the "timer_capability" member of the platform data is simply
> removed as this is already handled under the else clause.
>
> This regression was introduced while integrating commit "ARM: OMAP: Add
> DT support for timer driver" to add device-tree support to the DMTIMER
> driver and commit "ARM: OMAP: Move omap-pm-noop.c local to mach-omap2"
> to prepare for single zImage support.
By the way, I meant to add ...
Reported-by: Tony Lindgren <tony@atomide.com>
Jon
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
> arch/arm/plat-omap/dmtimer.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> index 38c12ef..9dca23e 100644
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
> timer->id = pdev->id;
> timer->capability = pdata->timer_capability;
> timer->reserved = omap_dm_timer_reserved_systimer(timer->id);
> + timer->get_context_loss_count = pdata->get_context_loss_count;
> }
>
> timer->irq = irq->start;
> timer->pdev = pdev;
> - timer->capability = pdata->timer_capability;
> - timer->get_context_loss_count = pdata->get_context_loss_count;
>
> /* Skip pm_runtime_enable for OMAP1 */
> if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: clockdomain: disabling unused clks
From: Mike Turquette @ 2012-11-09 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211090052100.20703@utopia.booyaka.com>
Quoting Paul Walmsley (2012-11-08 16:58:21)
> On Thu, 8 Nov 2012, Mike Turquette wrote:
>
> > The OMAP port to the common clk framework[1] resulted in spurious WARNs
> > while disable unused clocks. This is due to _clkdm_clk_hwmod_disable
> > catching clkdm->usecount's with a value of zero. Even less desirable it
> > would not allow the clkdm_clk_disable function pointer to get called due
> > to an early return of -ERANGE.
> >
> > This patch adds a check for such a corner case by skipping the WARN and
> > early return in the event that clkdm->usecount and clk->enable_usecount
> > are both zero. Presumably this could only happen during the check for
> > unused clocks at boot-time.
> >
> > [1] http://article.gmane.org/gmane.linux.ports.arm.omap/88824
> >
> > Signed-off-by: Mike Turquette <mturquette@ti.com>
>
> I don't think this is going to work, as it currently stands. The code
> will just bypass the warning and the error return. The clockdomain
> usecount still will be decremented, which is going to cause problems since
> the usecount will be inaccurate.
>
You're right. In my rush I glossed over the clkdm decrement part. In
light of the suspend/resume issues I'm not sure this approach is really
valid. I think getting to the bottom of those issues will give the
final word.
Regards,
Mike
>
> - Paul
^ permalink raw reply
* [PATCH 06/11] ARM: pxa: convert timer suspend/resume to clock_event_device
From: Eric Miao @ 2012-11-09 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352408516-21988-8-git-send-email-swarren@wwwdotorg.org>
On Fri, Nov 9, 2012 at 5:01 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Move PXA's timer suspend/resume functions from struct sys_timer
> pxa_timer into struct clock_event_device ckevt_pxa_osmr0. This
> will allow the sys_timer suspend/resume fields to be removed, and
> eventually lead to a complete removal of struct sys_timer.
>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
> ---
> arch/arm/mach-pxa/time.c | 76 +++++++++++++++++++++++-----------------------
> 1 files changed, 38 insertions(+), 38 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/time.c b/arch/arm/mach-pxa/time.c
> index 4bc47d6..ce58bc9 100644
> --- a/arch/arm/mach-pxa/time.c
> +++ b/arch/arm/mach-pxa/time.c
> @@ -89,12 +89,50 @@ pxa_osmr0_set_mode(enum clock_event_mode mode, struct clock_event_device *dev)
> }
> }
>
> +#ifdef CONFIG_PM
> +static unsigned long osmr[4], oier, oscr;
> +
> +static void pxa_timer_suspend(struct clock_event_device *cedev)
> +{
> + osmr[0] = readl_relaxed(OSMR0);
> + osmr[1] = readl_relaxed(OSMR1);
> + osmr[2] = readl_relaxed(OSMR2);
> + osmr[3] = readl_relaxed(OSMR3);
> + oier = readl_relaxed(OIER);
> + oscr = readl_relaxed(OSCR);
> +}
> +
> +static void pxa_timer_resume(struct clock_event_device *cedev)
> +{
> + /*
> + * Ensure that we have at least MIN_OSCR_DELTA between match
> + * register 0 and the OSCR, to guarantee that we will receive
> + * the one-shot timer interrupt. We adjust OSMR0 in preference
> + * to OSCR to guarantee that OSCR is monotonically incrementing.
> + */
> + if (osmr[0] - oscr < MIN_OSCR_DELTA)
> + osmr[0] += MIN_OSCR_DELTA;
> +
> + writel_relaxed(osmr[0], OSMR0);
> + writel_relaxed(osmr[1], OSMR1);
> + writel_relaxed(osmr[2], OSMR2);
> + writel_relaxed(osmr[3], OSMR3);
> + writel_relaxed(oier, OIER);
> + writel_relaxed(oscr, OSCR);
> +}
> +#else
> +#define pxa_timer_suspend NULL
> +#define pxa_timer_resume NULL
> +#endif
> +
> static struct clock_event_device ckevt_pxa_osmr0 = {
> .name = "osmr0",
> .features = CLOCK_EVT_FEAT_ONESHOT,
> .rating = 200,
> .set_next_event = pxa_osmr0_set_next_event,
> .set_mode = pxa_osmr0_set_mode,
> + .suspend = pxa_timer_suspend,
> + .resume = pxa_timer_resume,
> };
>
> static struct irqaction pxa_ost0_irq = {
> @@ -127,44 +165,6 @@ static void __init pxa_timer_init(void)
> clockevents_register_device(&ckevt_pxa_osmr0);
> }
>
> -#ifdef CONFIG_PM
> -static unsigned long osmr[4], oier, oscr;
> -
> -static void pxa_timer_suspend(void)
> -{
> - osmr[0] = readl_relaxed(OSMR0);
> - osmr[1] = readl_relaxed(OSMR1);
> - osmr[2] = readl_relaxed(OSMR2);
> - osmr[3] = readl_relaxed(OSMR3);
> - oier = readl_relaxed(OIER);
> - oscr = readl_relaxed(OSCR);
> -}
> -
> -static void pxa_timer_resume(void)
> -{
> - /*
> - * Ensure that we have at least MIN_OSCR_DELTA between match
> - * register 0 and the OSCR, to guarantee that we will receive
> - * the one-shot timer interrupt. We adjust OSMR0 in preference
> - * to OSCR to guarantee that OSCR is monotonically incrementing.
> - */
> - if (osmr[0] - oscr < MIN_OSCR_DELTA)
> - osmr[0] += MIN_OSCR_DELTA;
> -
> - writel_relaxed(osmr[0], OSMR0);
> - writel_relaxed(osmr[1], OSMR1);
> - writel_relaxed(osmr[2], OSMR2);
> - writel_relaxed(osmr[3], OSMR3);
> - writel_relaxed(oier, OIER);
> - writel_relaxed(oscr, OSCR);
> -}
> -#else
> -#define pxa_timer_suspend NULL
> -#define pxa_timer_resume NULL
> -#endif
> -
> struct sys_timer pxa_timer = {
> .init = pxa_timer_init,
> - .suspend = pxa_timer_suspend,
> - .resume = pxa_timer_resume,
> };
> --
> 1.7.0.4
>
^ permalink raw reply
* [PATCH] ARM: backtrace: avoid crash on large invalid fp value
From: Colin Cross @ 2012-11-09 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105105421.GB2005@linaro.org>
On Mon, Nov 5, 2012 at 2:54 AM, Dave Martin <dave.martin@linaro.org> wrote:
> On Fri, Nov 02, 2012 at 04:47:38PM -0700, Colin Cross wrote:
>> On Wed, Oct 10, 2012 at 4:15 AM, Dave Martin <dave.martin@linaro.org> wrote:
>> > On Tue, Oct 09, 2012 at 11:46:12PM -0700, Todd Poynor wrote:
>> >> Invalid frame pointer (signed) -4 <= fp <= -1 defeats check for too high
>> >> on overflow.
>> >>
>> >> Signed-off-by: Todd Poynor <toddpoynor@google.com>
>> >> ---
>> >> arch/arm/kernel/stacktrace.c | 2 +-
>> >> 1 files changed, 1 insertions(+), 1 deletions(-)
>> >>
>> >> diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
>> >> index 00f79e5..6315162 100644
>> >> --- a/arch/arm/kernel/stacktrace.c
>> >> +++ b/arch/arm/kernel/stacktrace.c
>> >> @@ -31,7 +31,7 @@ int notrace unwind_frame(struct stackframe *frame)
>> >> high = ALIGN(low, THREAD_SIZE);
>> >>
>> >> /* check current frame pointer is within bounds */
>> >> - if (fp < (low + 12) || fp + 4 >= high)
>> >> + if (fp < (low + 12) || fp >= high - 4)
>> >> return -EINVAL;
>> >>
>> >> /* restore the registers from the stack frame */
>> >
>> > sp and fp can still be complete garbage in the case of a corrupted frame,
>> > so low + 12 can still overflow and cause us to read beyond the stack base.
>> >
>> > A more robust patch might be as follows. This also checks for misaligned
>> > fp and sp values, since those indicate corruption and there can be no
>> > sensible way to interpret the resulting frame in that case.
>> >
>> > Also, according to the definition of current_thread_info(),
>> > IS_ALIGNED(sp, THREAD_SIZE) indicates a full stack extending from sp
>> > to sp + THREAD_SIZE, and not an empty stack extending from sp -
>> > THREAD_SIZE to sp. We cannot backtrace this situation anyway, since
>> > that would imply that the frame record extends beyond the stack...
>> > but this patch tidies it up in the interest of clarity.
>> >
>> > Cheers
>> > ---Dave
>> >
>> > (untested)
>> >
>> > diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
>> > index 00f79e5..fec82be 100644
>> > --- a/arch/arm/kernel/stacktrace.c
>> > +++ b/arch/arm/kernel/stacktrace.c
>> > @@ -28,10 +28,20 @@ int notrace unwind_frame(struct stackframe *frame)
>> >
>> > /* only go to a higher address on the stack */
>> > low = frame->sp;
>> > - high = ALIGN(low, THREAD_SIZE);
>> > + if (!IS_ALIGNED(fp, 4))
>> > + return -EINVAL;
>> > +
>> > + /*
>> > + * low + 1 here ensures that high > sp, consistent with the
>> > + * definition of current_thread_info().
>> > + * We subtract 1 to compute the highest allowable byte address.
>> > + * Otherwise, we might get high == 0 which would confuse our
>> > + * comparisons.
>> > + */
>> > + high = ALIGN(low + 1, THREAD_SIZE) - 1;
ARM eabi stacks are full-descending, meaning that if the sp is a
multiple of THREAD_SIZE, the stack is empty. current_thread_info
takes a short-cut and assumes it can never be called on an empty
stack, but better not to propagate that anywhere else.
>> >
>> > /* check current frame pointer is within bounds */
>> > - if (fp < (low + 12) || fp + 4 >= high)
>> > + if (fp < 12 || fp - 12 < low || fp > high)
>> > return -EINVAL;
>> >
>> > /* restore the registers from the stack frame */
>> > @@ -39,6 +49,10 @@ int notrace unwind_frame(struct stackframe *frame)
>> > frame->sp = *(unsigned long *)(fp - 8);
>> > frame->pc = *(unsigned long *)(fp - 4);
>> >
>> > + /* Do not claim the frame is valid if if is obviously corrupt: */
>> > + if (!IS_ALIGNED(frame->fp, 4))
>> > + return -EINVAL;
>> > +
>> > return 0;
>> > }
>> > #endif
>> >
>> >
>> > _______________________________________________
>> > linux-arm-kernel mailing list
>> > linux-arm-kernel at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>> Dave or Todd, mind reposting this, or should I squash it into my
>> CONFIG_SMP stacktrace series?
>
> I'm happy for you to fold my patch into your series if you agree
> with it. Ideally, please fix my typo in the final comment ("if IT is
> obviously corrupt").
>
> Do I assume correctly that you are already testing this stuff?
I've been testing it by repeatedly dumping the stack of a running
thread (cat /dev/urandom > /dev/null) and making sure it doesn't
panic, and by dumping all the threads in a idle system and making sure
they all end at the normal user or kernel thread initial frames
(do_exit, kernel_thread_exit, or ret_fast_syscall).
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the pinctrl tree
From: Stephen Rothwell @ 2012-11-09 2:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/pinctrl/pinctrl-nomadik.c between commit 241e51ebd3b2
("pinctrl/nomadik: make independent of prcmu driver") from the pinctrl
tree and commit 44e47ccf8ab6 ("Merge branch 'next/multiplatform' into
for-next") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
diff --cc drivers/pinctrl/pinctrl-nomadik.c
index 33c614e,3ad23fb..0000000
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@@ -30,10 -30,23 +30,9 @@@
#include <linux/pinctrl/pinconf.h>
/* Since we request GPIOs from ourself */
#include <linux/pinctrl/consumer.h>
-/*
- * For the U8500 archs, use the PRCMU register interface, for the older
- * Nomadik, provide some stubs. The functions using these will only be
- * called on the U8500 series.
- */
-#ifdef CONFIG_ARCH_U8500
-#include <linux/mfd/dbx500-prcmu.h>
-#else
-static inline u32 prcmu_read(unsigned int reg) {
- return 0;
-}
-static inline void prcmu_write(unsigned int reg, u32 value) {}
-static inline void prcmu_write_masked(unsigned int reg, u32 mask, u32 value) {}
-#endif
#include <linux/platform_data/pinctrl-nomadik.h>
-
#include <asm/mach/irq.h>
-
+ #include <mach/irqs.h>
#include "pinctrl-nomadik.h"
/*
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121109/81ef2148/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] arm: bcm2835: move to the multiplatform support
From: Stephen Warren @ 2012-11-09 3:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351419853-25146-1-git-send-email-thomas.petazzoni@free-electrons.com>
On 10/28/2012 04:24 AM, Thomas Petazzoni wrote:
> This commit integrates the bcm2835 into the list of platforms
> supported by the multiplatform mechanism, which makes it possible to
> build a single kernel binary image that boots on various SoCs.
...
> ---
> Note that if you have CONFIG_VFP enabled, you need "[PATCH v3] ARM:
> vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3
> set" to be applied in order to avoid a VFP-related kernel panic when
> starting the first userspace application. Thanks to Albin Tonnerre for
> pointing me to the right fix for this problem!
Thomas, just a heads up - the VFP commit you mention above should show
up in v3.7-rc5 which I imagine will be released this weekend, and the
debug_ll_io_init feature I mentioned in another response is already
available is arm-soc branch devel/debug_ll_init. If you rebase this
patch on a merge of those two branches, it should be in good shape for
me to apply it.
Thanks.
^ permalink raw reply
* S-o-b for 48efdd2 "Add a pm_power_off function that resets us, ..."
From: Stephen Warren @ 2012-11-09 3:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508CA4C4.5060407@wwwdotorg.org>
On 10/27/2012 09:21 PM, Stephen Warren wrote:
> Dom,
>
> Are you able to provide your S-o-b for the following commit:
>
> 48efdd2 Add a pm_power_off function that resets us, and indicates to
> bootcode.bin not to reboot us. Should allow a lower power 'off' state
>
> I would like to upstream that, but can't without an S-o-b [from you].
>
> Thanks.
Dom, are you able to provide an S-o-b line for this or any other commits
in you kernel trees? It'd be really helpful if you could add S-o-bs to
any/all commits in your branches where you can. Thanks.
^ permalink raw reply
* [PATCH] Add support for generic BCM SoC chipsets
From: Stephen Warren @ 2012-11-09 3:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352391196-9984-1-git-send-email-csd@broadcom.com>
On 11/08/2012 09:13 AM, Christian Daudt wrote:
> In order to start upstreaming Broadcom SoC support, create
> a starting hierarchy, arch and dts files.
> The first support SoC family that is planned is the
> BCM281XX (BCM28145/28150/28155) family of dual A9 mobile SoC cores
> This code is just the skeleton code for get the machine upstreamed. It
> has been made MULTIPLATFORM compatible.
Christian,
Is the intent for this to support other BCM SoCs in the future, such as
the bcm2835 in the Raspberry Pi, and the mach-bcm476x which Domenico
Andreoli recently sent patches for? It'd be awesome if Broadcom could
provide MMC and USB drivers for the bcm2835 for example.
> arch/arm/boot/dts/capri-brt.dts | 32 +++++++++++
> arch/arm/boot/dts/capri.dtsi | 50 +++++++++++++++++
What does the name "capri" refer to? I assume it's a code-name for the
SoC/series. My inclination is that naming those files bcm28145.dtsi and
bcm28145-brt.dts (or 28150/28155 as appropriate) might be a little more
obvious to people unfamiliar with the code-names.
> diff --git a/arch/arm/boot/dts/capri-brt.dts b/arch/arm/boot/dts/capri-brt.dts
> +/ {
> + model = "Capri BRT board";
> + compatible = "bcm,capri";
The individual board file's compatible property should contain both a
board-specific value and the generic SoC value. This allows the SoC
support in the kernel to match on the generic SoC compatible value, yet
still allow the kernel to match the board-specific value in case any
quirks are required. For example,
compatible = "bcm,brt", "bcm,capri";
(assuming that "brt" is the full board name)
> + interrupt-parent = <&gic>;
That's already in capri.dtsi; there's no advantage to repeating it.
> + memory {
> + device_type = "memory";
That property already exists in skeleton.dtsi, which is included via
capri.dtsi.
> diff --git a/arch/arm/boot/dts/capri.dtsi b/arch/arm/boot/dts/capri.dtsi
> + gic: interrupt-controller at 3ff00100 {
> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
The commit description says it's an A9 not an A15.
> + uart at 3e000000 {
> + compatible = "snps,dw-apb-uart";
You probably want to include SoC-specific compatible values for all the
IP blocks too.
There need to be device tree bindings written to describe to contents of
all these device-tree files; see Documentation/devicetree/bindings/.
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> +config ARCH_BCM
> + bool "Broadcom SoC" if ARCH_MULTI_V7
> + depends on MMU
> + select CPU_V7
> + select ARM_GIC
> + select GENERIC_GPIO
> + select GPIO_BCM
> + select ARCH_REQUIRE_GPIOLIB
> + select GENERIC_TIME
> + select GENERIC_CLOCKEVENTS
> + select TICK_ONESHOT
> + select ARM_ERRATA_754322
> + select ARM_ERRATA_764369 if SMP
> + select SPARSE_IRQ
Those select statements should be alphabetically sorted.
> diff --git a/arch/arm/mach-bcm/board_bcm.c b/arch/arm/mach-bcm/board_bcm.c
> +
> +
> +
> +
> +
Nit: A couple of instances of multiple newlines, but not a big deal.
^ permalink raw reply
* [RFC] arm: memtest
From: Alexander Holler @ 2012-11-09 5:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAE9FiQWeie62NYt2vyq2q+Um8NeA5xWQGy-nULmFidt4XxW=BA@mail.gmail.com>
Am 08.11.2012 23:39, schrieb Yinghai Lu:
> On Thu, Nov 8, 2012 at 12:48 PM, Alexander Holler <holler@ahsoftware.de> wrote:
>> Hello,
>>
>> I've recently discovered the lack of the command line parameter memtest for
>> ARM. So I've made a patch.
>>
>> But I have some questions:
>>
>> 1. arch/x86/mm/memtest.c looks platform independ.
>> The only thing why I don't use it for arm, is because it uses 64bit
>> pointers. Maybe it could be moved to mm/memtest.c. If so, the memtest32.c
>> I'm using (basically a copy of memtest.c) could be moved there too.
>>
>> 2. Because the below memtest32.c is basically a copy of
>> arch/x86/mm/memtest.c, I'm not sure if the mapping from physical to virtual
>> locations there does fit (always) for ARM too. I know almost as much about
>> the in-kernel memory organization on x86 as on ARM, which is not really that
>> much (some theory about TLBs, some source code explorations, ..., but I'm
>> working on it). ;)
>
> We are using arch/x86/mm/memtest.c for x86 32bit and 64bit.
>
> So it should be ok to use it with arm 32bit and 64bit directly.
It does. But in order to enable it on every boot, I wanted it to be as
fast as possible.
Regards,
Alexander
^ permalink raw reply
* [PATCH 4/4] DMA: PL330: add device tree property for DMA_MEMCPY capability
From: Jassi Brar @ 2012-11-09 6:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210301021.42803.b.zolnierkie@samsung.com>
On 30 October 2012 14:51, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
>
> Hi,
>
> On Monday 29 October 2012 22:45:48 Jassi Brar wrote:
>> On Mon, Oct 29, 2012 at 10:59 AM, Bartlomiej Zolnierkiewicz
>> <b.zolnierkie@samsung.com> wrote:
>> > * Add device tree (DT) property ("pl330,dma-memcpy") for DMA_MEMCPY
>> > capability and instead of setting this capability unconditionally
>> > in pl330_probe() do it only when property is present.
>> >
>> Perhaps we should pass the array of peripheral interfaces via DT, the
>> lack of which could imply MEMCPY capability ? (while it works, I doubt
>> if pl330 is supposed to have SLAVE and MEMCPY capabilities in any
>> instance)
>
> In case of PL330 on EXYNOS4 we have two interfaces with SLAVE capability
> and one interface with MEMCPY capability. Could you please explain more
> the idea of passing the array of peripherals through DT so we can detect
> which interface has MEMCPY capability?
>
The DT node of a 'pdma' should have the array of indices of
peripherals it caters to (what is currently peri_id of 'struct
dma_pl330_platdata'). The array would be missing in the DT node of
'mdma' since all channels are equal.
During probe if the array, say as property 'peri_map', is missing from
DT node of the dmac, that would imply the dmac is 'mdma' and hence the
pl330.c sets DMA_MEMCPY in its cap_mask. Otherwise the peri_map
implies a 'pdma' and hence SLAVE|CYCLIC is set.
>> That would also be a step towards discarding "struct dma_pl330_platdata".
>
> I don't know if getting rid of "struct dma_pl330_platdata" is possible
> but we still need to come up with some way to pass the needed information
> through DT. Do you have an idea how it could be done?
>
struct dma_pl330_platdata {
u8 nr_valid_peri;
u8 *peri_id;
As explain above, these two should move to DT node of the dma controller.
dma_cap_mask_t cap_mask;
Should be set in pl330.c : MEMCPY for mdma, SLAVE|CYCLIC for pdma
unsigned mcbuf_sz;
Currently unused and already safe enough default value set in driver.
}
^ permalink raw reply
* [PATCH] dmaengine: imx-dma: fix missing irq disable in tasklet
From: Dirk Behme @ 2012-11-09 7:00 UTC (permalink / raw)
To: linux-arm-kernel
From: Andreas Pape <external.Andreas.Pape@de.bosch.com>
Interrupt handler uses spinlock, too.
To avoid deadlock tasklet must disable IRQ.
Signed-off-by: Andreas Pape <external.Andreas.Pape@de.bosch.com>
CC: Vinod Koul <vinod.koul@linux.intel.com>
CC: Javier Martin <javier.martin@vista-silicon.com>
CC: Sascha Hauer <s.hauer@pengutronix.de>
---
I'm no DMA expert, so sorry if it's wrong ;)
And btw.: While looking at this code, we wonder if imxdma_xfer_desc() can
get the spin lock recursively, e.g. from imxdma_tasklet()? Or what ensures
that the lock is always taken from an other DMA engine than the one already
holding the lock?
drivers/dma/imx-dma.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index 7d9554c..bce30e8 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -562,8 +562,9 @@ static void imxdma_tasklet(unsigned long data)
struct imxdma_channel *imxdmac = (void *)data;
struct imxdma_engine *imxdma = imxdmac->imxdma;
struct imxdma_desc *desc;
+ unsigned long flags;
- spin_lock(&imxdma->lock);
+ spin_lock_irqsave(&imxdma->lock, flags);
if (list_empty(&imxdmac->ld_active)) {
/* Someone might have called terminate all */
@@ -600,7 +601,7 @@ static void imxdma_tasklet(unsigned long data)
__func__, imxdmac->channel);
}
out:
- spin_unlock(&imxdma->lock);
+ spin_unlock_irqrestore(&imxdma->lock, flags);
}
static int imxdma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
--
1.7.0.4
^ permalink raw reply related
* [GIT PULL v2] Renesas ARM-based SoC for v3.8 #2
From: Simon Horman @ 2012-11-09 7:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Arnd,
please consider the following SoC enhancements for 3.8.
* This series is based on the renesas/soc branch of the arm-soc tree.
There will be a subquent 'SoC2' pull request which is based on this
pull-request and a pull-request for boards.
----------------------------------------------------------------
The following changes since commit 86bc52ef4373be64867b56f3a9e30cbabf64e0dd:
ARM: shmobile: r8a7740: Enable PMU (2012-11-06 13:47:24 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git soc
for you to fetch changes up to 2944628607f76e4755660cd710f22a4748ef88d8:
ARM: shmobile: add fsi external clock sh7372 (2012-11-08 15:22:06 +0900)
----------------------------------------------------------------
Kuninori Morimoto (10):
ARM: shmobile: r8a7779: PFC rename PENCx -> USB_PENCx
ARM: shmobile: r8a7740: add USB24 clock explain
ARM: shmobile: r8a7779: add USB EHCI clock support
ARM: shmobile: r8a7779: add USB OHCI clock support
sh: clkfwk: add sh_clk_fsidiv_register()
ARM: shmobile: sh7372: sh7372_fsidivX_clk become non-global
ARM: shmobile: sh7372: use sh_clk_fsidiv_register() for FSI-DIV clocks
ARM: shmobile: r8a7740: add FSI-DVI clocks
ARM: shmobile: add fsi external clock on r8a7740
ARM: shmobile: add fsi external clock sh7372
arch/arm/mach-shmobile/board-ap4evb.c | 2 +-
arch/arm/mach-shmobile/board-mackerel.c | 2 +-
arch/arm/mach-shmobile/clock-r8a7740.c | 34 +++++++++
arch/arm/mach-shmobile/clock-r8a7779.c | 7 ++
arch/arm/mach-shmobile/clock-sh7372.c | 94 ++++---------------------
arch/arm/mach-shmobile/include/mach/r8a7779.h | 2 +-
arch/arm/mach-shmobile/include/mach/sh7372.h | 2 -
arch/arm/mach-shmobile/pfc-r8a7779.c | 16 ++---
drivers/sh/clk/cpg.c | 86 ++++++++++++++++++++++
include/linux/sh_clk.h | 9 +++
10 files changed, 159 insertions(+), 95 deletions(-)
^ permalink raw reply
* [PATCH 01/10] ARM: shmobile: r8a7779: PFC rename PENCx -> USB_PENCx
From: Simon Horman @ 2012-11-09 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352446165-19298-1-git-send-email-horms@verge.net.au>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
PENCx is Power Enable Control pin for USB.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/include/mach/r8a7779.h | 2 +-
arch/arm/mach-shmobile/pfc-r8a7779.c | 16 ++++++++--------
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7779.h b/arch/arm/mach-shmobile/include/mach/r8a7779.h
index 499f52d..8ab0cd6 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -71,7 +71,7 @@ enum {
GPIO_FN_A19,
/* IPSR0 */
- GPIO_FN_PENC2, GPIO_FN_SCK0, GPIO_FN_PWM1, GPIO_FN_PWMFSW0,
+ GPIO_FN_USB_PENC2, GPIO_FN_SCK0, GPIO_FN_PWM1, GPIO_FN_PWMFSW0,
GPIO_FN_SCIF_CLK, GPIO_FN_TCLK0_C, GPIO_FN_BS, GPIO_FN_SD1_DAT2,
GPIO_FN_MMC0_D2, GPIO_FN_FD2, GPIO_FN_ATADIR0, GPIO_FN_SDSELF,
GPIO_FN_HCTS1, GPIO_FN_TX4_C, GPIO_FN_A0, GPIO_FN_SD1_DAT3,
diff --git a/arch/arm/mach-shmobile/pfc-r8a7779.c b/arch/arm/mach-shmobile/pfc-r8a7779.c
index cbc26ba..9513234 100644
--- a/arch/arm/mach-shmobile/pfc-r8a7779.c
+++ b/arch/arm/mach-shmobile/pfc-r8a7779.c
@@ -140,7 +140,7 @@ enum {
FN_IP7_3_2, FN_IP7_6_4, FN_IP7_9_7, FN_IP7_12_10,
FN_IP7_14_13, FN_IP2_7_4, FN_IP2_11_8, FN_IP2_15_12,
FN_IP1_28_25, FN_IP2_3_0, FN_IP8_3_0, FN_IP8_7_4,
- FN_IP8_11_8, FN_IP8_15_12, FN_PENC0, FN_PENC1,
+ FN_IP8_11_8, FN_IP8_15_12, FN_USB_PENC0, FN_USB_PENC1,
FN_IP0_2_0, FN_IP8_17_16, FN_IP8_18, FN_IP8_19,
/* GPSR5 */
@@ -176,7 +176,7 @@ enum {
FN_A0, FN_SD1_DAT3, FN_MMC0_D3, FN_FD3,
FN_BS, FN_SD1_DAT2, FN_MMC0_D2, FN_FD2,
FN_ATADIR0, FN_SDSELF, FN_HCTS1, FN_TX4_C,
- FN_PENC2, FN_SCK0, FN_PWM1, FN_PWMFSW0,
+ FN_USB_PENC2, FN_SCK0, FN_PWM1, FN_PWMFSW0,
FN_SCIF_CLK, FN_TCLK0_C,
/* IPSR1 */
@@ -447,7 +447,7 @@ enum {
A0_MARK, SD1_DAT3_MARK, MMC0_D3_MARK, FD3_MARK,
BS_MARK, SD1_DAT2_MARK, MMC0_D2_MARK, FD2_MARK,
ATADIR0_MARK, SDSELF_MARK, HCTS1_MARK, TX4_C_MARK,
- PENC2_MARK, SCK0_MARK, PWM1_MARK, PWMFSW0_MARK,
+ USB_PENC2_MARK, SCK0_MARK, PWM1_MARK, PWMFSW0_MARK,
SCIF_CLK_MARK, TCLK0_C_MARK,
EX_CS0_MARK, RX3_C_IRDA_RX_C_MARK, MMC0_D6_MARK,
@@ -658,7 +658,7 @@ static pinmux_enum_t pinmux_data[] = {
PINMUX_DATA(A18_MARK, FN_A18),
PINMUX_DATA(A19_MARK, FN_A19),
- PINMUX_IPSR_DATA(IP0_2_0, PENC2),
+ PINMUX_IPSR_DATA(IP0_2_0, USB_PENC2),
PINMUX_IPSR_MODSEL_DATA(IP0_2_0, SCK0, SEL_SCIF0_0),
PINMUX_IPSR_DATA(IP0_2_0, PWM1),
PINMUX_IPSR_MODSEL_DATA(IP0_2_0, PWMFSW0, SEL_PWMFSW_0),
@@ -1456,7 +1456,7 @@ static struct pinmux_gpio pinmux_gpios[] = {
GPIO_FN(A19),
/* IPSR0 */
- GPIO_FN(PENC2), GPIO_FN(SCK0), GPIO_FN(PWM1), GPIO_FN(PWMFSW0),
+ GPIO_FN(USB_PENC2), GPIO_FN(SCK0), GPIO_FN(PWM1), GPIO_FN(PWMFSW0),
GPIO_FN(SCIF_CLK), GPIO_FN(TCLK0_C), GPIO_FN(BS), GPIO_FN(SD1_DAT2),
GPIO_FN(MMC0_D2), GPIO_FN(FD2), GPIO_FN(ATADIR0), GPIO_FN(SDSELF),
GPIO_FN(HCTS1), GPIO_FN(TX4_C), GPIO_FN(A0), GPIO_FN(SD1_DAT3),
@@ -1865,8 +1865,8 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
GP_4_30_FN, FN_IP8_18,
GP_4_29_FN, FN_IP8_17_16,
GP_4_28_FN, FN_IP0_2_0,
- GP_4_27_FN, FN_PENC1,
- GP_4_26_FN, FN_PENC0,
+ GP_4_27_FN, FN_USB_PENC1,
+ GP_4_26_FN, FN_USB_PENC0,
GP_4_25_FN, FN_IP8_15_12,
GP_4_24_FN, FN_IP8_11_8,
GP_4_23_FN, FN_IP8_7_4,
@@ -1981,7 +1981,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
FN_BS, FN_SD1_DAT2, FN_MMC0_D2, FN_FD2,
FN_ATADIR0, FN_SDSELF, FN_HCTS1, FN_TX4_C,
/* IP0_2_0 [3] */
- FN_PENC2, FN_SCK0, FN_PWM1, FN_PWMFSW0,
+ FN_USB_PENC2, FN_SCK0, FN_PWM1, FN_PWMFSW0,
FN_SCIF_CLK, FN_TCLK0_C, 0, 0 }
},
{ PINMUX_CFG_REG_VAR("IPSR1", 0xfffc0024, 32,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 02/10] ARM: shmobile: r8a7740: add USB24 clock explain
From: Simon Horman @ 2012-11-09 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352446165-19298-1-git-send-email-horms@verge.net.au>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
USBCKCR is controlling USB parent clock and divide rate.
This parent clock is used as a "usb24s" from other devices,
but the "divide rate" is not used.
Further, this clock itself is known as "usb24".
So, to set this clock is a little confusable.
This patch adds quick explain and sample settings for this clock.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/clock-r8a7740.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
index 6729e00..c012bbf 100644
--- a/arch/arm/mach-shmobile/clock-r8a7740.c
+++ b/arch/arm/mach-shmobile/clock-r8a7740.c
@@ -188,6 +188,22 @@ static struct clk pllc1_div2_clk = {
};
/* USB clock */
+/*
+ * USBCKCR is controlling usb24 clock
+ * bit[7] : parent clock
+ * bit[6] : clock divide rate
+ * And this bit[7] is used as a "usb24s" from other devices.
+ * (Video clock / Sub clock / SPU clock)
+ * You can controll this clock as a below.
+ *
+ * struct clk *usb24 = clk_get(dev, "usb24");
+ * struct clk *usb24s = clk_get(NULL, "usb24s");
+ * struct clk *system = clk_get(NULL, "system_clk");
+ * int rate = clk_get_rate(system);
+ *
+ * clk_set_parent(usb24s, system); // for bit[7]
+ * clk_set_rate(usb24, rate / 2); // for bit[6]
+ */
static struct clk *usb24s_parents[] = {
[0] = &system_clk,
[1] = &extal2_clk
--
1.7.10.4
^ permalink raw reply related
* [PATCH 03/10] ARM: shmobile: r8a7779: add USB EHCI clock support
From: Simon Horman @ 2012-11-09 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352446165-19298-1-git-send-email-horms@verge.net.au>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
ehci-platform driver require these clocks
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/clock-r8a7779.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-shmobile/clock-r8a7779.c b/arch/arm/mach-shmobile/clock-r8a7779.c
index 24f5a84..4ba4e3c 100644
--- a/arch/arm/mach-shmobile/clock-r8a7779.c
+++ b/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -87,6 +87,7 @@ static struct clk div4_clks[DIV4_NR] = {
};
enum { MSTP323, MSTP322, MSTP321, MSTP320,
+ MSTP101, MSTP100,
MSTP030,
MSTP029, MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
MSTP016, MSTP015, MSTP014,
@@ -98,6 +99,8 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP322] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR3, 22, 0), /* SDHI1 */
[MSTP321] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR3, 21, 0), /* SDHI2 */
[MSTP320] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR3, 20, 0), /* SDHI3 */
+ [MSTP101] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR1, 1, 0), /* USB2 */
+ [MSTP100] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR1, 0, 0), /* USB0/1 */
[MSTP030] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 30, 0), /* I2C0 */
[MSTP029] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 29, 0), /* I2C1 */
[MSTP028] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 28, 0), /* I2C2 */
@@ -153,6 +156,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_CON_ID("peripheral_clk", &div4_clks[DIV4_P]),
/* MSTP32 clocks */
+ CLKDEV_DEV_ID("ehci-platform.1", &mstp_clks[MSTP101]), /* USB EHCI port2 */
+ CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 04/10] ARM: shmobile: r8a7779: add USB OHCI clock support
From: Simon Horman @ 2012-11-09 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352446165-19298-1-git-send-email-horms@verge.net.au>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
ohci-platform driver require these clocks
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/clock-r8a7779.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-shmobile/clock-r8a7779.c b/arch/arm/mach-shmobile/clock-r8a7779.c
index 4ba4e3c..be885cf 100644
--- a/arch/arm/mach-shmobile/clock-r8a7779.c
+++ b/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -157,7 +157,9 @@ static struct clk_lookup lookups[] = {
/* MSTP32 clocks */
CLKDEV_DEV_ID("ehci-platform.1", &mstp_clks[MSTP101]), /* USB EHCI port2 */
+ CLKDEV_DEV_ID("ohci-platform.1", &mstp_clks[MSTP101]), /* USB OHCI port2 */
CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
+ CLKDEV_DEV_ID("ohci-platform.0", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox