> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: Tuesday, October 13, 2015 5:01 AM
> So please help me to get this straight:
>
> Errata I688 only affects OMAP4 which is consequently the only user of
> omap_interconnect_sync() in it's WFI enter sequence, which in turn is
> the only
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Tuesday, October 13, 2015 7:24 AM
> If you implement drivers using nothing but writel() and readl(), then your
> performance _will_ suck, but that's entirely the driver's fault.
Your above analysis seems correct.
Perhaps
Hello Robert,
> From: Robert Schwebel [mailto:r.schwe...@pengutronix.de]
> Sent: Tuesday, September 29, 2015 12:50 PM
> > -1-
> > Barrier side effects of the patch may be beneficial for other reasons. But
> AM335x should be immune from this particular issue.
>
> Is this a matter of fact, or
> From: Menon, Nishanth
> Sent: Friday, September 25, 2015 9:44 AM
> > If I688 is not needed on am335x, then it seems there are still some
> > mysteries remaining with this erratum to unravel. Something like
> > difference in the L3 implementation. Maybe somebody from TI can
> > investigate which
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Friday, September 11, 2015 9:03 AM
> To: Grazvydas Ignotas
> However, even the idea that it's ARMv7 or later is wrong. According to
> the ARM ARM, the IT
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Friday, September 11, 2015 12:49 PM
> Frankly, Richard, you're getting on my nerves in this thread - you seem to
> know all about this problem, yet you never reported the problem upstream,
> so people are effectively having
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Russell King - ARM Linux
> > There are 2 workarounds that I know which make the problem go
> > away (one is enough):
> > - recompile Xorg with -marm (I'm using Debian armhf so it's
> >
From: linux-arm-kernel [mailto:linux-arm-kernel-
boun...@lists.infradead.org] On Behalf Of Russell King
Sent: Wednesday, July 15, 2015 12:47 PM
This reverts commit 606da4826b89b044b51e3a84958b802204cfe4c7.
We actually need this code for proper behaviour of OMAP4, and it needs
fixing a
From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
boun...@lists.linaro.org] On Behalf Of wireless
Since Linaro is flapping loudly about Grub2, I should think that support for
the
modern file systems on the 64 Bit arm offerings would abound, such as ZFS,
CEPH, GlusterFS, etc
...@denx.de;
nota...@gmail.com; luca.ceres...@comelit.it; Woodruff, Richard;
we...@corscience.de; peter.bar...@logicpd.com; frede...@kriewitz.eu;
tom@windriver.com; Menon, Nishanth; srin...@mistralsolutions.com; Hiremath,
Vaibhav; Gupta, Pekon
Subject: [PATCH 1/1] am33xx: add
Hi Tony,
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, May 25, 2012 2:53 AM
Thanks for quick input. Apologies on slow ack of it.
Before we had these frameworks in place it was often hard to debug when
something
did not work for some omaps. Things would just not work or would
Hi Tony,
I am hoping to solicit an opinion from you for OMAP frameworks in general.
In some recent review there was some debate about how it was good practice to
form parameters in a way which didn't get misused. Nishanth was having some
experience where end users doing custom ports made some
The only thing the higher-level layers might potentially need to do
is to enable/disable AVS around transitions (e.g. when changing OPP,
AVS is disabled before changing OPP and only re-enabled when the new
nominal voltage has been acheived.)
Getting clean baseline in place is
From: Hilman, Kevin
Sent: Tuesday, May 08, 2012 5:17 PM
A basic OMAP AVS driver has been in mainline for a long time, yet we
have not seen support submitted for all of these features.
1.5/3.5 is a feature.
ABB is requirement for a production useable driver. Higher speed rated OMAP4
and all
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Grazvydas Ignotas
Sent: Tuesday, April 10, 2012 7:30 PM
What I think is going on here is that omap_sram_idle() is taking too
much time because it's overhead is too large. I've added a counter
From: NeilBrown [mailto:ne...@suse.de]
Sent: Friday, February 03, 2012 8:31 PM
So... if flow control is available, then when we idle the uart we should
set snip ...
Yes I think you can improve situation with such tricks.
Unfortunately there are a few types of low-power idle wakeups which
From: NeilBrown [mailto:ne...@suse.de]
Sent: Monday, February 06, 2012 5:58 PM
To: Woodruff, Richard
Apologies for mangled mails... I am years over due ditching current method.
I don't think it is really OK to drop chars on the UART-to-Debug console.
However it is OK to drop the BAUD rate
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
Sent: Saturday, February 04, 2012 10:40 AM
It is entirely unacceptable to drop characters on a serial port through
the use of PM. Many serial protocols just will not cope
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Sunday, February 05, 2012 10:03 AM
To: Woodruff, Richard
On Sun, Feb 05, 2012 at 03:37:21PM +, Woodruff, Richard wrote:
[x] What is acceptable depends is not black and white. Is there some
QOS mapping which can
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of NeilBrown
Not sure if it's the same problem but with 3530 on 3.2 with
sleep_timeout set, I usually get first char dropped (as expected) but
sometimes I get corrupted char instead too. Corrupt
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, February 03, 2012 7:00 PM
One irritation was some internal interrupt sources were not linked to
low power wakeup events. If you were in interrupt mode and got
characters below watermark you could sleep before interrupt status
From: Mans Rullgard [mailto:mans.rullg...@linaro.org]
Sent: Sunday, November 27, 2011 6:26 PM
Hi,
By the way, do you know whether it is safe to use SCU Speculative
linefills with Cortex-A9 r2pX and PL310 r3pX?
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0407f/BABEBFBH.html
From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
boun...@lists.linaro.org] On Behalf Of Mans Rullgard
Do you have an erratum number for this?
This was very recent BUG and not yet made it to the public errata
numbers. Most likely next PL310 errata update should have
this
From: Shilimkar, Santosh
Sent: Thursday, September 15, 2011 7:02 AM
You missed my point in the description. Clockdomain inactive
doesn't depend on idle or WFI execution. Under HW supervison
CPU clock domain can get into inactive when CPU is stalled and
waiting for a read response from
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
kernel-boun...@lists.infradead.org] On Behalf Of Shilimkar, Santosh
With fixed IRQ migration and forcing CPU0 into an infinite WFI loop,
I can offline CPU0 and still have a running system.
The secure software runs
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
kernel-boun...@lists.infradead.org] On Behalf Of Russell King - ARM Linux
On Wed, Jul 20, 2011 at 04:32:25PM -0700, Mike Turquette wrote:
A quick poll of the ARM platforms that implement CPU Hotplug support
shows that
From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
boun...@lists.linaro.org] On Behalf Of Christian Robottom Reis
Sent: Wednesday, June 22, 2011 8:30 PM
This suggests to me that a simple drop-in of libjpeg-turbo might be
actually easy to do, and that there is probably a
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, February 23, 2011 4:50 PM
Anybody from TI looking into these?
I'll poke some folks and check. I've not booted my LDP for a while.
As an older 3430 dev board its lost its shine compared to 3630 and 4430 dev
boards.
Regards,
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, January 17, 2011 11:35 AM
This happened for a few days both with 2.6.37 and current mainline
kernel. After I started debugging it went away with no changes to
anything.. So can't debug any further at this point unfortunately.
Odd.
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, January 14, 2011 6:03 PM
I've been seeing this on my omap4 panda. While debugging it, I left
u-boot console only running for a few minutes to see if that stays up.
It did.. And after doing that somehow now my panda boots all the
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Saturday, January 15, 2011 5:38 PM
Why does OMAP initialize its clock sources soo late, outside of
the timer initialization? This means you have no counter in place
(except for the jiffies counter) during early boot.
Is
Per blog request http://blog.fenrus.org/?p=80:
Try it, play with it and let me know what you think of it does it
work or does it crash?
I just gave build a quick try on a Fedora13 system.
-1- The build environment stumbled on NL2FOUND test. The naming convention of
libnl-x is not
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Gopinath, Thara
Sent: Friday, December 31, 2010 2:02 AM
Is this true for OMAP2 as well?
OMAP2 used VSEL for direct and VMODE for voltage control not SR path methods. I
don't recall OMAP2 ever
From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
boun...@lists.linaro.org] On Behalf Of Peter Maydell
One of the Valgrind subtools is Cachegrind; this is a cache
profiler. (It simulates the I1, D1 and L2 caches so it can
pinpoint the sources of cache misses in application code.)
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Wednesday, September 15, 2010 2:15 PM
This patch fixes this problem by ensuring the branch prediction logic is
disabled while changing the L3 clock frequency. The branch
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Thursday, September 16, 2010 3:50 PM
Sounds fair. But it might be worth checking that you guys have a system
in place for collecting omap specific fixes and promptly merging
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Tuesday, June 08, 2010 5:05 AM
Sorry for the delay, here's some more info on this issue. So it looks
like starting with 3630 there are dedicated pull-up for all the I2C buses.
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Greg KH
Sent: Thursday, May 13, 2010 4:47 PM
Also note that such a driver, without wakelocks, would never get tested,
and so, things start quickly diverging.
Do wakelock enabled drivers require a
Hi Alex,
From: virtu...@slind.org [mailto:virtu...@slind.org]
Sent: Saturday, May 01, 2010 12:38 PM
Do you have a web viewable git tree where your full patch is applied? Or could
you send me on the side files?
Main bit I was looking to check was that you have bug fix which came late in my
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
I'm a little puzzled on this one. My understanding is that the IO pad
is only armed when CORE is in RET or OFF.
For ES3 and before the io ring wake was 'armed' when ever core went to
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Tuesday, January 05, 2010 11:54 AM
Also, what's the Cortex version on your v7? It's rev r2p3 on
omap3430.
Just a quick note - I think it is r1p3 on OMAP34xx ES3.1 and
From: ext-ari.kau...@nokia.com [mailto:ext-ari.kau...@nokia.com]
Sent: Saturday, October 31, 2009 4:40 AM
@@ -60,6 +60,9 @@ struct dpll_data {
void __iomem*idlest_reg;
u32 autoidle_mask;
u32 freqsel_mask;
+ u32
Hi Paul,
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, October 28, 2009 9:39 PM
+static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16 m,
u8 n)
+{
+ unsigned long fint, clkinp, sd; /* watch out for overflow */
+ int mod1, mod2;
+
+ n++; /*
Hi Beonit,
From: Cousson, Benoit
Sent: Thursday, October 22, 2009 3:59 AM
To: Woodruff, Richard; Paul Walmsley; Nayak, Rajendra
It is not guaranteed safe to write actim registers on the fly to an active
part. It is safe to do RFR as it is buffered and sent out at a safe time.
I think
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Thursday, October 22, 2009 5:24 AM
IVA2 controls its target power state individually, thus suspend should not
touch IVA2. Without this patch DSP suspend always fails.
We
From: Aguirre Rodriguez, Sergio Alberto
Sent: Tuesday, October 20, 2009 9:16 AM
+ * lookup_dco_sddiv -j-type DPLL4 compensation variables
Put a space before the j-type, and add better description.
Doesn't clarify what it really does IMHO:
Something like:
* lookup_dco_sddiv - Set j-type
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Tuesday, October 20, 2009 8:21 PM
This patch removes the SDRC AC timings changes done during core dvfs.
Updating AC timing CTRL values for SDRC during DVFS is seen to be a
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Monday, October 19, 2009 9:52 AM
To: Woodruff, Richard
Do you have any idea about MMCHS_HCTL.IBG?
Not off the top of my head.
I was working with someone who hit issues so I did a quick spec read and came
up with previous list
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of tero.kri...@nokia.com
Sent: Monday, October 19, 2009 5:19 AM
Is there errata number available for this issue by the way? I could attach
this to the patch.
No. I expect in the next few weeks it
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Andrejs Cainikovs
Sent: Monday, October 19, 2009 12:33 PM
I've googled that OMAP HS are checking some kind of signature (applications
should be signed with the special tool (OST Tools)) so the
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Pandita, Vikram
Sent: Monday, October 19, 2009 4:58 PM
diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-
omap/include/mach/cpu.h
index 7cb0556..05a0a33 100644
---
From: John Rigby [mailto:jcri...@gmail.com]
Sent: Monday, October 19, 2009 8:13 PM
It is not perfect yet, I am still polling in sdio_irq.c because
sometimes the card irq does get dropped. I suspect that is why the
davinci driver had extra checks and calls in various places.
Maybe.
Do
From: John Rigby [mailto:jcri...@gmail.com]
Sent: Monday, October 19, 2009 8:13 PM
It is not perfect yet, I am still polling in sdio_irq.c because
sometimes the card irq does get dropped. I suspect that is why the
davinci driver had extra checks and calls in various places.
Maybe.
Do
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tero Kristo
Sent: Friday, October 16, 2009 5:49 AM
OMAP interrupt controller goes to unknown state when there is right
combination of l3,l4 sleep/wake-up transitions, l4 autoidle in
interrupt
From: Ghongdemath, Girish
Sent: Friday, October 16, 2009 12:48 PM
On one of the custom board the power measured didn't show any major impact,
with just one time disabling of INTC-AUTOIDL. However,
optimizing this WA looks good though. I did give it a try,
Disabling/enabling INTC autoidle
/* I2C WE wakeup enable register */
-#define OMAP_I2C_WE_XDR_WE (1 14) /* TX drain wakup */
+#define OMAP_I2C_WE_XDR_WE (1 14) /* TX drain wakeup */
#define OMAP_I2C_WE_RDR_WE (1 13) /* RX drain wakeup */
+#define OMAP_I2C_WE_ROVR_WE (1 11)
/* I2C WE wakeup enable register */
-#define OMAP_I2C_WE_XDR_WE (1 14) /* TX drain wakup */
+#define OMAP_I2C_WE_XDR_WE (1 14) /* TX drain wakeup */
#define OMAP_I2C_WE_RDR_WE (1 13) /* RX drain wakeup */
+#define OMAP_I2C_WE_ROVR_WE (1 11)
There is no newer u-boot from TI available. There is a SDK 02.01.03.11
but it contains the same uboot 2008.10 with the only addition of the second
generation of EVM boards with another network chip.
So I checked the uboot from git, but this doesn't support Microns NAND Flash
anymore. It is
From: e...@gmx.de [mailto:e...@gmx.de]
Sent: Wednesday, October 14, 2009 9:49 AM
To: Woodruff, Richard; linux-omap@vger.kernel.org; Premi, Sanjeev
Subject: Re: RE: RE: Memory performance / Cache problem
Mem clock is both times 166MHz. I don't know whether are differences in cycle
access
From: e...@gmx.de [mailto:e...@gmx.de]
Sent: Wednesday, October 14, 2009 12:23 PM
To: Woodruff, Richard; Premi, Sanjeev; linux-omap@vger.kernel.org
Subject: Re: RE: RE: RE: Memory performance / Cache problem
Yes aligned buffers can make a difference. But probably more so for small
From: Siarhei Siamashka [mailto:siarhei.siamas...@nokia.com]
Sent: Wednesday, October 14, 2009 12:37 PM
To: ext e...@gmx.de
What you see is just a (fake) performance boost because you have a single
physical page shared between all the virtual pages in the source buffer. So
you get no cache
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Wednesday, October 14, 2009 11:12 AM
I think we should as well change the naming and use the less confusing
naming we are using on OMAP3630/4430.
OPPs are now named using
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kalle Jokiniemi
Sent: Friday, October 02, 2009 5:59 AM
Yes, this is a good idea in theory, but the reality of wake-up latencies
kind-a kill this one. Wake-up from even C1 (MPU INA, CORE ON) takes
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hunter, Jon
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!
No bother with W, its part of
Hi Paul,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Tuesday, August 18, 2009 7:36 AM
To: Russell King - ARM Linux
I'm afraid to say that I think you've left it far too late to send this.
I
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Tuesday, August 18, 2009 6:27 PM
To: Woodruff, Richard
The series cannot conflict with Rajendra's patches 1-3, since there are no
files in common between the two series. As for patches 4-6, there are
comments pending:
OK, there are recent
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Siarhei Siamashka
Sent: Saturday, August 15, 2009 3:04 PM
On Saturday 15 August 2009, Frantisek Dufka wrote:
Gerald Coley wrote:
You need to enable Smart Reflex on VDD2 in the Kernel. I can't
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
The device no longer hits retention if element DMA
mode is taken for at least the duration of the
serial console timeout. Force element DMA mode to
shut down through smartidle.
Used to be you needed to build with CONFIG_ARCH_DISCONTIGMEM_ENABLE did you do
this?
Regards,
Richard W.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Syed Mohammed, Khasim
Sent: Friday, August 07, 2009 3:17 PM
To:
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Pandita, Vikram
Sent: Friday, July 17, 2009 7:33 PM
USBHOST module has 2 fclocks (for HOST1 and HOST2), only one iclock
and only a single bit in the WKST register to indicate a wakeup event.
So point is... for USB having this WKST status bit set and NOT having the F-
Clk enabled points to an issue in the OFF mode transition code in the USB
driver.
Or if this is on 1st boot, then issue can be init code needing to clean up
whatever damage the boot loader may have done. Prcm_init
Hi,
If there are any omap people at linux symposium this year feel free to drop me
a note. I've ran into a few OMAP3 users already.
Regards,
Richard W.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On
Behalf Of Tom Rix
Sent: Monday, July 06, 2009 11:48 AM
Since there is only one version of flushing the dcache for
arm_cortex8, rename v7_flush_dcache_all to the the generic
name flush_dcache. Because the function
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, July 01, 2009 9:19 AM
David, did you see stability problems when using this patch on top of
linux-omap PM branch? Or did you see problems on some internal tree?
Issue was on one internal tree. Tests need to be
Hi Paul,
On Tue, 23 Jun 2009, Woodruff, Richard wrote:
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Tuesday, June 23, 2009 3:05 PM
Looks like the significant difference is the use of CLKCTRL = 0x2 (+
AUTOCOUNT). Maybe there is some SDRC bug related to CLKCTRL = 0x2
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Last week I posted some more omap io.h clean-up patches to
the linux-omap
list [1], and started looking at what it would take to
reclaim lost address
space on top of the
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Why is this sys-config reset done only for omap34xx()
This should be valid for any old 24xx() as well as new 44xx() omaps
You're correct. Good catch.
The force-idle fix that
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, June 19, 2009 11:21 AM
Thanks a lot for testing. It sounds like something specific to the
ES3.0 GP SDP.
Are DIP switches the same?
ROM code may touch UART in one case and not the other.
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, June 18, 2009 4:07 PM
Hi Paul,
On Wed, 17 Jun 2009, Woodruff, Richard wrote:
I've only seen the condition along side of very aggressive SDRC_POWER
settings.
Could you send over the SDRC_POWER settings that cause this problem
Mike,
From: Mike Chan [mailto:m...@android.com]
Sent: Thursday, June 18, 2009 1:42 PM
+/* Kick DLL state machine if lock not started */
+kick_dll:
+ ldr r4, sdrc_dlla_ctrl /* get dlla addr */
+ ldr r5, [r4]/* grab value */
+ mov r6, r5
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, June 18, 2009 10:03 AM
I've seen this issue on a couple custom boards. In these instances
I've not had access to boot loaders. I would expect this issue
would show up in the wild in some devices. It might be ok to
Hi,
From: Wang Sawsd-A24013 [mailto:cqw...@motorola.com]
Sent: Thursday, June 18, 2009 2:27 PM
+ str r6, [r4]/* restore old value */
Richard, I think here it should be: str r5, [r4], not r6.
I modifed this when I was verifying your patch.
You are correct that was
core vs per
Did you hook up your emulator and connect during awake time of uart timer? It
should really tell a lot.
Regards,
Richard W.
-Original Message-
From: Nayak, Rajendra
Sent: Wednesday, June 17, 2009 1:12 AM
To: Kevin Hilman; Woodruff, Richard
Cc: linux-omap@vger.kernel.org
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Friday, June 05, 2009 4:26 PM
On Thu, 28 May 2009, Rajendra Nayak wrote:
This patch implements locking using the semaphore in scratchpad
memory preventing any concurrent
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
Sent: Monday, June 01, 2009 2:45 AM
On Sun, May 31, 2009 at 07:24:19PM -0500, Woodruff, Richard wrote:
6. do ___NOT___ (underscored in triplicate and 500ft high letters
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
Sent: Monday, June 01, 2009 2:45 AM
That's something that TI may know, but it's almost impossible for developers
to know because:
BTW, yes, the forest of TRMs for OMAP3
6. do ___NOT___ (underscored in triplicate and 500ft high letters) enable
ARM errata 460075 - it solidly prevents the kernel booting on LDP.
(it's taken many hours to debug that.)
This is an r2p0 errata only. It's not in earlier versions or in later cores.
Today there are only r1pX
Kevin,
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
echo 0 /sys/power/clocks_off_while_idle
Kevin Hilman (2):
For PM branch are you keeping any kind of running readme file for inclusion in
Documentation directory? It
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Niilo Minkkinen
Sent: Monday, May 18, 2009 9:54 AM
Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG
register prevents the device from going into retention.
This is a workaround
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Monday, May 18, 2009 3:25 PM
The call to the enter method essentially calls the core specific suspend
function (eg, pxa25x_cpu_suspend()), which is an assembly function which
ultimately ends up powering down the core
couple errata impacting different chip revs.
Today in the older TI reference code this condition of a stuck on
power domain does not happen. However, we are using a software
supervised method to disable the power domain. May be this code has a
bug or the hardware does around auto
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, May 14, 2009 12:10 PM
To: Kalle Jokiniemi
Kalle Jokiniemi kalle.jokini...@digia.com writes:
The hardware SAVEANDRESTORE mechanism seems to leave
USB HOST power domain permanently into active state
after one
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 was added for some early Labrador boards that had speed
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
A brief update for anyone following along on the list:
Aaro sent me a test-case. It seems that the receive overruns only affect
PM kernels. They are caused by the MPU going to
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, April 23, 2009 3:53 AM
To: Woodruff, Richard
4. Current PM code didn't enable the maximum clock (i.e. CPU: 600Mhz)
according to the comment as below:
/* Avoid registering the 120% Overdrive with CPUFreq */
prcm
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kim Kyuwon
Sent: Thursday, April 23, 2009 12:00 AM
3. OP(Operating Point) transition time is set to 10seconds in
cpu-omap.c as follows:
The default sampling rate of CPUFreq is set to
From: Shilimkar, Santosh
Sent: Monday, April 20, 2009 11:39 PM
Thanks Richard for root casing the issue.
Yes I also did observed this. Second time when framework calls
omap2_gp_timer_set_mode set the periodic mode, R0 contains 0
(CLOCK_EVT_MODE_UNUSED) instead of
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Jarkko Nikula
Sent: Thursday, April 09, 2009 2:04 AM
just messing around with tony's master branch on SDP3430, just did a
defconfig and a build with 2007q3-51 codesourcery compiler, I see it
I wonder if the timer stopped ticking. If you connect with emulator take
a look at GPT1 registers and see if time base is moving.
Another quick test is to shut off tickles, nohz=off.
nohz=off did not work with either 2007q3 or 2008q3.. have'nt looked at the GPT
regs though..
Hmm,
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Roger Quadros
Sent: Tuesday, April 07, 2009 6:11 AM
modprobe omap_wdt fails in omap PM branch. below is the trace log.
any idea why?
i wonder weather fails in master too.
Looks like it. I
1 - 100 of 235 matches
Mail list logo
