From: Jon Hunter
This series adds PMU support for OMAP4 devices. This is based upon Will Deacons
series [1]. This series attempts to fix the management of the EMU power domain
so that PMU can be enabled at runtime and low-power states are not prevented
when PMU is not in-use. The fix is based
From: Jon Hunter
In order to use the CTI interrupts inconjunction with the DEBUGSS we need to
re-map the CTI IRQs to the DEBUGSS HWMOD. This is based upon Benoit Cousson's
patch [1].
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/073319.html
Cc: Ming Lei
Cc:
: Kevin Hilman
Signed-off-by: Ming Lei
Signed-off-by: Will Deacon
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/devices.c | 61 ++---
1 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2
Shilimkar
Cc: Woodruff Richard
Cc: Ming Lei
Cc: Will Deacon
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Signed-off-by: Ming Lei
Signed-off-by: Will Deacon
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/devices.c | 60 +++-
arch/arm
From: Jon Hunter
This patch is based upon Ming Lei's patch to add runtime PM support for OMAP4
[1]. In Ming's original patch the CTI interrupts were being enabled during
runtime when the PMU was used but they were only configured once during init.
Therefore move the configuration
From: Jon Hunter
For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the
following transition modes ...
NO_SLEEP (0x0) - A clock domain sleep transition is never initiated,
irrespective of the hardware conditions.
SW_SLEEP (0x1) - A software-forced sleep
From: Jon Hunter
On the OMAP4 devices the EMU power domain is configured in hardware so that its
next power state is OFF. This cannot be overriden by software and this means
that when ever the EMU clock domain automatically transitions to the idle
state, the power domain will transition to OFF
Hi All,
On 05/09/2012 02:28 PM, Jon Hunter wrote:
[...]
>>>>> No hacking intended here, just getting the flags correct ;-)
>>>>>
>>>>> So let me start from the beginning ...
>>>>>
>>>>> 1. I agree that for the EMU CD
Hi Will,
On 05/10/2012 03:44 AM, Will Deacon wrote:
> On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
>> Hi All,
>
> Hi Jon,
>
>> I have posted my latest series here [1] based upon that from Will [2]
>> which attempts to fix the EMU CD based upon the
Hi Kevin,
On 05/10/2012 09:12 AM, Kevin Hilman wrote:
> Jon Hunter writes:
>
> [...]
>
>> I have posted my latest series here [1] based upon that from Will [2]
>> which attempts to fix the EMU CD based upon the inputs from this thread.
>> It is working on my o
Hi Will
On 05/11/2012 07:25 AM, Will Deacon wrote:
> On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote:
>> Hi Will,
>
> Hi Jon,
>
>> For my testing I have just been reading the PM_EMU_PWRSTST register which
>> shows the power state of the EMU power dom
Hi Will,
On 05/11/2012 08:49 AM, Will Deacon wrote:
> On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote:
>> On 05/11/2012 07:25 AM, Will Deacon wrote:
>>> I figured I may as well take perf for a spin and see how I got on. The good
>>> news is that the hwm
Hi Will,
On 05/11/2012 10:02 AM, Will Deacon wrote:
> On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote:
>> Hi Will,
>
> Hello,
>
>> On 05/11/2012 08:49 AM, Will Deacon wrote:
>>> I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that
Hi Will,
On 05/11/2012 11:38 AM, Will Deacon wrote:
> On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote:
>> Can you send me your .config?
>
> Sent off-list.
>
>> At the same time, maybe just try "make omap2plus_defconfig" and enable
>> the OMA
Hi Santosh, Benoit,
On 05/10/2012 01:54 AM, Santosh Shilimkar wrote:
> On Thursday 10 May 2012 03:06 AM, Jon Hunter wrote:
>> From: Jon Hunter
>>
>> For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the
>> following transition modes ...
>>
&
Hi Ming,
On 05/14/2012 11:53 PM, Ming Lei wrote:
> On Thu, May 10, 2012 at 5:35 AM, Jon Hunter wrote:
>> From: Jon Hunter
>>
>> This patch is based upon Ming Lei's patch to add runtime PM support for OMAP4
>> [1]. In Ming's original patch the CTI interrupts
From: Jon Hunter
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
int (*set_timer_src
From: Jon Hunter
In the plat/dmtimer.h there is a structure named "clk" declared. This structure
is not used and appears to be left over from previous code. Hence, remove this
unused structure.
Verified that both omap1 and omap2plus kernel configurations build with this
change.
Sig
From: Jon Hunter
The OMAP2+ timer code has a definition for the maximum number of timers that
OMAP2+ devices have. This defintion is not used anywhere in the code and
appears to be left over. Furthermore the definition is not accurate for OMAP4
devices that only have 11 timers available because
From: Jon Hunter
During early boot, two timers are reserved by the kernel as system timers (for
clocksource and clockevents). These timers are marked as reserved and the
dmtimer driver is notified which timers have been reserved via the platform
data information.
For OMAP2+ devices the timers
From: Jon Hunter
Although the OMAP timers share a common hardware design, there are some
differences between the timer instances in a given device. For example, a timer
maybe in a power domain that can be powered-of, so can lose its logic state and
need restoring where as another may be in power
From: Jon Hunter
Fix the following issues with the timer device attributes for OMAP2+ devices:
1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating
that these timers are in an ALWAYS-ON power domain. This is not the case
only timer1 is in an ALWAYS-ON power domain
From: Jon Hunter
The platform data variable loses_context is used to determine if the timer may
lose its logic state during power transitions and so needs to be restored. This
information is also provided in the HWMOD device attributes for OMAP2+ devices
via the OMAP_TIMER_ALWON flag. When this
From: Jon Hunter
For OMAP2+ devices, a function pointer that returns the number of times a timer
power domain has lost context is passed to the dmtimer driver. This function
pointer is only populated for OMAP2+ devices and it is pointing to a platform
function. Given that this is a platform
From: Jon Hunter
For OMAP1 devices, it is necessary to perform a manual reset of the timer.
Currently, this is indicating by setting the "needs_manual_reset" variable in
the platform data. Instead of using an extra variable to indicate this add a new
timer capabilities flag to indicat
From: Jon Hunter
Currently, the dmtimer determines whether an timer can support an external
clock source (sys_altclk) for driving the timer by the IP version. Only
OMAP24xx devices can support an external clock source, but the IP version
between OMAP24xx and OMAP3xxx is common and so this
Hi Jassi,
On 05/12/2012 08:40 AM, Jassi Brar wrote:
> On 12 May 2012 05:21, Stephen Warren wrote:
>> On 05/11/2012 03:06 PM, Jassi Brar wrote:
>>> On 12 May 2012 00:58, Stephen Warren wrote:
On 05/10/2012 01:59 PM, Jassi Brar wrote:
>> ...
>> client0: i2s {
>> /* has 2 DMA request
Hi Jassi,
On 05/04/2012 02:01 PM, Jassi Brar wrote:
> On 4 May 2012 20:47, Jon Hunter wrote:
>> Hi Jassi,
>>
>> On 05/04/2012 01:56 AM, Jassi Brar wrote:
>>> On 1 May 2012 02:47, Jon Hunter wrote:
>>>> From: Jon Hunter
>>>>
>>>
Hi Jassi,
On 05/16/2012 07:37 AM, Jassi Brar wrote:
> Hi Jon,
>
> On 16 May 2012 06:41, Jon Hunter wrote:
>> On 05/04/2012 02:01 PM, Jassi Brar wrote:
>>>
>>> + i2c1: i2c@1 {
>>> + ...
>
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
> Hi Jon,
>
> On 5/16/2012 1:35 AM, Jon Hunter wrote:
>> From: Jon Hunter
>>
>> In order to migrate the dmtimer driver to support device-tree I found
>> that it
>> was first necessary to clean-up th
On 05/16/2012 08:15 AM, Jon Hunter wrote:
> Hi Jassi,
>
> On 05/16/2012 07:37 AM, Jassi Brar wrote:
>> Hi Jon,
>>
>> On 16 May 2012 06:41, Jon Hunter wrote:
>>> On 05/04/2012 02:01 PM, Jassi Brar wrote:
>>>>
>>>> + i2c1: i2c@1 {
On 05/16/2012 10:44 AM, Stephen Warren wrote:
> On 05/16/2012 07:15 AM, Jon Hunter wrote:
>> Hi Jassi,
>>
>> On 05/16/2012 07:37 AM, Jassi Brar wrote:
>>> Hi Jon,
>>>
>>> On 16 May 2012 06:41, Jon Hunter wrote:
>>>> On 05/04/2012
On 05/16/2012 11:22 AM, Jassi Brar wrote:
[...]
> OK, my guts feel people might be interested in what's cooking on
> my side. I started with the binding text first and then would write
> code based upon that approach.
>
> The following might be tweaked as I look deeper into client and DMAC
> dr
On 05/16/2012 11:16 AM, Jassi Brar wrote:
> On 16 May 2012 21:31, Jon Hunter wrote:
>> On 05/16/2012 08:15 AM, Jon Hunter wrote:
>>> Hi Jassi,
>>>
>>> On 05/16/2012 07:37 AM, Jassi Brar wrote:
>>>> Hi Jon,
>>>>
>>>> On 1
On 05/16/2012 12:24 PM, Jassi Brar wrote:
> On 16 May 2012 22:42, Jon Hunter wrote:
>
>>>> What is still unclear to me, is if you use this token approach how
>>>> readable is the device-tree? For example, if you have a client that can
>>>> use one
On 05/16/2012 12:46 PM, Stephen Warren wrote:
> On 05/16/2012 11:37 AM, Jon Hunter wrote:
>>
>>
>> On 05/16/2012 12:24 PM, Jassi Brar wrote:
>>> On 16 May 2012 22:42, Jon Hunter wrote:
>>>
>>>>>> What is still unclear to me, is if you
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
> Hi Jon,
>
> On 5/16/2012 1:35 AM, Jon Hunter wrote:
>> From: Jon Hunter
>>
>> In order to migrate the dmtimer driver to support device-tree I found
>> that it
>> was first necessary to clean-up th
Hi Paul,
On 05/16/2012 06:30 PM, Paul Walmsley wrote:
> Hello Jon,
>
> On Wed, 16 May 2012, Jon Hunter wrote:
>
>> I have been looking into this and in order to get rid for the above
>> function pointer we would need to move at a minimum the following
>> functions
Hi Tarun,
On 05/17/2012 12:07 AM, DebBarma, Tarun Kanti wrote:
> On Thu, May 17, 2012 at 1:44 AM, Jon Hunter wrote:
>> Hi Benoit,
>>
>> On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
>>> Hi Jon,
>>>
>>> On 5/16/2012 1:35 AM, Jon Hunter wrote:
>
Hi Ming,
On 05/16/2012 05:12 AM, Ming Lei wrote:
> On Thu, May 10, 2012 at 5:35 AM, Jon Hunter wrote:
>
>> +
>> + /*configure CTI0 for pmu irq routing*/
>> + cti_init(&omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
>> + cti_unlock(&oma
Hi Benoit,
On 05/10/2012 04:56 AM, Cousson, Benoit wrote:
> Hi Jon & Ming,
>
> On 5/9/2012 11:35 PM, Jon Hunter wrote:
>> From: Ming Lei
>>
>> The following modules is required to be enabled before configuring
>> cross trigger interface for enabling pmu ir
Hi Benoit,
On 05/21/2012 11:58 AM, Cousson, Benoit wrote:
> Hi Jon,
>
> On 5/16/2012 1:35 AM, Jon Hunter wrote:
>> From: Jon Hunter
>>
>> Currently, the dmtimer determines whether an timer can support an
>> external
>> clock source (sys_altclk) for dr
From: Jon Hunter
OMAP1 dmtimer support is currently broken. When a dmtimer is requested by the
omap_dm_timer_request() function fails to allocate a dmtimer because the call
to clk_get() inside omap_dm_timer_prepare fails. The clk_get() fails simply
because the clock data for the OMAP1 dmtimers
From: Jon Hunter
The function omap2_clk_set_parent is just a wrapper for the
omap_clksel_set_parent() function. Now we have moved the
omap_clksel_set_parent() function into the plat-omap directory for all OMAP
devices to use, we should just use this function directly and we can eliminate
the
From: Jon Hunter
The OMAP dmtimer driver allows you to dynamically configure the functional
clock that drives the timer logic. The dmtimer driver uses the device name and
a "con-id" string to search for the appropriate functional clock.
Currently, we define a clock alias for each
From: Jon Hunter
Add clock data for the 8 dmtimers present on OMAP16xx (including OMAP5912)
and OMAP17xx devices. These timers support 3 different clock sources which
are the 32kHz clock, ARMXOR clock and an external clock source.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap1/clock_data.c
From: Jon Hunter
OMAP1 and OMAP2+ devices had architecture specific functions for configuring
the dmtimer clock source. This was simply because the OMAP1 devices did not
support the clock framework for dynamically setting a clock's parent. Now OMAP1
can use the clock framework to set the p
Hi Tony, Paul,
On 05/17/2012 11:48 AM, Paul Walmsley wrote:
> On Thu, 17 May 2012, Jon Hunter wrote:
>
>> Yes that's right. What is your preference here, the options are ...
>>
>> 1. Move the clkt_clksel.c file to arch/arm/plat-omap and change the
>> omap2_x
On 05/22/2012 03:17 PM, Jon Hunter wrote:
> From: Jon Hunter
>
> Add clock data for the 8 dmtimers present on OMAP16xx (including OMAP5912)
> and OMAP17xx devices. These timers support 3 different clock sources which
> are the 32kHz clock, ARMXOR clock and an external clock so
On 05/22/2012 03:17 PM, Jon Hunter wrote:
> From: Jon Hunter
>
> OMAP1 and OMAP2+ devices had architecture specific functions for configuring
> the dmtimer clock source. This was simply because the OMAP1 devices did not
> support the clock framework for dynamically setting a cloc
Hi Xiao Jiang,
On 05/25/2012 05:42 AM, jgq...@gmail.com wrote:
> From: Xiao Jiang
>
> This series can be applied to dt branch of linux-omap tree.
Thanks for sending this!
> Since omap24xx series has different wdt base addr (omap2420: 0x48022000 and
> omap2430: 0x49016000) per commit 2817142f31
On 05/25/2012 05:42 AM, jgq...@gmail.com wrote:
> From: Xiao Jiang
>
> Add wdt node to support dt.
>
> Signed-off-by: Xiao Jiang
> ---
> arch/arm/boot/dts/omap3.dtsi |5 +
> arch/arm/boot/dts/omap4.dtsi |5 +
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git
uot;wd_timer2";
> char *dev_name = "omap_wdt";
>
> - if (!cpu_class_is_omap2())
> + if (!cpu_class_is_omap2() || of_have_populated_dt())
> return 0;
>
> oh = omap_hwmod_lookup(oh_name);
Reviewed-by: Jon Hunter
Cheers
Jon
--
On 05/25/2012 05:42 AM, jgq...@gmail.com wrote:
> From: Xiao Jiang
>
> Add device table for omap_wdt to support dt.
>
> Signed-off-by: Xiao Jiang
> ---
> drivers/watchdog/omap_wdt.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/watchdog/omap_wdt
Hi Kevin,
On 05/29/2012 04:17 PM, Kevin Hilman wrote:
> Jon Hunter writes:
>
>> From: Jon Hunter
>>
>> This patch is based upon Ming Lei's patch to add runtime PM support for OMAP4
>> [1]. In Ming's original patch the CTI interrupts were being enabled
Hi Kevin,
On 05/29/2012 05:07 PM, Jon Hunter wrote:
> Hi Kevin,
>
> On 05/29/2012 04:17 PM, Kevin Hilman wrote:
>> Jon Hunter writes:
>>
>>> From: Jon Hunter
>>>
>>> This patch is based upon Ming Lei's patch to add runtime PM support for
On 05/29/2012 10:19 PM, Xiao Jiang wrote:
> Jon Hunter wrote:
>> On 05/25/2012 05:42 AM, jgq...@gmail.com wrote:
>>
>>> From: Xiao Jiang
>>>
>>> Add wdt node to support dt.
>>>
>>> Signed-off-by: Xiao Jiang
>>> ---
>&g
Hi Benoit,
On 05/30/2012 02:54 AM, Cousson, Benoit wrote:
> On 5/30/2012 5:18 AM, Xiao Jiang wrote:
>> Jon Hunter wrote:
>>> On 05/25/2012 05:42 AM, jgq...@gmail.com wrote:
>>>> From: Xiao Jiang
>>>>
>>>> Add device table for omap_
Hi Benoit,
On 05/30/2012 10:30 AM, Cousson, Benoit wrote:
> Hi Jon,
>
> On 5/30/2012 5:03 PM, Jon Hunter wrote:
>> Hi Benoit,
>>
>> On 05/30/2012 02:54 AM, Cousson, Benoit wrote:
>>> On 5/30/2012 5:18 AM, Xiao Jiang wrote:
>>>> Jon Hunter wrote
On 05/31/2012 12:51 AM, Xiao Jiang wrote:
> Hi Jon and Benoit,
>>> Thanks for reminding, how about below patch?
>>>
>>> diff --git a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
>>> b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
>>> new file mode 100644
>>> index 000..427
Hi Kevin,
On 05/30/2012 04:50 PM, Kevin Hilman wrote:
[...]
> I'm guessing you probably know my thoughts since you've already thought
> through how this should probably look.
>
> Basically, I don't like the result when we have to hack around missing
> runtime PM support for a driver, so IMO, th
Hi Will,
On 05/30/2012 08:29 PM, Will Deacon wrote:
> Hi Kevin,
>
> On Wed, May 30, 2012 at 10:50:01PM +0100, Kevin Hilman wrote:
>> Basically, I don't like the result when we have to hack around missing
>> runtime PM support for a driver, so IMO, the driver should be updated.
>>
>> IOW, it looks
on OMAP for some quick testing. However, I would need to make sure
this does not break compilation without runtime PM enabled.
Let me know your thoughts.
Cheers
Jon
>From b111bcb24737e070ee1ce7ea3d1deb60a4d6f266 Mon Sep 17 00:00:00 2001
From: Jon Hunter
Date: Thu, 31 May 2012 13:05:20 -0500
S
On 05/31/2012 10:05 AM, Jon Hunter wrote:
> Hi Will,
>
> On 05/30/2012 08:29 PM, Will Deacon wrote:
>> Hi Kevin,
>>
>> On Wed, May 30, 2012 at 10:50:01PM +0100, Kevin Hilman wrote:
>>> Basically, I don't like the result when we have to hack around missin
Hi Kevin,
On 05/31/2012 03:42 PM, Kevin Hilman wrote:
> Jon Hunter writes:
>
>> Hi Kevin, Will,
>>
>> On 05/30/2012 08:29 PM, Will Deacon wrote:
>>> Hi Kevin,
>>>
>>> On Wed, May 30, 2012 at 10:50:01PM +0100, Kevin Hilman wrote:
>>&
Hi Kevin,
On 05/31/2012 05:36 PM, Kevin Hilman wrote:
> Jon Hunter writes:
>
>> Hi Kevin,
>>
>> On 05/31/2012 03:42 PM, Kevin Hilman wrote:
>>> Jon Hunter writes:
>>>
>>>> Hi Kevin, Will,
>>>>
>>>> On 05/30/2012 08
Hi Tero,
On 05/31/2012 08:29 AM, Tero Kristo wrote:
> 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 rea
rs/watchdog/omap_wdt.c|7 +++
> 5 files changed, 32 insertions(+), 1 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/watchdog/omap-wdt.txt
Thanks! Looks good to me.
Reviewed-by: Jon Hunter
Cheers
Jon
--
To unsubscribe from this list: se
On 05/31/2012 07:27 PM, Kevin Hilman wrote:
> Jon Hunter writes:
>
>> Hi Kevin,
>>
>> On 05/31/2012 05:36 PM, Kevin Hilman wrote:
>>> Jon Hunter writes:
>>>
>>>> Hi Kevin,
>>>>
>>>> On 05/31/2012 03:42
Hi Rajendra, Paul,
On 06/01/2012 07:07 AM, Rajendra Nayak wrote:
> Hi,
>
> This RFC series is based of Mikes' latest clk-next. I will
> rebase it once 3.5-rc1 is out and post with more testing thats
> in progress. Meanwhile, the RFC is for me to get some early
> feedback on the patches.
>
> This
Hi Rajendra,
On 06/01/2012 07:07 AM, Rajendra Nayak wrote:
> Hi,
>
> This RFC series is based of Mikes' latest clk-next. I will
> rebase it once 3.5-rc1 is out and post with more testing thats
> in progress. Meanwhile, the RFC is for me to get some early
> feedback on the patches.
>
> This serie
Hi Rajendra,
On 06/04/2012 03:52 AM, Rajendra Nayak wrote:
> Hi Jon,
>
> On Saturday 02 June 2012 04:57 AM, Jon Hunter wrote:
>> Hi Rajendra,
>>
>> On 06/01/2012 07:07 AM, Rajendra Nayak wrote:
>>> Hi,
>>>
>>> This RFC series is based of Mik
Hi Rajendra,
On 06/01/2012 07:07 AM, Rajendra Nayak wrote:
> Moving to COMMON clk, plat/clock.c and plat/clock.h files will no
> longer be used. Move whatever is useful for OMAP2+ for implementing
> platform code into mach/clock.h.
>
> plat/clock.c which has most of usecounting/locking infrastruc
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
> Hi Jon,
>
> On 5/16/2012 1:35 AM, Jon Hunter wrote:
>> From: Jon Hunter
>>
>> In order to migrate the dmtimer driver to support device-tree I found
>> that it
>> was first necessary to clean-up th
On 06/04/2012 09:16 AM, Rajendra Nayak wrote:
>
>>> +/* struct clksel_rate.flags possibilities */
>>> +#define RATE_IN_242X(1<< 0)
>>> +#define RATE_IN_243X(1<< 1)
>>> +#define RATE_IN_3430ES1(1<< 2)/* 3430ES1 rates only */
>>> +#define RATE_IN_3430ES2PLUS(1<<
Beagle and OMAP4460 PANDA.
Jon Hunter (11):
ARM: OMAP: Remove unnecessary clk structure
ARM: OMAP2+: Remove unused max number of timers definition
ARM: OMAP2+: Add dmtimer platform function to reserve systimers
ARM: OMAP: Add DMTIMER capability variable to represent timer
features
In the plat/dmtimer.h there is a structure named "clk" declared. This structure
is not used and appears to be left over from previous code. Hence, remove this
unused structure.
Verified that both omap1 and omap2plus kernel configurations build with this
change.
Signed-off-by:
reserved
as a secure timer. Therefore, remove this definition.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 840929b..c030dfe 100644
--- a/arch/arm/mach-omap2
ever, such attributes do not need to be queried at runtime and we can look up
the attributes via HWMOD or device-tree.
This changes a new "capability" variable to the platform data and timer
structure so we can start removing and simplifying the platform data structure.
Signed-off-by: Jon H
"reserved"
member from the timer platform data. This seemed like the simpler approach and
so was implemented here.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |9 ++---
arch/arm/plat-omap/dmtimer.c | 18 +-
arch/arm
.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |7 ---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 +---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 --
3 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/arch/arm
se for the
same purpose in omap_dm_timer_stop().
Signed-off-by: Jon Hunter
---
arch/arm/plat-omap/dmtimer.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 30742d8e6..d284b5d 100644
--- a/arc
minate
the "timer_ip_version" variable passed as part of the platform data and simplify
the code.
We can also remove the timer IP version from the HWMOD data because the dmtimer
driver uses the TIDR register to determine the IP version.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/omap_hwmod
timer will not lose
context. So use the HWMOD device attributes to determine this.
For OMAP1 devices, loses_context is never set and so set the OMAP_TIMER_ALWON
flag for OMAP1 timers to ensure that code is equivalent.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap1/timer.c |1
simplifies the dmtimer migration to device-tree.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap1/timer.c |4 ++--
arch/arm/mach-omap2/timer.c |3 ---
arch/arm/plat-omap/dmtimer.c | 26 ++
arch/arm/plat-omap/include/plat
uld specify an architecture specific
function for setting the clock source via the platform data set_dmtimer_src()
function pointer.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c | 56 -
arch/arm/plat-omap/dmtimer.c |
2 only) an external clock. By defining
a unique con-id name for each of these (timer_32k_ck, timer_sys_ck and
timer_ext_ck) we can eliminate a lot of the clock aliases for timers. This
reduces code, speeds-up searches and clock initialisation time.
Signed-off-by: Jon Hunter
---
arch/arm/
On 06/04/2012 12:22 PM, Jon Hunter wrote:
> In order to migrate the dmtimer driver to support device-tree I found that it
> was first necessary to clean-up the timer platform data. The goal of this
> series is to simplify the timer platform data structure from ...
&g
On 06/04/2012 12:22 PM, Jon Hunter wrote:
> For OMAP2+ devices, a function pointer that returns the number of times a
> timer
> power domain has lost context is passed to the dmtimer driver. This function
> pointer is only populated for OMAP2+ devices and it is pointing to a platfor
:-(
V2:
- Fix OMAP1 dmtimer support which currently broken. Requesting a timer
fails because clk_get() is called and this is not support for OMAP1
devices.
- Only use "set_timer_src" function pointer for OMAP1 devices.
Jon Hunter (12):
ARM: OMAP: Remove unnecessary clk structure
remove the "reserved"
member from the timer platform data. This seemed like the simpler approach and
so was implemented here.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |9 ++---
arch/arm/plat-omap/dmtimer.c | 18 +-
arc
reserved
as a secure timer and for OMAP3 devices the 12th timer is not available on
secure devices. Therefore, remove this definition.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach
In the plat/dmtimer.h there is a structure named "clk" declared. This structure
is not used and appears to be left over from previous code. Hence, remove this
unused structure.
Verified that both omap1 and omap2plus kernel configurations build with this
change.
Signed-off-by:
ever, such attributes do not need to be queried at runtime and we can look up
the attributes via HWMOD or device-tree.
This changes a new "capability" variable to the platform data and timer
structure so we can start removing and simplifying the platform data structure.
Signed-off-by: Jon H
domain.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |7 ---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 +---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 --
3 files changed, 1 insertion(+), 20 deletions(-)
diff --git
se for the
same purpose in omap_dm_timer_stop().
Signed-off-by: Jon Hunter
---
arch/arm/plat-omap/dmtimer.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 30742d8e6..d284b5d 100644
--- a/arc
timer will not lose
context. So use the HWMOD device attributes to determine this.
For OMAP1 devices, loses_context is never set and so set the OMAP_TIMER_ALWON
flag for OMAP1 timers to ensure that code is equivalent.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap1/timer.c |1
minate
the "timer_ip_version" variable passed as part of the platform data and simplify
the code.
We can also remove the timer IP version from the HWMOD data because the dmtimer
driver uses the TIDR register to determine the IP version.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/omap_hwmod
simplifies the dmtimer migration to device-tree.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |3 ---
arch/arm/plat-omap/dmtimer.c | 17 +++--
arch/arm/plat-omap/include/plat/dmtimer.h |3 ---
3 files changed, 7 insertions(+), 16 deletions
remove the "needs_manual_reset"
member from the platform data.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap1/timer.c |4 ++--
arch/arm/plat-omap/dmtimer.c |9 +++--
arch/arm/plat-omap/include/plat/dmtimer.h |1 +
3 files changed, 6 insertions(+),
201 - 300 of 1176 matches
Mail list logo
