On 9/9/2010 7:47 AM, Cousson, Benoit wrote:
On 9/9/2010 2:07 PM, Balbi, Felipe wrote:
Hi Santosh,
On Thu, Sep 09, 2010 at 07:02:46AM -0500, Shilimkar, Santosh wrote:
Felipe is suggesting not to add this support where as you want to
have this support.
Sorry if I haven't understood the
From: Jon Hunter jon-hun...@ti.com
J-Type DPLLs have additional configuration parameters that need to
be programmed when setting the multipler and divider for the DPLL.
These parameters being the sigma delta divider (SD_DIV) for the DPLL
and the digital controlled oscillator (DCO) to be used
On 12/18/2010 4:08 AM, Paul Walmsley wrote:
Hello Jon
On Fri, 17 Dec 2010, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
J-Type DPLLs have additional configuration parameters that need to
be programmed when setting the multipler and divider for the DPLL.
These parameters being
On 2/2/2011 3:03 PM, Elvis Dowson wrote:
Hi,
Is there a register that I can read, to determine if an OMAP34xx chip
was powered up because of a cold boot (power cycled off to on), or a warm boot
(software initiated reset or software initiated reboot)?
Yes, you can read the PRM_RSTST
which need custom VDD1/2 OPPs, the opp table can be
updated by the board file on a need basis after the
omap3_pm_init_opp_table call. The OPPs introduced here are the
official OPP table at this point in time.
Tested on: SDP3430, SDP3630
Cc: Benoit Cousson b-cous...@ti.com
Cc: Jon Hunter
On 6/23/2010 4:10 PM, Anders, David wrote:
Shouldn't this be a board-specific option, and not set for every
OMAP4-based config?
As I understand it, any of the omap4 devices that are using the Inventra need
to have at a minimum of the NOP USB Transceiver. Enabling the NOP transceiver
doesn't
On 6/23/2010 4:12 PM, Koen Kooi wrote:
Shouldn't this be a board-specific option, and not set for every
OMAP4-based config?
If that's true, why do the davinci and blackfin archs force it?
DaVinci only has an internal PHY, I don't think that there is anyway to
use an external PHY with
From: Jon Hunter jon-hun...@ti.com
When changing the L3 clock frequency, the CPU is executing from internal RAM
and the SDRC clock is disabled. During this time accesses made to external
DDR are stalled. If the ARM subsystem attempts to access the DDR while the
SDRC clock is disabled
Russell King - ARM Linux wrote:
Moreover, I don't think forcing frame pointers to be enabled even with
unwinding support is the right solution - if we have frame pointers
there's no need for unwind support (so maybe the right answer is to
force unwind support off for the time being?)
Ok, so I
Pandita, Vikram wrote:
The ball/pad numbers may change due to the package, but the registers
used to configure the pin muxing and the pin muxing options will not
change. So from a software standpoint it is the same.
The OMAP3530 is available in 3 packages, namely CBB, CBC and CUS
according to
From: Jon Hunter jon-hun...@ti.com
There are two scenarios where a race condition could result in a hang in the
prcm_interrupt handler. These are:
1). Waiting for PRM_IRQSTATUS_MPU register to clear.
Bit 0 of the PRM_IRQSTATUS_MPU register indicates that a wake-up event is
pending for the MPU
On Mon, 2009-06-22 at 18:44 -0500, Kevin Hilman wrote:
Jon Hunter jon-hun...@ti.com writes:
From: Jon Hunter jon-hun...@ti.com
There are two scenarios where a race condition could result in a hang in the
prcm_interrupt handler. These are:
IIRC, the RX51 tree has a workaround for some
From: Jon Hunter jon-hun...@ti.com
Depending on the OMAP3 boot mode the MUSB peripheral may or may not be
accessible when the kernel starts.
The OMAP3 can boot from several devices including USB. The sequence of the
devices the OMAP will attempt to boot from is configured via the sys_boot
pins
Kevin Hilman wrote:
Thanks for this fix.
I'll consider this another vote for switching to omap_hwmod.
To be honest, I am not too familiar with omap_hwmod. Only what I have
seen here:
http://patchwork.kernel.org/patch/28171/
Anyway, sounds like a good idea. I am not a fan of the current
From: Jon Hunter jon-hun...@ti.com
This is version 2 of this patch. I have incorporated the changes
recommended by Kevin Hilman.
Depending on the OMAP3 boot mode the MUSB peripheral may or may not be
accessible when the kernel starts.
The OMAP3 can boot from several devices including USB
Kevin Hilman wrote:
Jon, you're raising the bar and spoiling us with such descriptive
changelogs. If everyone was as thorough as you, the world would be a
merrier place. :)
Thanks, pushing to PM branch and pm-2.6.29.
Kevin
No problem. You are welcome. Just an FYI, but for 2.6.29, I was
-2.6/patches/
From st...@rowland.harvard.edu Thu Aug 13 16:37:16 2009
From: Jon Hunter jon-hun...@ti.com
Date: Wed, 12 Aug 2009 11:57:59 -0400 (EDT)
Subject: USB: EHCI: ensure all watchdog timer events are deleted when
suspending usb
To: Greg KH g...@kroah.com, Jon Hunter jon-hun...@ti.com
Cc
Kevin Hilman wrote:
Jon,
Do you know if this will be queued as a fix for .31? or if it will wait
for the .32 merge window.
Kevin
I am not sure. I was just browsing Greg's page and I found the following
text file.
Mikko Rapeli wrote:
Hello,
I'd like to test out newer kernel on a Beagleboard B6 but latest
trees from Linus, linux-omap and linux-omap/for-next seem to be failing at
early boot [1] with omap3_beagle_defconfig.
Some bisecting shows that ARM_UNWIND broke something in the defconfig since
Sripathy, Vishwanath wrote:
OSWR stands for Open Switch With Retention.
Not to split hairs, but the OMAP3430 Technical Reference Manual states
that OSwR means Open Switch Retention. So no with. This W always
bother me too!
Cheers
Jon
--
To unsubscribe from this list: send the line
Kevin Hilman wrote:
Hello,
I've rebased/updated the PM branch based on current linux-omap master
branch (2.6.32-rc1 based.)
I've also updated the OMAP Power Management wiki, and the 'Current
version' section highlights the changes, supported platforms as well
as the features that have made it
Tony Lindgren wrote:
From: Janusz Krzysztofik jkrzy...@tis.icnet.pl
DSP public peripherals used to work on OMAP1510 based (or all OMAP1 class?)
machines as long as old dspgateway code were present in the l-o tree. For
several months it is no longer included, breaking support for McBSP1 based
Hi Paul
On 8/28/2011 23:09, Paul Walmsley wrote:
Just doublechecking on this patch. Does anything need to be changed
before we merge this? I can take a look at the autogeneration script if
that's the only issue left.
Sorry, I have been out on holiday. I believe that was the only problem
Hi Paul,
On 8/28/2011 23:11, Paul Walmsley wrote:
Hi Jon,
On Thu, 7 Jul 2011, Jon Hunter wrote:
Various clock fixes for OMAP3 and OMAP4 devices.
Just doublechecking on these patches, some of them don't have
Signed-off-by:'s from you. Seems like we should add those?
Ok, let me look
From: Jon Hunter jon-hun...@ti.com
Various clock fixes for OMAP3 and OMAP4 devices.
Jon Hunter (4):
OMAP4: Add missing clock divider for OCP_ABE_ICLK
OMAP3+: use DPLLs recalc function instead of omap2_get_dpll_rate
OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices
OMAP4
From: Jon Hunter jon-hun...@ti.com
The parent clock of the OCP_ABE_ICLK is the AESS_FCLK and the
parent clock of the AESS_FCLK is the ABE_FCLK...
ABE_FCLK -- AESS_FCLK -- OCP_ABE_ICLK
The AESS_FCLK and OCP_ABE_ICLK clocks both have dividers which
determine their operational frequency. However
the REGM4XEN bit.
The REGM4XEN bit is only implemented for the ABE DPLL on OMAP4 and so
only dpll_abe_ck uses omap4_dpll_regm4xen_round_rate() and
omap4_dpll_regm4xen_recalc() functions.
Signed-off-by: Mike Turquette mturque...@ti.com
Tested-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2
dividers depending on register settings.
This requires a special round_rate function that might yield a rate
different from the initial target.
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/dpll3xxx.c |2 +-
1 files changed, 1
From: Jon Hunter jon-hun...@ti.com
This is a continuation of Mike Turquette's patch OMAP3+: use
DPLL's round_rate when setting rate.
omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call
omap2_get_dpll_rate() explicitly. It may be necessary for some
DPLLs to use a different function
From: Jon Hunter jon-hun...@ti.com
The OMAP36xx and OMAP4xxx DPLLs have a different internal reference
clock frequency (fint) operating range than OMAP3430. Update the
dpll_test_fint() function to check for the correct frequency ranges
for OMAP36xx and OMAP4xxx.
For OMAP36xx and OMAP4xxx devices
From: Jon Hunter jon-hun...@ti.com
Currently the interface clocks for the two SLIMBUS peripherals are
named slimbus1_fck and slimbus2_fck. Rename these clocks to be
slimbus1_ick and slimbus2_ick so it is clear that these are
interface clocks and not functional clocks.
Signed-off-by: Jon Hunter
Hi Paul,
On 9/28/2011 1:59, Paul Walmsley wrote:
Hi Jon and Mike,
On Fri, 16 Sep 2011, Jon Hunter wrote:
From: Mike Turquettemturque...@ti.com
OMAP4 DPLL_ABE can enable a 4X multipler on top of the normal MN multipler
and divider. This is achieved by setting
Hi Paul,
On 9/28/2011 2:02, Paul Walmsley wrote:
Hi,
On Fri, 16 Sep 2011, Jon Hunter wrote:
From: Mike Turquettemturque...@ti.com
omap3_noncore_dpll_set_rate uses omap2_dpll_round_rate explicitly. Instead
use the struct clk pointer's round_rate function to allow for DPLL's with
special
Hi Paul,
On 10/6/2011 20:40, Paul Walmsley wrote:
On Fri, 16 Sep 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
The OMAP36xx and OMAP4xxx DPLLs have a different internal reference
clock frequency (fint) operating range than OMAP3430. Update the
dpll_test_fint() function to check
Hi Benoit,
On 10/7/2011 3:23, Cousson, Benoit wrote:
Hi Paul Jon,
On 10/7/2011 3:42 AM, Paul Walmsley wrote:
+ Benoît
On Fri, 16 Sep 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
Currently the interface clocks for the two SLIMBUS peripherals are
named slimbus1_fck
Hi Benoit,
On 10/10/2011 4:54, Cousson, Benoit wrote:
Hi Jon,
On 10/8/2011 12:46 AM, Hunter, Jon wrote:
Hi Benoit,
On 10/7/2011 3:23, Cousson, Benoit wrote:
Hi Paul Jon,
On 10/7/2011 3:42 AM, Paul Walmsley wrote:
+ Benoît
On Fri, 16 Sep 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun
Hi Govindraj,
On 10/18/2011 10:26, Govindraj.R wrote:
Move the errata handling mechanism from serial.c to omap-serial file
and utilise the same func in driver file.
Errata i202, i291 are moved to be handled with omap-serial
Moving the errata macro from serial.c file to driver header file
as
Hi Govindraj,
On 11/11/2011 3:59, Govindraj.R wrote:
Move the errata handling mechanism from serial.c to omap-serial file
and utilise the same func in driver file.
Errata i202, i291 are moved to be handled with omap-serial
Moving the errata macro from serial.c file to driver header file
as
Hi Govindraj,
On 11/16/2011 4:13, Govindraj wrote:
On Tue, Nov 15, 2011 at 1:20 AM, Jon Hunterjon-hun...@ti.com wrote:
Hi Govindraj,
[...]
oh = uart-oh;
- uart-dma_enabled = 0;
name = DRIVER_NAME;
omap_up.dma_enabled = uart-dma_enabled;
On 06/29/2012 11:27 PM, Shilimkar, Santosh wrote:
+ Paul, Rajendra,
On Sat, Jun 30, 2012 at 2:34 AM, Jon Hunter jon-hun...@ti.com wrote:
Note: Re-sending with updated kernel doc.
The wake-up power domain is an alway-on power domain and so this power domain
does not have a power state
, 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 like to confirm whether or not you see what I see. With
the 4430_init
On 07/02/2012 01:36 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [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
[2.808929] OneNAND
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 jon-hun...@ti.com [120628 09:48]:
The above change seems to imply that Tony's n900 is dependent on the
bootloader settings
and not those being set by the kernel
On 07/01/2012 03:45 AM, Tony Lindgren wrote:
* Shilimkar, Santosh santosh.shilim...@ti.com [120629 21:23]:
On Fri, Jun 29, 2012 at 10:52 PM, Jon Hunter jon-hun...@ti.com wrote:
Currently the gpio _runtime_resume/suspend functions are calling the
get_context_loss_count() platform function
On 07/02/2012 01:07 PM, Kevin Hilman wrote:
+ Neil Brown
Hi Jon,
Jon Hunter jon-hun...@ti.com writes:
Currently the gpio _runtime_resume/suspend functions are calling the
get_context_loss_count() platform function if the function is populated for
a gpio bank. This function is used
On 07/02/2012 07:05 PM, Kevin Hilman wrote:
NeilBrown ne...@suse.de writes:
On Mon, 2 Jul 2012 13:26:38 -0500 Jon Hunter jon-hun...@ti.com wrote:
On 07/02/2012 01:07 PM, Kevin Hilman wrote:
+ Neil Brown
Hi Jon,
Jon Hunter jon-hun...@ti.com writes:
Currently the gpio _runtime_resume
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 now this
On 07/03/2012 03:17 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [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 already follows the device spec timings. And using cycle
: Santosh Shilimkar santosh.shilim...@ti.com
Cc: NeilBrown ne...@suse.de
Reported-by: Franky Lin fran...@broadcom.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Franky Lin fran...@broadcom.com
Tested-by: NeilBrown ne...@suse.de
Signed-off-by: Jon Hunter jon-hun...@ti.com
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 this series?
Cheers
Jon
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-tree binding for OMAP timers and
I have encountered
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 feedback from design. They were trying to confirm
my
On 07/09/2012 11:47 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
From: R Sricharan r.sricha...@ti.com
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
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 af...@ti.com [120710 03:09]:
On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120709 23:24]:
For the
Hi Paul,
On 07/12/2012 04:17 PM, Paul Walmsley wrote:
Hello Jon
On Thu, 7 Jun 2012, Jon Hunter wrote:
By removing the CLKDM_CAN_ENABLE_AUTO flag, the EMU clock domain will always
remain on and hence, this will break low-power modes. The EMU clock domain
only
support the SW_WKUP
Hi Will,
On 07/13/2012 09:00 AM, Will Deacon wrote:
Jon,
[cutting out realms of context!]
Thanks! My inbox thanks you too ;-)
On Fri, Jul 13, 2012 at 02:54:59PM +0100, Jon Hunter wrote:
Another proposal I also thought of is re-working the flags to describe
the HW mode to be used when
with.
- 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 nodes
ARM: OMAP3
is not added and there
is a better way to pass an ID from device-tree let me know.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
.../devicetree/bindings/arm/omap/timer.txt | 34 +++
arch/arm/boot/dts/omap3.dtsi | 104
with.
- 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: Dynamically disable secure
is not added and there
is a better way to pass an ID from device-tree let me know.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
.../devicetree/bindings/arm/omap/timer.txt | 34 +++
arch/arm/boot/dts/omap3.dtsi | 104
is not added and there
is a better way to pass an ID from device-tree let me know.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
.../devicetree/bindings/arm/omap/timer.txt | 34 +++
arch/arm/boot/dts/omap3.dtsi | 104
/gmane.linux.ports.arm.omap/79203
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
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 insertions(+)
diff
-by: Jon Hunter jon-hun...@ti.com
---
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/timer.c
index e3b9931..ad5b29a
-by: Jon Hunter jon-hun...@ti.com
---
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/timer.c
index e3b9931..ad5b29a
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 jon-hun...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 12
with.
- 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: Dynamically disable secure
is not added and there
is a better way to pass an ID from device-tree let me know.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
.../devicetree/bindings/arm/omap/timer.txt | 34 +++
arch/arm/boot/dts/omap3.dtsi | 104
/gmane.linux.ports.arm.omap/79203
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
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 insertions(+)
diff
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
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 jon-hun...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 12
-by: Jon Hunter jon-hun...@ti.com
---
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/timer.c
index e3b9931..ad5b29a
On 07/13/2012 06:41 PM, Paul Walmsley wrote:
Hi
On Fri, 13 Jul 2012, Jon Hunter wrote:
1. If DT blob is present, then let HWMOD create the timer devices
dynamically.
This probably should read is _not_ present, yes?
Yes, you are right. What a balls-up ...
Thanks
Jon
--
To unsubscribe
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.
For each timer an alias is being added
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 from
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 together. However, I could see that patch
Hi Tony,
On 07/18/2012 02:19 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [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_timer_request_by_cap(int cap)?
I
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 together. However, I could see that patch
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 turning on the CLKDM, when the CLKDM
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.
Add documentation for timer properties specific to OMAP
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 node
-
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 luck getting to the bottom of this?
I am still waiting
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 OMAP. Latest can be found here [1]. I have
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.
But direction
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 pointing to dma controller node
- flags word, a bit map that can hold these flags
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
since I
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
li...@arm.linux.org.uk 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.
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 together. However, I could see that patch
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.
commit
domain to turn off on OMAP3
whilst testing PMU.
Cheers
Jon
commit a0307bd539ecef976793679a1c4ff0d47b22c4bd
Author: Jon Hunter jon-hun...@ti.com
Date: Mon Jul 30 18:04:06 2012 -0500
ARM: OMAP2/3: Allow HWMOD to disable clock domains
Currently when HWMOD attempts to disable a clock
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 wrote:
Commit 4da71ae6 (OMAP: clockdomain: Arch specific
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 safe to
remove this but I can do some
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 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 that seems to be a good place to collate
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
boot-up if enabled
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 patch [1] with the following changes ...
1. Re
into hardware-supervised idle.
This patch is an equal collaboration with Jon Hunter
jon-hun...@ti.com. Ming Lei ming@canonical.com, Will Deacon
will.dea...@arm.com, Madhav Vij m...@ti.com, Kevin Hilman
khil...@ti.com, Benoît Cousson b-cous...@ti.com, and Santosh
Shilimkar santosh.shilim
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_request_channel()
we are going to get a channel
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've also
included your runtime PM hooks
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 07/13/2012 05:26 PM, Jon Hunter wrote:
Add the 12 GP timers nodes present
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
as
general purpose (GP).
For OMAP3 devices
1 - 100 of 1153 matches
Mail list logo
