> 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: 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
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: 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: 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
> 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: 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: 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: 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
> 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
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: 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
> 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 O
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? I
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Monday, May 18, 2009 4:11 PM
> On Mon, May 18, 2009 at 03:47:31PM -0500, Woodruff, Richard wrote:
> > The code flow is:
> > - Wakeup event
> > - ARM reboots and uses SOC mask
> 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 r
> 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 workar
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Monday, May 18, 2009 12:09 PM
> To: Russell King - ARM Linux; Woodruff, Richard
> > There is a function which re-initializes the abort mode registers already -
> > cpu_init(). Please use that if possibl
> > 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 aro
> 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 res
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Thursday, May 14, 2009 12:10 PM
> To: Kalle Jokiniemi
> Kalle Jokiniemi writes:
>
> > The hardware SAVEANDRESTORE mechanism seems to leave
> > USB HOST power domain permanently into active state
> > after one transition from off t
> > Ok so -fno-optimize-sibling-calls is busted in older compiler.
>
> I am not sure that -fno-optimize-sibling-calls is busted as it appears that
> with this option it worked with the old compiler.
I wrote poorly. The optimize-sibling-calls optimization probably is busted for
this compiler. By
Hi Jon,
> From: Hunter, Jon
> Sent: Wednesday, May 13, 2009 10:48 AM
> KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
Ok so -fno-optimize-sibling-calls is busted in older compiler.
I wonder if there are other reasons for the exclusion of this optimization in
kernel code
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Tuesday, May 12, 2009 6:33 PM
> To: Hunter, Jon
> There was a thread a few weeks back where various folks had noticed
> this as well and we discovered using CodeSourcery 2008q3
> 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: 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 transi
> 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 regis
> 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 2(CLOCK_EVT_MODE_
>
> > > 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
> >
> -Original Message-
> From: Pandita, Vikram
> Sent: Tuesday, April 14, 2009 3:08 PM
> To: Menon, Nishanth; Woodruff, Richard; Jarkko Nikula
> Cc: linux-omap
> Subject: RE: 2.6.29 and SDP3430
> I am also seeing a hang at following bootup time:
>
> console [ttyS
> > 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..
> 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
1 - 100 of 268 matches
Mail list logo
