n
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Jon Hunter (6):
ARM: OMAP3: Add debugss HWMOD data
ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD
ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS
ARM: OMAP2+: PMU: Add runtime PM support
ARM: OMAP4: Enable PMU for OMAP4460
/074153.html
Cc: Ming Lei
Cc: Will Deacon
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/pmu.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index
upon Benoit Cousson's patch [1].
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/073319.html
Cc: Ming Lei
Cc: Will Deacon
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Reviewed-by: Santosh Shilimkar
Signed-off-by: Jon Hunter
---
arch/arm/mach-
runtime PM.
Reviewed-by: Benoit Cousson
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c9e3820
On 09/07/2012 03:56 PM, Tony Lindgren wrote:
> * Jon Hunter [120907 13:27]:
>> Hi Tony,
>>
>> On 08/30/2012 03:14 PM, Tony Lindgren wrote:
>>> * Jon Hunter [120816 08:05]:
>>>> On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
>>>>>
Hi Tony,
On 08/30/2012 03:14 PM, Tony Lindgren wrote:
> * Jon Hunter [120816 08:05]:
>> On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
>>>
>>> Did we get conclude on this? I haven't got anything further on this
>>> thread, this may block baseport suppor
On 09/06/2012 08:45 AM, Rob Herring wrote:
> On 07/23/2012 10:24 AM, Jon Hunter wrote:
[snip]
>> Do you have any inputs on the above? Does it make sense to reserve timer
>> resources for kernel system timers in device-tree?
>
> This issue is not unique to omap. So if we
On 09/06/2012 09:20 AM, Jon Hunter wrote:
>
> On 09/06/2012 07:57 AM, Vaibhav Hiremath wrote:
>>
>>
>> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>>> Currently the dmtimer posted mode is being enabled when the function
>>> __omap_dm_timer_reset() is call
On 09/06/2012 09:42 AM, Jon Hunter wrote:
>
> On 09/06/2012 09:06 AM, Jon Hunter wrote:
>>
>> On 09/06/2012 12:07 AM, Vaibhav Hiremath wrote:
>>>
>>>
>>> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>>>> Errata Titles:
>>>> i103:
On 09/06/2012 09:06 AM, Jon Hunter wrote:
>
> On 09/06/2012 12:07 AM, Vaibhav Hiremath wrote:
>>
>>
>> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>>> Errata Titles:
>>> i103: Delay needed to read some GP timer, WD timer and sync timer registers
>&g
On 09/06/2012 07:58 AM, Vaibhav Hiremath wrote:
>
>
> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>> This series includes several fixes for the OMAP DMTIMER driver and a few
>> clean-ups to simplify some of the code. This series is based upon 3.6-rc4.
>>
>> Te
On 09/06/2012 07:58 AM, Vaibhav Hiremath wrote:
>
>
> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>> The OMAP dmtimer driver does not currently have a function to disable the
>> timer interrupts. For some timer instances the timer interrupt enable
>> function can be use
On 09/06/2012 07:57 AM, Vaibhav Hiremath wrote:
>
>
> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>> Currently the dmtimer posted mode is being enabled when the function
>> __omap_dm_timer_reset() is called. This function is only being called for
>> OMAP1 timers and O
On 09/06/2012 12:07 AM, Vaibhav Hiremath wrote:
>
>
> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>> Errata Titles:
>> i103: Delay needed to read some GP timer, WD timer and sync timer registers
>> after wakeup (OMAP3/4)
>> i767: Delay needed to read som
Hi Afzal,
On 09/05/2012 07:37 AM, Afzal Mohammed wrote:
> Create a minimal driver out of gpmc code.
> Responsibilities handled by earlier gpmc
> initialization is now achieved in probe.
>
> Signed-off-by: Afzal Mohammed
Reviewed-by: Jon Hunter
Cheers
Jon
--
To unsubscribe
omap_device for %s\n", oh_name);
return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
> +}
> +postcore_initcall(omap_gpmc_init);
> +
> static irqreturn_t gpmc_handle_irq(int irq, void *dev)
> {
> int i;
>
Otherwise ...
Reviewed-by: Jon Hunter
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Afzal,
On 09/05/2012 07:37 AM, Afzal Mohammed wrote:
> Add gpmc hwmod and associated interconnect data
>
> Signed-off-by: Afzal Mohammed
> ---
> arch/arm/mach-omap2/omap_hwmod_2420_data.c | 18 +++
> arch/arm/mach-omap2/omap_hwmod_2430_data.c | 18 +++
> arch/arm/
Hi Afzal,
On 09/05/2012 07:37 AM, Afzal Mohammed wrote:
> Add gpmc hwmod and associated interconnect data
>
> Signed-off-by: Afzal Mohammed
> ---
> arch/arm/mach-omap2/omap_hwmod_2420_data.c | 18 +++
> arch/arm/mach-omap2/omap_hwmod_2430_data.c | 18 +++
> arch/arm/
also being passed to the above
functions and therefore we do not need to pass the posted variable separately.
Therefore, simplify the above functions by removing the posted variable as an
argument as this is not necessary.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c
timer, the function omap_dm_timer_reset() is now only being called for OMAP1
devices and OMAP1 does not use timer1 as a system timer. Therefore, remove the
check in omap_dm_timer_reset() so that timer1 is reset for OMAP1 devices.
Signed-off-by: Jon Hunter
---
arch/arm/plat-omap/dmtimer.c |6
structure. So instead of looking up the clock again used the clock handle
that stored in the omap_dm_timer structure.
Signed-off-by: Jon Hunter
---
arch/arm/plat-omap/dmtimer.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm
have separate interrupt enable/disable registers and so this will not work.
Therefore, add a dedicated function to disable interrupts.
Signed-off-by: Jon Hunter
---
arch/arm/plat-omap/dmtimer.c | 31 +
arch/arm/plat-omap/include/plat/dmtimer.h |3 ++-
2
H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is
configuring the dmtimer OCP_CFG register as expected for clock-events timer.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 13 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13
does not have the
clock-activity field and so when we reset the timer for an OMAP1 device we
only need to configure the idle-mode field in the TIOCP_CFG register.
Signed-off-by: Jon Hunter
---
arch/arm/plat-omap/dmtimer.c | 40 +
arch/arm/plat-omap
. Therefore, remove one of the SYSC register definitions for the
DMTIMERs and ensure the appropriate register fields are defined for all
DMTIMERs.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 27 ++-
1 file changed, 6 insertions(+), 21
0 of the DMTIMER
TISTAT register (referred to as the SYSS register in HWMOD). Add the
appropriate HWMOD definitions so that HWMOD will check the software reset
status when performing a software reset of the DMTIMER.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |
dmtimer. Currently the watchdog driver does
not read the counter register and so no workaround is necessary.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |9 +++
arch/arm/plat-omap/dmtimer.c
runs test #3 and #4 for
each available timer
Jon Hunter (10):
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
ARM: OMAP: Fix timer posted mode support
ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations
ARM: OMAP2/3: Define HWMOD software reset status for
OMAP1 devices. Although this is a regression from
the original code it only impacts performance and so is not needed for stable.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |3 +--
arch/arm/plat-omap/dmtimer.c | 14 +-
arch/arm/plat-omap
Hi Afzal,
On 08/27/2012 05:37 AM, Mohammed, Afzal wrote:
> On Thu, Aug 23, 2012 at 08:28:44, Hunter, Jon wrote:
[snip]
>> I understand that this is based upon how timings for onenand and tusb
>> are being calculated today, but I am not sure that this is the way to go
>> for all devices. Personal
Hi Afzal,
On 08/21/2012 05:45 AM, Afzal Mohammed wrote:
> Presently there are three peripherals that gets it timing
> by runtime calculation. Those peripherals can work with
> frequency scaling that affects gpmc clock. But timing
> calculation for them are in different ways.
>
> Here a generic ru
pmc_get_fclk_period(void);
>
> extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
> extern u32 gpmc_cs_read_reg(int cs, int idx);
> -extern int gpmc_cs_calc_divider(int cs, unsigned int sync_clk);
> +extern int gpmc_calc_divider(unsigned int sync_clk);
> extern int gpmc_cs_set_timing
t; @@ -922,6 +928,8 @@ static int __init gpmc_init(void)
> clk_enable(gpmc_l3_clk);
>
> l = gpmc_read_reg(GPMC_REVISION);
> + if (GPMC_REVISION_MAJOR(l) > 0x4)
> + gpmc_capability = GPMC_HAS_WR_ACCESS | GPMC_HAS_WR_DATA_MUX_BUS;
> printk(KERN_INFO "GPMC revision %d
Hi Afzal,
Sorry for the delay, I have been out of the office.
On 08/06/2012 08:38 AM, Mohammed, Afzal wrote:
> Hi Tony, Jon,
>
> On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote:
>> * Jon Hunter [120710 10:20]:
>
>>> The DT node should simply have the informa
On 08/17/2012 12:32 AM, Hiremath, Vaibhav wrote:
> On Thu, Aug 16, 2012 at 22:27:42, Hunter, Jon wrote:
>>
>> On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
>>>
>>>
>>> On 7/14/2012 3:56 AM, Jon Hunter wrote:
>>>> OMAP3 devices m
On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
>
>
> On 7/14/2012 3:56 AM, Jon Hunter wrote:
>> 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
>>
Hi Vaibhav,
On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
>
>
> On 7/23/2012 8:54 PM, Jon Hunter wrote:
>> Hi Rob,
>>
>> On 07/16/2012 10:56 AM, Jon Hunter wrote:
>>> Hi Rob,
>>>
>>> On 07/13/2012 09:15 PM, Rob Herring wrote:
>>>
On 08/01/2012 03:47 PM, Will Deacon wrote:
> On Wed, Aug 01, 2012 at 12:07:16AM +0100, Jon Hunter wrote:
>> I have just updated my pmu branch for omap3/4. You can pull my latest
>> patches from [1].
>
> Great, thanks for that. I've pushed out to perf/omap4 and I'
Hi Vinod,
On 07/31/2012 06:12 AM, Vinod Koul wrote:
> On Thu, 2012-07-26 at 12:43 -0500, Jon Hunter wrote:
>>>> So yes I can see that a channel itself could be configured to
>> support a
>>>> given direction, but when we ask for a channel via
>> dma_reque
ckdomain will be forced idle, or, if that mode is not supported in
> the hardware, it will be placed into hardware-supervised idle.
>
> This patch is an equal collaboration with Jon Hunter
> . Ming Lei , Will Deacon
> , Madhav Vij , Kevin Hilman
> , Benoît Cousson , and Santosh
&
Hi Paul,
On 08/01/2012 10:08 AM, Paul Walmsley wrote:
> Hi Jon,
>
> On Tue, 31 Jul 2012, Jon Hunter wrote:
>
>> Sorry for all the emails. However, I wanted to get this out to you as
>> I am due to be out for a couple weeks.
>>
>> So I have updated your
Hi Paul,
On 07/31/2012 01:16 PM, Jon Hunter wrote:
[snip]
> So scratch item #1 above. As Rajendra pointed out in another thread this
> is not right. The only other comment I have with your patch is maybe we
> need to add the following to prevent the EMU PD being idled during
>
Hi Will,
On 07/31/2012 10:14 AM, Will Deacon wrote:
> On Thu, Jul 26, 2012 at 04:16:15PM +0100, Jon Hunter wrote:
>> On 07/26/2012 10:05 AM, Will Deacon wrote:
>>> Ok, thanks for updating me. I've pushed the patches out onto my
>>> perf/omap4-dev branch as
Hi Paul,
On 07/12/2012 04:17 PM, Paul Walmsley wrote:
[snip]
> @@ -170,6 +201,18 @@ static int omap2_clkdm_clk_enable(struct clockdomain
> *clkdm)
> if (!clkdm->clktrctrl_mask)
> return 0;
>
> + /*
> + * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
> +
Hi Paul,
On 07/30/2012 11:36 PM, Jon Hunter wrote:
> Hi Paul,
>
> On 07/30/2012 06:26 PM, Jon Hunter wrote:
>
> [...]
>
>> 1. When HWMOD attempts to disable the clock domain for OMAP2/3 devices
>>we simply return without doing anything. Not sure if it is sa
Hi Rajendra,
On 07/31/2012 12:41 AM, Rajendra Nayak wrote:
> Hi Jon,
>
> On Tuesday 31 July 2012 10:11 AM, Jon Hunter wrote:
>> Hi Paul, Rajendra,
>>
>> On 07/27/2012 12:43 AM, Rajendra Nayak wrote:
>>> On Friday 27 July 2012 02:34 AM, Paul Walmsley wro
use of the following code? I needed to
remove this to get the EMU clock domain to turn off on OMAP3
whilst testing PMU.
Cheers
Jon
commit a0307bd539ecef976793679a1c4ff0d47b22c4bd
Author: Jon Hunter
Date: Mon Jul 30 18:04:06 2012 -0500
ARM: OMAP2/3: Allow HWMOD to disable clock domains
Hi Paul,
On 07/30/2012 06:26 PM, Jon Hunter wrote:
[...]
> 1. When HWMOD attempts to disable the clock domain for OMAP2/3 devices
>we simply return without doing anything. Not sure if it is safe to
>remove this but I can do some more testing on OMAP2/3.
&g
Hi Paul,
On 07/16/2012 01:38 PM, Paul Walmsley wrote:
> Hi Jon,
>
> On Mon, 16 Jul 2012, Jon Hunter wrote:
>
>> Yes I see that makes sense. However, patch #7 has already changed the
>> mapping of the flags. I had intended that patch #7 and #8 would be
>> applied
Hi Javier,
On 06/25/2012 05:31 AM, Javier Martinez Canillas wrote:
> On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
> wrote:
>> On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
>>> It seems the same patch has been there for a while.
>>>
>>> http://thread.gmane.org/gmane.linu
Hi Russell,
On 07/27/2012 08:42 AM, Russell King - ARM Linux wrote:
> On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux wrote:
>> Just a quick reminder that I'm still on holiday, and at this point there
>> are over 2500 messages from the mailing lists which are sitting unread
>> s
On 07/26/2012 01:42 AM, Vinod Koul wrote:
> On Tue, 2012-07-24 at 14:07 -0500, Jon Hunter wrote:
>> Hi Vinod,
>>>>>> Required property:
>>>>>> dmas: list of one or more dma specifiers, each consisting of
>>>>>> - phandle poin
On 07/26/2012 06:28 AM, Vinod Koul wrote:
> On Thu, 2012-07-26 at 07:14 +, Arnd Bergmann wrote:
>> On Thursday 26 July 2012, Vinod Koul wrote:
> But from a client POV it makes sense as with the given direction you
> would need a specific request line for a channel. So this is right.
>>
On 07/26/2012 10:05 AM, Will Deacon wrote:
> On Thu, Jul 26, 2012 at 01:41:23AM +0100, Jon Hunter wrote:
>> Hi Will,
>
> Hi Jon,
>
>> On 07/05/2012 07:40 PM, Jon Hunter wrote:
>> I just wanted to let you know that I have been updating the PMU patches
>> for O
Hi Will,
On 07/05/2012 07:40 PM, Jon Hunter wrote:
> Hi Will,
>
> On 07/02/2012 05:01 PM, Will Deacon wrote:
>> On Mon, Jul 02, 2012 at 05:50:38PM +0100, Jon Hunter wrote:
>>> On 07/02/2012 04:55 AM, Will Deacon wrote:
>>>>
>>>> Did you have any
Hi Vinod,
On 07/20/2012 04:37 AM, Vinod Koul wrote:
> On Fri, 2012-07-20 at 08:39 +, Arnd Bergmann wrote:
>> On Friday 20 July 2012, Vinod Koul wrote:
Required property:
dmas: list of one or more dma specifiers, each consisting of
- phandle pointing to dma controller no
Hi Rob,
On 07/16/2012 10:56 AM, Jon Hunter wrote:
> Hi Rob,
>
> On 07/13/2012 09:15 PM, Rob Herring wrote:
>> 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.
>>>
Hi Will,
On 07/13/2012 09:00 AM, Will Deacon wrote:
> 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 tur
Hi Paul,
On 07/16/2012 01:38 PM, Paul Walmsley wrote:
> Hi Jon,
>
> On Mon, 16 Jul 2012, Jon Hunter wrote:
>
>> Yes I see that makes sense. However, patch #7 has already changed the
>> mapping of the flags. I had intended that patch #7 and #8 would be
>> applied
Hi Tony,
On 07/18/2012 02:19 AM, Tony Lindgren wrote:
> * Jon Hunter [120716 09:01]:
>> On 07/13/2012 09:15 PM, Rob Herring wrote:
>>
>> Tony, Tarun,
>>
>> How would you feel on replacing omap_dmtimer_request_specific(int id)
>> with say omap_dm_tim
Hi Paul,
On 07/16/2012 01:38 PM, Paul Walmsley wrote:
> Hi Jon,
>
> On Mon, 16 Jul 2012, Jon Hunter wrote:
>
>> Yes I see that makes sense. However, patch #7 has already changed the
>> mapping of the flags. I had intended that patch #7 and #8 would be
>> applied
Hi Paul,
On 07/13/2012 04:00 PM, Paul Walmsley wrote:
[...]
>> Unfortunately, although this works it does make the flags a bit less
>> clearer. The upside is the solution is simpler.
>
> Yeah, the problem is the clockdomain CLKDM_CAN_* flags are just intended
> to represent the available bits
Hi Rob,
On 07/13/2012 09:15 PM, Rob Herring wrote:
> 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.
>>
&g
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 righ
t the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |4
arch/arm/plat-omap/dmtimer.c | 32 ++--
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/t
ice-tree.
Please note that adding a 2nd set of clock aliases for the same clocks to only
temporary until device-tree migration is complete. Then we can remove the legacy
aliases. Hence, I have marked the legacy aliases with a "TODO" to remove them.
Signed-off-by: Jon Hunter
---
a
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
P device by default.
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|1 +
arch/arm/mach-omap2/timer.c | 36 +++
3 files changed, 38 in
added and there
is a better way to pass an ID from device-tree let me know.
Cc: Benoit Cousson
Signed-off-by: Jon Hunter
---
.../devicetree/bindings/arm/omap/timer.txt | 34 +++
arch/arm/boot/dts/omap3.dtsi | 104
arch/arm/boot/dts/omap4
.
- Using DT to provide resource information for IRQ and memory by
removing Benoit's intention "HACK" in commit a4f6cdb0 (ARM: OMAP:
omap_device: Add omap_device_[alloc|delete] for DT integration)
Jon Hunter (4):
arm/dts: OMAP: Add timer nodes
ARM: OMAP3: Dyna
t the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |4
arch/arm/plat-omap/dmtimer.c | 32 ++--
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/t
ice-tree.
Please note that adding a 2nd set of clock aliases for the same clocks to only
temporary until device-tree migration is complete. Then we can remove the legacy
aliases. Hence, I have marked the legacy aliases with a "TODO" to remove them.
Signed-off-by: Jon Hunter
---
a
t the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |4
arch/arm/plat-omap/dmtimer.c | 32 ++--
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/t
P device by default.
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|1 +
arch/arm/mach-omap2/timer.c | 36 +++
3 files changed, 38 in
added and there
is a better way to pass an ID from device-tree let me know.
Cc: Benoit Cousson
Signed-off-by: Jon Hunter
---
.../devicetree/bindings/arm/omap/timer.txt | 34 +++
arch/arm/boot/dts/omap3.dtsi | 104
arch/arm/boot/dts/omap4
added and there
is a better way to pass an ID from device-tree let me know.
Cc: Benoit Cousson
Signed-off-by: Jon Hunter
---
.../devicetree/bindings/arm/omap/timer.txt | 34 +++
arch/arm/boot/dts/omap3.dtsi | 104
arch/arm/boot/dts/omap4
.
- Using DT to provide resource information for IRQ and memory by
removing Benoit's intention "HACK" in commit a4f6cdb0 (ARM: OMAP:
omap_device: Add omap_device_[alloc|delete] for DT integration)
Jon Hunter (4):
arm/dts: OMAP: Add timer nodes
ARM: OMAP3: Dyna
added and there
is a better way to pass an ID from device-tree let me know.
Cc: Benoit Cousson
Signed-off-by: Jon Hunter
---
.../devicetree/bindings/arm/omap/timer.txt | 34 +++
arch/arm/boot/dts/omap3.dtsi | 104
arch/arm/boot/dts/omap4
.
- Using DT to provide resource information for IRQ and memory by
removing Benoit's intention "HACK" in commit a4f6cdb0 (ARM: OMAP:
omap_device: Add omap_device_[alloc|delete] for DT integration)
Jon Hunter (4):
arm/dts: OMAP: Add genernal purpose timer nod
OMAP1 devices, because these devices do
not use the clock framework for dmtimers.
Signed-off-by: Jon Hunter
---
arch/arm/plat-omap/dmtimer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 626ad8c..7b6689a
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
>>
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
Hi Afzal,
On 07/10/2012 08:47 AM, Mohammed, Afzal wrote:
> Hi Tony,
>
> On Tue, Jul 10, 2012 at 18:47:34, Tony Lindgren wrote:
>> * Mohammed, Afzal [120710 03:09]:
>>> On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote:
* Mohammed, Afzal [120709 23:24]:
>
> For the peripherals requ
On 07/09/2012 11:47 AM, Kevin Hilman wrote:
> Santosh Shilimkar writes:
>
>> From: R Sricharan
>>
>> OMAP socs has a legacy and a highlander version of the
>> 32k sync counter IP. The register offsets vary between the
>> highlander and the legacy scheme. So use the 'SCHEME'
>> bits(30-31) of th
as OMAP2+.
>
> The cover letter says this was only build tested on OMAP1 so I suggest
> this actually be tested on OMAP1 before merging.
I have tested this on an omap5912 osk. I booted and verified that the
offset is good.
Santosh, add my tested-by for OMAP1 ...
Tested-by: Jon Hunter
Hi Will,
On 07/02/2012 05:01 PM, Will Deacon wrote:
> On Mon, Jul 02, 2012 at 05:50:38PM +0100, Jon Hunter wrote:
>> On 07/02/2012 04:55 AM, Will Deacon wrote:
>>>
>>> Did you have any luck getting to the bottom of this?
>>
>> I am still waiting for fe
Hi Rob,
Thanks for the feedback. Some how our mail server appeared to filter out your
response!
> On 06/21/2012 06:50 PM, Jon Hunter wrote:
>>
>> On 06/21/2012 02:15 PM, Jon Hunter wrote:
>>> Hi all,
>>>
>>> I am in the process of adding a device-t
Hi Paul,
On 07/04/2012 10:38 AM, Paul Walmsley wrote:
> On Thu, 7 Jun 2012, Jon Hunter wrote:
>
>> For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the
>> following transition modes ...
>
> Thanks, queued.
Thanks. Any comments on patch 8/10 of
ntosh Shilimkar
Tested-by: Franky Lin
Tested-by: NeilBrown
Signed-off-by: Jon Hunter
---
drivers/gpio/gpio-omap.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c4ed172..f13fc9c 100644
--- a/drivers/gpio/gpio
On 07/03/2012 03:17 AM, Tony Lindgren wrote:
> * Jon Hunter [120702 10:30]:
>>
>> On 07/02/2012 01:36 AM, Tony Lindgren wrote:
>>>
>>> In general, I doubt that we can come up with better calculations. The
>>> existing
>>> code pretty well alrea
On 07/02/2012 11:35 PM, Mohammed, Afzal wrote:
> Hi Jon,
>
> On Mon, Jul 02, 2012 at 22:59:03, Hunter, Jon wrote:
>> On 07/02/2012 04:43 AM, Mohammed, Afzal wrote:
>
>>> Not sure whether you are fine with fixing up this patch with added diff
>>>
>>> Assuming inferences so far is not wrong, right
On 07/02/2012 07:05 PM, Kevin Hilman wrote:
> NeilBrown writes:
>
>> On Mon, 2 Jul 2012 13:26:38 -0500 Jon Hunter wrote:
>>
>>>
>>> On 07/02/2012 01:07 PM, Kevin Hilman wrote:
>>>> + Neil Brown
>>>>
>>>> Hi Jon,
>
On 07/02/2012 01:07 PM, Kevin Hilman wrote:
> + Neil Brown
>
> Hi Jon,
>
> Jon Hunter writes:
>
>> Currently the gpio _runtime_resume/suspend functions are calling the
>> get_context_loss_count() platform function if the function is populated for
>> a
On 07/01/2012 03:45 AM, Tony Lindgren wrote:
> * Shilimkar, Santosh [120629 21:23]:
>> On Fri, Jun 29, 2012 at 10:52 PM, Jon Hunter wrote:
>>> Currently the gpio _runtime_resume/suspend functions are calling the
>>> get_context_loss_count() platform function if th
On 07/02/2012 04:43 AM, Mohammed, Afzal wrote:
> Hi Tony,
>
> On Mon, Jul 02, 2012 at 12:06:51, Tony Lindgren wrote:
>> * Jon Hunter [120628 09:48]:
>
>>> The above change seems to imply that Tony's n900 is dependent on the
>>> bootloader settings
On 07/02/2012 01:36 AM, Tony Lindgren wrote:
> * Jon Hunter [120628 09:48]:
>>
>> [2.792510] OneNAND driver initializing
>> [2.797576] omap2-onenand omap2-onenand: initializing on CS2, phys base
>> 0x2000, virtual base c88c, freq 0 MHz
>> [
not
working for you, but it was working fine for me.
> On Tue, Jun 12, 2012 at 11:41:27PM +0100, Jon Hunter wrote:
>> On 06/12/2012 04:31 PM, Will Deacon wrote:
>>> That's understandable -- one of the CPUs is likely more loaded than the
>>> other. However, I'd lik
On 06/29/2012 11:27 PM, Shilimkar, Santosh wrote:
> + Paul, Rajendra,
>
> On Sat, Jun 30, 2012 at 2:34 AM, Jon Hunter wrote:
>> Note: Re-sending with updated kernel doc.
>>
>> The wake-up power domain is an alway-on power domain and so this power domain
>> d
On 06/29/2012 04:07 PM, Greg Kroah-Hartman wrote:
> On Fri, Jun 29, 2012 at 07:16:19PM +0530, Shilimkar, Santosh wrote:
>> Greg,
>>
>> On Tue, Jun 26, 2012 at 1:19 PM, Shilimkar, Santosh
>> wrote:
>>>
>>> On Tue, Jun 26, 2012 at 10:56 AM, Rajendra Nayak wrote:
On Tuesday 26 June 2012 10:53
eagle and validated CORE RET still working (using
Paul's 32k timer patch [1]).
[1] http://marc.info/?l=linux-omap&m=13453229888&w=2
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/powerdomain.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/a
701 - 800 of 1176 matches
Mail list logo
