> 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
> 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 user
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 just
> 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: 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 t
> 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 instruction
> 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
> 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, et
> From: Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
> Sent: Wednesday, October 02, 2013 5:59 AM
> To: Balbi, Felipe
> Cc: Strashko, Grygorii; Woodruff, Richard; linux-omap@vger.kernel.org; Taras
> Kondratiuk
> Subject: [RFC PATCH] i2c: omap: Clear ARDY bit twice
...@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 w
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 h
> 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
> > >> 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 cl
> 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: 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
> 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 ...
Yes I think you can improve situation with such tricks.
Unfortunately there are a few types of low-power idle wakeups which mu
> 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 +0000, Woodruff, Richard wrote:
> > [x] What is acceptable depends is not black and white. Is there some
>
> 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
> 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 stat
> 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. Co
> 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/BA
> 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 h
> 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 r
> 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
> 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
> 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 signi
Fred,
Do the kernel have and enable this code:
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=9069ca7aec1750b2e6362d7f4ffd44c4ed1f85e5
It may provide information on which entity was bugging the system.
You log shows failure from:
[1.947326] Unhandled fault: imprec
> 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,
R
> 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.
> 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.
>
> 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 th
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 eve
> From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> Sent: Sunday, December 12, 2010 3:02 PM
> In case you're collecting things to clean up for the next issue,
> here's
> another :-) The Rev M OMAP35x TRM says on page 1139:
>
> "In both prefetch and write-posting modes, the engine respective
The underlying functional spec which TRM started from gives this description:
"In MPU filling mode, the FIFO status can be monitored through the FIFOPointer
or through the FIFOThresholdStatus bits in the GPMC_PREFETCH_STATUS register.
FIFOPointer indicates the current number of available free b
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Dave Martin
> Sent: Tuesday, November 30, 2010 3:41 AM
> > * VFP uses the same register set. Does a floating point
> instruction
> > also turn the NEON coprocessor on?
>
> Yes-- these are one
> 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 co
> 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 mergin
> 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 branc
> 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 bus
> 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 requi
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
> 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 a
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;
> > +
> > +
> 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;
>
> 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.
>
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
> 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 b
> 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 -
> 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.
D
> 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.
D
> 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
> --- a/arch/
> 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 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
> 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 p
> 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 p
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Dirk Behme
> Sent: Sunday, October 18, 2009 11:45 AM
> > It would be funny if the TRM was wrong and the CIRQ bit is really
> > cleared by writing 1 to it. I'll try that.
A while back I hunted down
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Dirk Behme
> Sent: Sunday, October 18, 2009 11:45 AM
> > It would be funny if the TRM was wrong and the CIRQ bit is really
> > cleared by writing 1 to it. I'll try that.
A while back I hunted down
> 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 autoi
> 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
> interrup
> 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 name
> 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
> 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
> 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 a
> 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
> > >> /* 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_I
> > >> /* 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_I
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Sunday, October 11, 2009 5:30 PM
> > > + clk = clk_get(&pdev->dev, "emu_core_alwon_ck");
> > > + clk_enable(clk);
> > > +
> > > + clk = clk_get(&pd
> 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) t
> 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
> 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
> 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
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 thi
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 thi
> 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.
> 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 smartid
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
>
> 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
> 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.
>
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 funct
> 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 re-a
> 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
> > > spac
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).
> 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 "fi
Hi,
> 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 that
> causes this problem? Perhaps the problem is partially relate
> 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
> -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.
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 th
> 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 b
> From: Mike Chan [mailto:m...@android.com]
> Sent: Thursday, June 18, 2009 2:01 PM
> > >> Bootloader must configure proper settings for SDRC before starting
> > >> kernel from SDRAM. Furthermore, removed lines violated omap3430 and
> > >> omap2420 SDRC errata (see errata 1.150)
> > >
>
> This se
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
Hi Paul,
Hm, seems my mailing is out to lunch today... I'll be worse than normal in
protocol and top post.
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 b
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
>
> 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 concu
> 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 OMA
> 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 trip
1 - 100 of 305 matches
Mail list logo