.orig
3667957 196256 113216 3977429 3cb0d5 vmlinux.3430sdp
Paul Walmsley (2):
OMAP3 SDRC: Add rounded rates for devices using the Qimonda SDRAM
OMAP3 SDRC: Fix autorefresh counter for Qimonda SDRAM 66.6MHz rate
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h|
The autorefresh counter value for the 66.6MHz rate for the Qimonda SDRAM
part is wrong; fix it.
Signed-off-by: Paul Walmsley
---
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h|6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-qimonda
.
Signed-off-by: Paul Walmsley
Tested-by: Kevin Hilman
---
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 22
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
b/arch/arm/mach-omap2/sdram-qimonda
On Thu, 14 May 2009, Woodruff, Richard wrote:
> > Also when reviewing the timing calculations, it appears that the lowest
> > speed
> > setting had an error in its autorefresh counter value. I don't know if
> > anything out there still uses this low-speed setting - my recollection is
> > that it
b5 vmlinux.3430sdp
Paul Walmsley (2):
OMAP3 SDRC: Add rounded rates for devices using the Qimonda SDRAM
OMAP3 SDRC: Drop 133.3MHz, 66.6MHz rates from Qimonda SDRAM params file
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 25 ++--
1 files changed, 12 inserti
.
Signed-off-by: Paul Walmsley
Tested-by: Kevin Hilman
---
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
b/arch/arm/mach-omap2/sdram-qimonda
Boards that used 133.3MHz maximum rate SDRAM were never released to the
public and presumably used the OMAPZoom kernel; so, drop these unused
rates. Viz.:
http://marc.info/?l=linux-omap&m=124232922426311&w=2
This patch is a collaboration between Richard Woodruff
and Paul Walmsley .
On Thu, 14 May 2009, Tony Lindgren wrote:
> * Paul Walmsley [090514 12:52]:
> > Hi,
> >
> > This series updates some SDRAM parameter settings for the Qimonda parts
> > used on some 3430SDP boards.
> >
> > Drop the 133.3MHz/66.6MHz rates from the Qi
On Wed, 25 Feb 2009, Roel Kluin wrote:
> with while (i++ < MAX_CLOCK_ENABLE_WAIT); i can reach MAX_CLOCK_ENABLE_WAIT +
> 1
> after the loop, so if (i == MAX_CLOCK_ENABLE_WAIT) that's still success.
Hi Roel
it's a worst-case bailout value that is significantly larger than it needs
to be, so bei
Hi Kevin
On Wed, 20 May 2009, Kevin Hilman wrote:
> diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
> index c832d83..d7807e2 100644
> --- a/arch/arm/mach-omap2/sdrc.c
> +++ b/arch/arm/mach-omap2/sdrc.c
> @@ -136,5 +136,13 @@ void __init omap2_sdrc_init(struct omap_sdrc_params
On Thu, 21 May 2009, Mike Chan wrote:
> On Thu, May 21, 2009 at 3:37 PM, Paul Walmsley wrote:
> >
> > would suggest keeping pin remuxing in board-*.c or maybe chip-*.c files;
> > ideally this file would only pertain to the SDRC IP block itself.
>
> Is there a reason
and Paul Walmsley .
Signed-off-by: Paul Walmsley
Cc: Richard Woodruff
Cc: Tony Lindgren
---
arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h | 20 +++-
1 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
b/arch/
Hi Jarkko
On Fri, 22 May 2009, Jarkko Nikula wrote:
> EHCI port is not working on my Beagle C2 with linux-omap but is working
> with this one:
>
> http://www.angstrom-distribution.org/demo/beagleboard/uImage-2.6.28-r17-beagleboard.bin
>
> Looks like the error below was fixed by the
> 205f37af71
Hello Russell,
On Tue, 12 May 2009, Paul Walmsley wrote:
> This series contains OMAP clock and SDRAM controller patches against
> v2.6.30-rc5. If you are happy with these, Tony will merge them into
> his for-next branch for you to pull.
>
> This series includes the cl
On Tue, 26 May 2009, Russell King - ARM Linux wrote:
> On Tue, May 26, 2009 at 10:29:52AM -0600, Paul Walmsley wrote:
> > Hello Russell,
> >
> > On Tue, 12 May 2009, Paul Walmsley wrote:
> >
> > > This series contains OMAP clock and SDRAM controller patche
eries completes basic support for OMAP3 CORE DVFS. A few other
minor bugs are fixed by the off-by-one patch and the GPIO debounce
clock patch.
regards,
- Paul
---
Paul Walmsley (8):
OMAP3 clock: GPIO de-bounce clocks don't affect module idle state
OMAP3 SDRC: set FIXEDDELAY whe
The original CDP kernel that this code comes from waited for 0x800
loops after switching the CORE DPLL M2 divider. This does not appear
to be necessary.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/sram34xx.S |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a
On the OMAP3, initialize SDRC timings when the kernel boots. This ensures
that the kernel is running with known, optimized SDRC timings, rather than
whatever was configured by the bootloader.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock34xx.c |3 ---
arch/arm/mach-omap2/io.c
500MHz MPU frequency at
room temperature, 64 loops seems to work okay; so add another 32 loops for
environmental and process variation.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock34xx.c| 30 --
arch/arm/mach-omap2/sram34xx.S | 20
Program the SDRC_MR_0 register as well during SDRC clock changes.
This register allows selection of the memory CAS latency. Some SDRAM
chips, such as the Qimonda HYB18M512160AF6, have a lower CAS latency
at lower clock rates.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock34xx.c
Clean up comments and copyrights on the CORE DPLL3 M2 divider change code.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/sram34xx.S | 45 +---
1 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm
Correspondence with the TI OMAP hardware team indicates that
SDRC_DLLA_CTRL.FIXEDDELAY should be initialized to 0x0f. This number
was apparently derived from process validation. This is only used
when the SDRC DLL is unlocked (e.g., SDRC clock frequency less than
83MHz).
Signed-off-by: Paul
From: Tero Kristo
Previously only 1 and 2 was supported. This is needed for DVFS VDD2 control.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock34xx.c|9 +++--
arch/arm/mach-omap2/sram34xx.S |8 +---
arch/arm/plat-omap/include/mach/sram.h |6 --
a
From: Roel Kluin
with while (i++ < MAX_CLOCK_ENABLE_WAIT); i can reach MAX_CLOCK_ENABLE_WAIT + 1
after the loop, so if (i == MAX_CLOCK_ENABLE_WAIT) that's still success.
Signed-off-by: Roel Kluin
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock.c |2 +-
arch/
GPIO de-bounce clocks don't have any impact on the module idle state, so
the clock code should not wait for the module to enable after the de-bounce
clocks are enabled.
Problem found by Kevin Hilman .
Signed-off-by: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/clock3
Convert omap3_sram_configure_core_dpll() to use macros rather than
magic numbers.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/sram34xx.S | 53 +---
1 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/sram34xx.S b
Hi Jean,
a minor request: it is easier to comment on these patches if they are
included inline in the E-mail message, rather than attached. That way
code comments can be inlined in the reply.
On Tue, 26 May 2009, Jean Pihet wrote:
> Here is a patch for the SDRC 2nd CS support. It applies on t
Hello Rajendra,
On Mon, 1 Jun 2009, Rajendra Nayak wrote:
> This patch adds 2 more entries for new SDRC clock rates
> (16600 and 8300) in the sdrc params table for
> Qimonda HYB18M512160AF-6 sdram part.
> Without this CORE dvfs is broken on the 3430SDP as
> omap2_sdrc_get_params() call in
Beagle and 3430SDP. Compile-tested on 2430SDP and
N800.
Comments welcome and solicited.
- Paul
---
textdata bss dec hex filename
3411061 192960 104048 3708069 3894a5 vmlinux.omap3beagle.old
3417637 194016 104080 3715733 38b295 vmlinux.omap3beagle
Paul Walmsley (8
After the recent clkdev conversion, struct clks are no longer
locatable located by the struct clk name via clk_get(). Core code
separate from the platform_device system needs to do this. This patch
adds an omap_clk_get_by_name() function for this purpose.
Signed-off-by: Paul Walmsley
---
arch
clocks earlier, immediately after omap2_clk_init().
This is in turn necessary since otherwise clock tree usecounts on
clocks like dpll4_m2x2_ck will be bogus, which can cause the
currently-active console UART clock to be disabled during boot.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/board
of debugging and reference.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock24xx.h | 52 +-
arch/arm/mach-omap2/clock34xx.h | 60 ---
2 files changed, 56 insertions(+), 56 deletions(-)
diff --git a/arch/arm/mach
All MPU-related clocks should be in the mpu_clkdm. This is needed for the
upcoming omap_hwmod patches, which needs to know the clockdomain that arm_fck
is in.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock34xx.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
wing patch),
rather than a per-clock data structure. The new code will use these new
functions to handle waiting for modules to enable.
Once hardware module data is filled in for all of the on-chip devices,
the clock framework code to handle IDLEST waiting can be removed.
Signed-off-by: Pau
Connect the omap_hwmod code to the kernel boot. Create some basic
interconnect and device structures for OMAP2/3 chips.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/io.c | 17 +++
arch/arm/mach-omap2/omap_hwmod_2420.h | 140
arch/arm/mach
Add basic HSMMC hardware modules for OMAP2430 and OMAP34xx.
The integration data is so similar between 2430 and 34xx in this
case that these entries could almost be shared; that is probably worth
investigating.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_2430.h | 143
k are welcome and solicited.
- Paul
---
omap_device
textdata bss dec hex filename
3417637 194016 104080 3715733 38b295 vmlinux.omap3beagle.orig
3420233 194016 104080 3718329 38bcb9 vmlinux.omap3beagle
Paul Walmsley (3):
OMAP2/3 MMC: initial conversion to omap_d
Split OMAP-common MMC device registration into OMAP1 and OMAP2
components. This is in preparation for the omap_device conversion of
the HSMMC portions.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap1/devices.c | 41 ++
arch/arm/mach-omap2/devices.c | 46
_data activate, deactivate functions, or via an custom
bus/device type for OMAP.
Signed-off-by: Paul Walmsley
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Tony Lindgren
Cc: Rajendra Nayak
Cc: Vikram Pandita
Cc: Sakari Poussa
Cc: Ansnd Sawant
Cc: Santosh Shilimkar
Cc: Eric Thomas
Cc: Richard Woo
set_power hook.
Note that the non-HS MMC driver, used on 2420 and previous, has not yet
been converted.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/devices.c | 146 -
arch/arm/mach-omap2/mmc-twl4030.c | 12 ++-
arch/arm/plat-omap/include/mach
Hi Jarkko,
On Sat, 23 May 2009, Paul Walmsley wrote:
> On Fri, 22 May 2009, Jarkko Nikula wrote:
>
> > EHCI port is not working on my Beagle C2 with linux-omap but is working
> > with this one:
> >
> > http://www.angstrom-distribution.org/demo/beagleboard/uIm
On Tue, 28 Oct 2008, Kevin Hilman wrote:
> Paul Walmsley wrote:
> > Commit 8b1f0bd44fe490ec631230c8c040753a2bda8caa introduced a bug that
> > caused non-CORE DPLL rates to be incorrectly set on boot in
> > omap3_noncore_dpll_enable(). Debugged by Tomi Valkeinen
> > &
yOn Wed, 29 Oct 2008, Kevin Hilman wrote:
> Hi Paul,
>
> This patch doesn't fix the problem. :(
>
> Kevin
>
OK, could you private E-mail me the patches you are using to test?
thanks for testing
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a
The SGX device on OMAP3 does not support retention, so remove RET from the
list of possible SGX power states. Problem debugged by Richard Woodruff
<[EMAIL PROTECTED]>.
Signed-off-by: Richard Woodruff <[EMAIL PROTECTED]>
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Hi,
On Thu, 6 Nov 2008, Paul Walmsley wrote:
> The current git head crashes on boot due to some MTD-related problem on
> 3430SDP. Partial boot log below.
Timo-Pekka's robot tracked this down to commit
4a4ada55c1bdaa2b9fd1293611b55ceba14b13e7, which is the system_rev to
omap_r
Hi Russell,
I've been on holiday, hence the delayed E-mail.
On Mon, 27 Oct 2008, Russell King - ARM Linux wrote:
> If I take this further, and detect clocks which result in
> omap2_clk_wait_ready() being called, but we don't have a corresponding
> [if]ck, I see at least these four warnings:
>
>
Fix one remaining user of system_rev. This patch is needed for
3430SDP ES2 to boot after 4a4ada55c1bdaa2b9fd1293611b55ceba14b13e7.
Bisected by Timo-Pekka Launonen's <[EMAIL PROTECTED]>
list robot.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Cc: Timo-Pekka Launonen <[
On Wed, 5 Nov 2008, Tony Lindgren wrote:
> * Paul Walmsley <[EMAIL PROTECTED]> [081105 11:39]:
> >
> > The SGX device on OMAP3 does not support retention, so remove RET from the
> > list of possible SGX power states. Problem debugged by Richard Woodruff
> >
Hi,
The current git head crashes on boot due to some MTD-related problem on
3430SDP. Partial boot log below.
- Paul
<4>Driver 'sd' needs updating - please use bus_type methods
Driver 'sd' needs updating - please use bus_type methods
Hello Sergio,
On Fri, 7 Nov 2008, Aguirre Rodriguez, Sergio Alberto wrote:
> I'm attempting this with a 3430SDP-VG5.0.1 (ES3.0), and I was using the same
> commit.
Sounds like the OMAP ES revision detection code is broken again for ES3
chips.
You might want to try adding some printk()s to the
Hi Sergio,
On Fri, 7 Nov 2008, Aguirre Rodriguez, Sergio Alberto wrote:
> But one other thing is that with latest commit, the Tux that shows up on
> the LCD looks greenish. Does it happen on your SDP ES2.0?
I don't have physical access to the SDP, so unfortunately I don't know
what's on the LC
On Thu, 6 Nov 2008, Aguirre Rodriguez, Sergio Alberto wrote:
> Today when I attempted to boot on an 3430SDP with latest commit, I got a
> kernel dump, which is this:
> PC is at cfi_qry_present+0x1c0/0x29c
f7429fd378a29cf6947c2613e0fd6e6e36165167 boots fine now on the 3430SDP
ES2 that I use her
Hi Jouni,
On Fri, 7 Nov 2008, Högander Jouni wrote:
> What do you Paul think about patch below:
I'm okay with it, but one potential problem: won't this prevent the chip
from entering retention, since SGX will be set to ON?
Anyway, if you agree this is a problem, what do you think about adding
On Wed, 12 Nov 2008, Peter 'p2' De Schrijver wrote:
> This patch causes _omap3_noncore_dpll_lock to wait for clocks marked as
> WAIT_READY to be ready before continuing. This is necessary for MPU/DSP
> DVFS to work correctly.
Acked-by: Paul Walmsley <[EMAIL PROTECTED]>
Hello,
this series fixes a bug in the OMAP3 DPLL rate rounding code that will
attempt to program the DPLL to use an internal clock frequency that
does not exist in the FREQSEL table in 34xx TRM 4.7.6.2. This mostly
seems to generate warnings, but can potentially hang the system.
As part of this
Remove some clutter from omap2_dpll_round_rate().
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock.c | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
<[EMAIL PROTECTED]> put up with several
test cycles of this patch - thanks Peter.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Cc: Peter de Schrijver <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock.c | 35 ++-
1 files changed, 18 insertion
up.
The first pass through the rate rounding code will update the DPLL max
and min dividers appropriately, so later rate rounding passes will run
faster than the first.
Peter de Schrijver <[EMAIL PROTECTED]> put up with several
test cycles of this patch - thanks Peter.
Signed-off-by:
Hi Jouni, Kevin,
On Tue, 11 Nov 2008, Högander Jouni wrote:
> I wouldn't add any flags for this. The goal is finally to set all
> next_states as OFF until someone has set some constraint which
> prevents OFF usage. For now we need to use RET as default, because
> drivers are not supporting OFF mo
On Wed, 12 Nov 2008, Paul Walmsley wrote:
> On Wed, 12 Nov 2008, Peter 'p2' De Schrijver wrote:
>
> > This patch causes _omap3_noncore_dpll_lock to wait for clocks marked as
> > WAIT_READY to be ready before continuing. This is necessary for MPU/DSP
> > DVF
Hi Jouni,
one quick review comment:
On Fri, 14 Nov 2008, Jouni Hogander wrote:
> Check that wanted sleep state is supported by powerdomain. If it is
> not supported, then use next lowest supported state.
>
> Check also on suspend that state of pwrdm was lower or equal.
...
> diff --git a/arch
some bugs where the kernel would hang when returning
from retention or return the wrong rate for the DPLL.
This patch is a collaboration with Peter de Schrijver
<[EMAIL PROTECTED]> and Kevin Hilman
<[EMAIL PROTECTED]>.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Cc:
> > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> > index da098d2..babead5 100644
> > --- a/arch/arm/mach-omap2/pm34xx.c
> > +++ b/arch/arm/mach-omap2/pm34xx.c
> > @@ -239,8 +239,13 @@ static int set_pwrdm_state(struct powerdomain *pwrdm,
> > u32 state)
> > if (pw
IL PROTECTED]>
Acked-by: Paul Walmsley <[EMAIL PROTECTED]>
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 21 Nov 2008, Kevin Hilman wrote:
> Tony Lindgren <[EMAIL PROTECTED]> writes:
>
> > * Paul Walmsley <[EMAIL PROTECTED]> [081114 09:46]:
> >>
> >> During _omap3_noncore_dpll_lock(), if a DPLL has no active downstream
> >> clocks and DPLL
Hi,
This oops shows up shortly after logging in on BeagleBoard running
pm-20081119; posting here in case anyone recognizes what's going on.
/ is on a SanDisk SD Plus 4GB MMC card.
- Paul
(none) login: root
Unhandled fault: external abort on non-linefetch (0x1808) at 0xd809c104
Internal error:
On Fri, 21 Nov 2008, David Brownell wrote:
> On Friday 21 November 2008, Paul Walmsley wrote:
> > This oops shows up shortly after logging in on BeagleBoard running
> > pm-20081119; posting here in case anyone recognizes what's going on.
> > / is on a SanDisk SD Plus 4
-off-by: Kevin Hilman <[EMAIL PROTECTED]>
Acked-by: Paul Walmsley <[EMAIL PROTECTED]>
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
27;
drivers/misc/sti/sti-netlink.c:91: error: 'len' undeclared (first use in this
function)
drivers/misc/sti/sti-netlink.c:91: error: (Each undeclared identifier is
reported only once
drivers/misc/sti/sti-netlink.c:91: error: for each function it appears in.)
Signed-off-by: Paul Walmsley
On Sat, 29 Nov 2008, Kevin Hilman wrote:
> This series applies on top of on addtional patch which I mistakenly
> assumed was already in l-o. Here it is.
Just FYI, there's an updated version of this patch - following shortly...
- Paul
--
To unsubscribe from this list: send the line "unsubscribe
RE_CLK rate recalculation
to clock24xx.c:omap2xxx_clk_get_core_rate().
This patch is a collaboration between Tero Kristo <[EMAIL PROTECTED]>
and Paul Walmsley <[EMAIL PROTECTED]>. Thanks to Peter de Schrijver
<[EMAIL PROTECTED]> for help debugging and Kevin Hilman
<[EMAIL PR
TECTED]>
Acked-by: Paul Walmsley <[EMAIL PROTECTED]>
Måns, sorry this took so long, these two patches slipped through the
cracks here.
- Paul
On Tue, 21 Oct 2008, Mans Rullgard wrote:
> This makes clk_get_parent() work on OMAP2/3.
>
> Signed-off-by: Mans Rullgard <[EMAIL PROTECTED]>
Acked-by: Paul Walmsley <[EMAIL PROTECTED]>
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap&qu
On Fri, 5 Dec 2008, Tony Lindgren wrote:
> Pushing both to l-o tree today. Paul, I take it you will queue these
> up for mainline via your clock series?
Yes, and that will go for any other clock patches that you push into l-o
between now and the time that I send that series to Russell.
- Paul
-
Hi Kevin,
one quick comment.
On Mon, 1 Dec 2008, Kevin Hilman wrote:
> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/pm34xx.c | 55
> +
> arch/arm/plat-omap/include/mach/control.h |5 +++
> 2 files changed, 60 inserti
Hi Kevin,
another quick comment ...
On Mon, 1 Dec 2008, Kevin Hilman wrote:
> The bootloader may leave the MMC in a state which prevents hitting
> retention. Even when MMC is not compiled in, each MMC module needs to
> be forced into reset.
>
> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
>
On Mon, 1 Dec 2008, Kevin Hilman wrote:
> Add D2D clocks (modem_fck, sad2d_ick, mad2d_ick) to clock framework,
> and also ensure that auto-idle bits are set for these clocks during
> PRCM init.
>
> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
Acked-by: Paul Walms
quot;d2d_clkdm",
> .pwrdm = { .name = "core_pwrdm" },
> - .flags = CLKDM_CAN_HWSUP,
> + .flags = CLKDM_CAN_HWSUP_SWSUP,
> .clktrctrl_mask = OMAP3430ES1_CLKTRCTRL_D2D_MASK,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
&
Hi Tomi,
nice test case.
On Fri, 5 Dec 2008, [EMAIL PROTECTED] wrote:
> I have had strange clk_enable() crashes with DSS2, and now I managed to
> isolate it. With the included patch, on OMAP3 SDP board, with default
> kernel config, I always get the crash below. In this example case it
> happens
Hi Tomi,
On Mon, 8 Dec 2008, Tomi Valkeinen wrote:
> On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
> > Hi Tomi,
> >
> > nice test case.
> >
> > On Fri, 5 Dec 2008, [EMAIL PROTECTED] wrote:
> >
> > > I have had strange clk_
Hi Tomi,
On Tue, 9 Dec 2008, Tomi Valkeinen wrote:
> I don't know much about power and clock domains, but I believe I found
> the reason and fix for this. At least this should point to the right
> direction.
>
> It looks to me that when I do clk_enable() to a clock which is inside a
> turned off
Hi Igor,
On Wed, 10 Dec 2008, Igor Stoppa wrote:
> On Tue, 2008-12-09 at 16:14 -0700, ext Paul Walmsley wrote:
> >
> > On Tue, 9 Dec 2008, Tomi Valkeinen wrote:
> >
> > > It looks to me that when I do clk_enable() to a clock which is inside a
> > > turned
Hi David,
On Thu, 23 Oct 2008, David Brownell wrote:
> On Saturday 18 October 2008, Paul Walmsley wrote:
> > --- a/arch/arm/mach-omap2/omapdev-common.h
> > +++ b/arch/arm/mach-omap2/omapdev-common.h
> > @@ -21,6 +21,87 @@
> > #include "omapdev3xxx.h"
>
Hi Tero
one comment on this patch ...
On Thu, 11 Dec 2008, Tero Kristo wrote:
> Previously only 1 and 2 was supported. This is needed for DVFS VDD2 control.
> diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
> index 16eb4ef..832cd76 100644
> --- a/arch/arm/mach-omap2
Hi Jouni, Tomi,
On Thu, 11 Dec 2008, Högander Jouni wrote:
> So it seems that cm_* register should not be written while there is
> powerstate transition ongoing in * domain. Patch by Tomi is fixing
> this. As it seems to be transition related rather than pwrdm state,
> same line should be added
Hi Grazvydas, Steve,
On Thu, 11 Dec 2008, Grazvydas Ignotas wrote:
> > Can you please post whatever patches you need to apply to make it work
> > occasionally so others can also look at the issue?
>
> For pandora, making infinite while loops finite doesn't help much,
> kernel crashes later on. S
Hi Vikram,
looking at ehci-omap.c lines 190-204. Is there some reason why the
USBHOST clockdomain needs to be in software-supervised mode? Also, is
there some reason why the interface clock must be prevented from
auto-idling? This will cause problems with power management.
- Paul
On Thu, 11 Dec 2008, Grazvydas Ignotas wrote:
> On Thu, Dec 11, 2008 at 7:38 PM, Steve Sakoman wrote:
> > Here you go. Note that no infinite loop!
>
> Ah, so it no longer needs that revert, probably recent clock changes
> fixed that issue.
What is baffling is that it appears to be the presence
Drop some PRCM-related register writes that now appear to be
unnecessasry:
http://marc.info/?l=linux-omap&m=122901972412835&w=2
Cc: Vikram Pandita
---
drivers/usb/host/ehci-omap.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/ehci-omap
For testing only, not for merging.
Use the clock framework to program DPLL5, DPLL5_M2_CLK.
---
drivers/usb/host/ehci-omap.c | 57 +++---
1 files changed, 36 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap
.
Unfortunately, there is no hardware here for me to test these on, so
these patches have only been compile-tested. Note also that patch 2
should be implemented differently before any final merge; it is written
this way for testing purposes only.
- Paul
---
Paul Walmsley (3):
OMAP3 clock: Add debugging
For testing only, not for merging.
Add some debugging in omap3_noncore_dpll_enable() to try to figure out what
is wrong with ehci-omap.c.
---
arch/arm/mach-omap2/clock34xx.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach
Hello Thomas,
On Sun, 7 Dec 2008, Russell King - ARM Linux wrote:
> On Sun, Dec 07, 2008 at 08:55:54AM -0600, Woodruff, Richard wrote:
> > Yes, NOHZ is _poor_ today in respect to needless reprogramming. Code can
> > be improved. I have sent Thomas a patch for the same which is in the MM
> > tree
On Fri, 12 Dec 2008, Pandita, Vikram wrote:
> Can we have these clocks hidden from the driver.
> USB-Host understands only :
> 2 fclocks
> 1 iclock
>
> The DPLL5 is outside the USBHOST module in the DPLL5 part.
> Ideally, the clock node for say USBHOST-iclock should internally enable all
> the p
Hello Grazvydas,
On Fri, 12 Dec 2008, Grazvydas Ignotas wrote:
> On Thu, Dec 11, 2008 at 11:07 PM, Paul Walmsley wrote:
> > Gravyzdas, can you send us a commit ID that results in successful device
> > enumeration (after reverting
> > http://marc.info/?l=linux-omap&
Hello,
For anyone interested, here are some worst case measurements for CORE DVFS
transition times with patches 1-16.
The test board was a 3430SDP ES2.0 GP. Tests were run both with and
without changing the VDD2 voltage; and at two different MPU frequencies.
No voltage change:
MPU @ 381MHz:
inen
Acked-by: Paul Walmsley
- Paul
--
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
Hello Vikram,
On Fri, 12 Dec 2008, Grazvydas Ignotas wrote:
> On Fri, Dec 12, 2008 at 1:09 AM, Paul Walmsley wrote:
> > On Fri, 12 Dec 2008, Grazvydas Ignotas wrote:
>
> >> I'm also getting suspend/resume related problems if I plug a hub
> >> without any de
Hello Vikram,
On Sat, 13 Dec 2008, Pandita, Vikram wrote:
> >From: Paul Walmsley [mailto:p...@pwsan.com]
> >
> >Were you able to get USB remote wakeup or auto-suspend working on
> >ehci-omap.c with the 3430SDP?
>
> For remote-wakeup:
> There was a long disc
On Mon, 15 Dec 2008, Tony Lindgren wrote:
> * Tero Kristo [081211 07:59]:
> > From: Paul Walmsley
> >
> > Add a Non-cacheable Normal ARM executable memory type,
> > MT_MEMORY_NONCACHED. This is needed for the OMAP3 SDRAM clock change
> > code, which must
301 - 400 of 4899 matches
Mail list logo
