RE: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x
> 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 of the SRAM scratch area to work around the erratum.
>
> The OMAP specific barrier implementation which should be used also on
> other SoCs does not need any SRAM scratch, but uses a part of DRAM to do
> the strongly ordered access.
>
> So it is safe to say that we only ever need to run the initcall
> allocating the SRAM scratch area on OMAP4.
There are 2 separate things here. One is the bus sync function and the other
is the errata which requires a bus sync near WFI to avoid an errata.
The rational for the bus sync is similar to why there is a writel() and a
writel_releaxed(). The bus sync has been used for a long time to ensure writes
have landed and are not stuck in some posting buffer on path.
A lot of historical drivers use a writel() where perhaps they could choose a
more granular construct. If drivers were audited maybe the bus sync could be
minimized on writel() path. Some writel's could be converted to use something
like an mmiowb () or some appropriate option. There is a lot of good
information in the
http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt
document. It seems every time I scan it some new aspect comes out.
For many product launches I was part of in mobile >24 hour robustness was not
achievable in non-trivial use cases without the serializing bus sync. For
CortexA9 ARM pushed in pl310sync and we added a bit to flush the interconnect
posting buffer. For a time in the mainline tree the bus sync's fell out as it
seemed to complicate single kernel booting. This has the effect of opening up
folks to sparse hang issues like found in i688. Re-closing this issue is the
point of this mail series.
Regards,
Richard W.
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
RE: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x
> 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 it is wrongheaded but part of the rationalization I used in the past was many of the ARM SW drivers evolved from low performance bus architectures which didn't punish drivers for forgetting to use a barrier or a read back. Many driver porters assumed what was there was good and built atop that. The result was a lot of hidden issues during production ramps. This is a mix of errata, missing read backs, wrong macro choice (and many valid macro usage instances). A couple SOCs I sampled in the past just used StronlgyOrdered and didn't buffer. This created a lot of 'it works for me not sure of your problem is' inputs. In that environment the question was realized performance vs. correctness. The promotion in heaviness for some of the valid macro usages tended to not be an issue as they are sparse. In cases they were not were in places where a DMA engine should have been in use anyway. The end result of promotion was the ability to work around many of the bad with one knob. I recall consulting Linux PowerPC folks (production users of weak memory model) in that time frame and they indicated they over synchronized also. I don't know what they do today. Today, maybe the code has been refactored/evolved enough that the older issues have been boiled away but this seems a bit optimistic given history. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x
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 an assumption? > Could you clarify this with the TI hardware folks? Which point are you asking for clarification on? -0- is factual. The conditions to trigger bridge bugs are specific and tied to cited component issues. These factors can lead to a HW clock gate before completion of bus protocol. The result is a misaligned of HW FIFO pointer inside of the retiming bridge. At hang it is possible to attach through JTAG-DAP and see writes going to the wrong address due to misalignment. The bridge component did fail in simulation and was fixed per hw-bug database as I mention. In my sampling of customers which ramped with aggressive power management ~10/10 I worked with hit this issue on 4430 on robustness tests. We did verify signatures at hang. There may be other errata which have a hang condition which users experience but their root cause is not the same as i688. Really any action which results in a bus protocol violation can end up in a hang. For instance a wrong sequencing of DSS pipeline/DMA control can cause the IP to crash. If the IP crashes while in the middle of talking with DDR a hang will result. There is no timeout on the interconnect so a watchdog will be needed to recover from such events. -1- is partially an assumption based on previous Linux macros and code structure. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x
> 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 SoCs this is really needed on? > + Richard who probably has the oldest history on the topic. > > I suspect strongly that the erratum was discovered during A9 OMAP4 days, > but never percolated to older SoC erratum documentation. The need of > barrier logic was clarified with SoC folks to confirm the behavior though. -0- After looking up i688 in data base and reviewing AM335x SOC I do NOT think i688 will exhibit for AM335x. - it appears not to be using pieces which have issues on path. I688 could impact SOCs which use a DMM and the interconnect infrastructure which supports it. I believe hang issues on path could be mapped to 3 sources: - asyncbrige used from MPUSS to Arteris NOC to DMM - Dual EMIF idle (ocp-connect/disconnect) policy on path - PL310 idle signal usage on path SOCs using similar chassis components of OMAP4430 time are impacted. Errata aspect in generic bridge map to Aegis, J5E, ... The hangs are brought out by enabling power management features which causes micro-idles on path which can trigger a lock up. Later SOCs pulled in fixes in one or all areas. Some SOCs are not using components. -1- Barrier side effects of the patch may be beneficial for other reasons. But AM335x should be immune from this particular issue. 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 info at http://vger.kernel.org/majordomo-info.html
RE: mysterious crashes on OMAP5 uevm
> 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 is present in ARMv6T2 as well, which > means it's ARMv6 too (which would have __LINUX_ARM_ARCH__ = 6). I recall seeing ARMv6T2 first implemented in the ARM1156 which is a v6 CPU with T2 option added. Cortex-R class was the ARMv7 successor to the 1156 CPU which also use T2. > Looking at the ARM ARM, these bits are "reserved" in previous non-T2 > architectures, have an undefined value at reset, and are probably zero > anyway. > > Merely changing __LINUX_ARM_ARCH__ >= 7 to >= 6 should fix the > problem, > and I doubt there's any ARMv6 non-T2 systems out there that would be > affected by clearing the IT state bits. Probably you already looked, but cpsr.it usage is not restricted to this one spot. Looking back at old notes I think both debug and signal handler code keyed on bit usage. I see from LXR kernel KVM code also uses in some capacity. The 1156/Cortex-R are typically MMU-less. They may (or not) have something else to consider when fixing. Regards, Richard W.
RE: mysterious crashes on OMAP5 uevm
> 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 to waste time re-doing the work that you've > already done. > > Nothing annoys me more than having people say "oh yes, I found that > problem and worked on it" and nothing coming of it (no report, no patch, no > nothing.) Yes, when I put out the hint (to help speed resolution) I expected there might be some negative interpretation. When I originally hit the issue, I did pass along information to folks who work in the area with expectation they would follow through. Probably it got lost. When I noticed this thread, it appeared like the CPSR.IT information didn't make it out, so I directly posted what I recalled. > As you have "old notes" you've already investigated this issue, and > presumably you came up with a patch. Where is it? I didn't generate a comprehensive one. I did a couple of hack versions but was unsure in some of the areas your analysis has cleared... for that issue I ended up advising a reversion of MULTI_V6 for that older kernel. 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 info at http://vger.kernel.org/majordomo-info.html
RE: mysterious crashes on OMAP5 uevm
> 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 > > thumb2 by default) > > - disable ARCH_MULTI_V6 in the kernel config This reminds me of a customer crash I saw quite a while ago relating to thumb2. I thought it was fixed but maybe not. In a couple spots the PSR_IT_MASK was not conditionally handled well in ARCH_MULTI_V6 flow. Some stack sanity check failed and a BUG() was triggered. Compiling the app for v6 or pulling MULTI from the kernel build solved the issue. Additionally it was not handled correctly in GDB. The old build of GDB didn't do MULTI and needed a hack to be useable on thumb2 code. Regards, Richard W.
RE: [PATCH 3/4] Revert ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688
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 different way other than just removing the code. Disabling code which is necessary in the hopes of persuing multiplatform kernels is a stupid approach. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk The series looks good. It improves code generation and fixes race issues which have been see production devices running Linux. Acked-by: Richard Woodruff r-woodru...@ti.com -- 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
RE: Test: OMAP5432-EVM support?
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 etc. Anyone clustering arm dev boards into something big? Sharing knowledge? None of the ARM boards you cite are 64 bit capable. - The A15 does have LPAE which allows for larger memory addressing but this is not general 64bit pointers in anyway. - LPAE allows multiple virtualized guests to each potentially get their own 32-bit/4GB and unique memory using stage 2 translation 64 bit ARMv8 paths are: - The first 64bit coming from ARM is A57/A53 which is not in production yet - There are some early 64-bit ARMv8 chips sampling from some server vendors - Apple released its 64bit A7 - Last I took a look there was ARMv8 simulators from ARM... probably the dev boards are around - ... other I've not noticed... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH 1/1] am33xx: add CONFIG_SYS_NAND_DEVICE_WIDTH to determine NAND device bus-width
Short comment. Apologies for top posting: The first incarnations of SPL and loader mainly cared about the boot flash device. OMAPs require a resistor strap to specify the width of the boot device. The values is latched for SW to read. As such always a run time check of width was sufficient for boot device. On dev board we would have many devices and use DIP switch to select which one was in use. A run time not compile time was way to support this. If information is dynamically available it is better to use this if focus is boot device management. Other tricks writing patterns and reading results is also possible but simplicity of compile vs. that is debatable. Regards, Richard W. -Original Message- From: Gupta, Pekon Sent: Wednesday, September 25, 2013 12:18 AM To: scottw...@freescale.com; Rini, Tom Cc: u-boot@lists.denx.de; Balbi, Felipe; Kipisz, Steven; sba...@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 CONFIG_SYS_NAND_DEVICE_WIDTH to determine NAND device bus-width NAND driver needs to know bus-width of the connected NAND device, in order to perform proper I/O and initialize itself. Currently there is no CONFIG option to provide this information to NAND driver. - SPL NAND driver does not have framework to parse ONFI parameter page. - NAND drivers which cannot self initialize !defined(CONFIG_SYS_NAND_SELF_INIT) do not have any information about device bus-width during board_nand_init(), So, any device-width specific configurations are not possible there. - There should be some mechanism to pass device bus-width information for non-ONFI compliant devices. @@ -772,10 +768,10 @@ int board_nand_init(struct nand_chip *nand) nand-priv = bch_priv; nand-cmd_ctrl = omap_nand_hwcontrol; nand-options |= NAND_NO_PADDING | NAND_CACHEPRG; - /* If we are 16 bit dev, our gpmc config tells us that */ - if ((readl(gpmc_cfg-cs[cs].config1) 0x3000) == 0x1000) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
RE: usage of sparse or other trick for improved type safety
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 stop working for some drivers with no ideas what was going on. So yeah, having these kind of frameworks in place has helped a lot to avoid breakage like you're describing above. Trees which had to hit the lowest power states for full customer boards all employed some form of abstraction of clock, power, voltage. The one today in mainline today is the most clean. Aspects around auto-generation are very good even if a bit big in size. Perhaps main grump I hear is the number of abstraction layers sometimes makes debugging difficult. It would be nice to find smart tricks for compile to prune away some. Still one can experience some of the mystery issues, as the PRCM connection to IP-device utilizes a protocol which the device side can mess up. If the device does not shut down its local function and associated clocks cleanly it will show 'stuck in transition' and this gates final global changes. In one of the closed implementation we would bug() drivers who did not shut down their internal clocks properly before allowing global clock release. Most of the issues seen in field are at drivers/peripheral-ip. For some external subsystems it might be possible to let the omap kernel manage powerdomains and other resource via remote proc interface, assuming these registers are ioremapped in the omap kernel side and not owned by the external subsystem. The messaging to do this would add some undesired latencies though, but maybe those would not be so critical for the external subsystems as they tend to be full on or completely off type accelerators. Humm. Maybe for some. Guess walking what is used and sorting might tell. The way some subsystems 'ideal' operation is described from designers implies tight control of timing and sequence for things like power state. A RPC doesn't feel like it fits with intent. However... practically speaking from 'full system view' RPC may fit sometimes. A subsystem exporting hooks to save 100uW using its optimal state set against other components running in 500mW range minimizes usefulness. The other alternative of course is to implement similar frameworks for the external subsystems. Some of this might be possible to implement as simple macros with some type checks if it's subsystem specific. For doing it for all omap devices, macros were soon found not to be enough as the various bits all over need to be linked together for managing various resources. Agree. I don't know insides of all subsystems. Though what I know or hear is kind of a mixed picture. OMAP has an ultra high level of integration. As such you might find something like DSP-Bios may provide a good hook but quick integration of a previously standalone single purpose piece does not have time to be readapted. The type checking question kind of grows out of this. Linux might today offer a clean run-time api which is place where high wall should be built with type check. But... the driver might not be able to function yet with the API alone given state of evolution of both ends. Review question was pointing re-hitting of bugs for what could be argued 'ideal' internal framework api. How to fix up what is in use by real drivers or to add/fix external api so its useful should be roadmap. 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 info at http://vger.kernel.org/majordomo-info.html
usage of sparse or other trick for improved type safety
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 hard to find mistakes. I was wondering if it is useful to create a standard or it's a waste of time. The knee-jerk reaction to comment is to consider annotations for driver users of api's, then inside the framework trust internals to do the right thing. Complexity divide between a driver and some frameworks might be similar to user-vs-kernel. I think example in this case was IVA and other external subsystems commonly got away using stale definitions when managing their own power domains. Example seemed a little pedantic but it is true that this has broken several times through migrations. At customer fan out it causes a lot of effort which could have been avoided. Just last week someone was trying to caste away an iomem annotation from external driver based on warning. For me warning was a good thing and forced discussion. I do recall you pushing what ARM and Linux tress did in this area back into OMAP years back. Question is if it's worth internalizing more for our ever growing frameworks. Thanks, 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
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 huge step but actual production interfaces will need to comprehend some OPP to AVS dependencies beyond on/off. AVS as used in many OMAP designs (mostly OMAP4430) do have some per OPP dependent details: - Multiple PMICs are in use. In some current designs the AVS step size is different per voltage range. At OPP change time you have to reconfigure several AVS parameters before enable. - ABB-ldo sequencing and parameters in tightly coupled with OPP and AVS enables. - Good power savings can be had in future 1.5/3.5 by adjusting nominal to calibrated-plus-margin voltage. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
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 OMAP5 added these to be useable. Yes this is effort. Point of mentioning is to raise awareness of need. Yet to be added feature has different meaning than functional gap. 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 info at http://vger.kernel.org/majordomo-info.html
RE: PM related performance degradation on OMAP3
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 there and it seems to be called ~530 times per megabyte (DMA operates in ~2K chunks so it makes sense), that's over 2000 calls per second. Some quick measurement code shows ~243us spent for setting up in omap_sram_idle() (before and after omap34xx_do_sram_idle()). 243uS is really a long time for C1. For some reason has grown a lot since last time I captured path in ETM. Your analysis correlates well to reports from a couple years back. N900 folks did report that the non-clock gated C1 was needed (as exists in code today). IIRC the NAND stack did have small-uS spins on NAND status or something which having higher clock stop penalty resulted in big performance dip. You needed like 10uS for C1 or bit hit. 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 info at http://vger.kernel.org/majordomo-info.html
RE: patch tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA added to tty tree
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 muddy the water when trying to understand TRMs. - The IOpad type wakes are the ones being discussed now. These are used in conjunction with isolation rings which stop external signals from propagating into chip and causing undefined things. This protection is used to enable OFF mode (but can be armed outside of from 34xx+ and beyond). The wakeup event here travels through pins to wakeup domain then to prcm which reactivates subdomains and signals can then reflow (if there are still valid). You get IOpad status which can map to function. - A shade of idle up is module idle wakes. Here if the isolation latch is not enabled you need to program omap-ocpip wake-function wrappers in uart itself. Here the wake signal comes through pads to uart-ip then it signals prcm to reflow signals. - A wakeup which no one seems to use above this is the 16x50 UART has some internal sleep/wake features. The generic linux driver might know these but they are rarely used. Outside of debug console, this loss has not been huge. Protocols like irda would retransmit their magic wake packets. You can move between DMA and interrupt modes with activity. So far there has been a work around per attached device. What about bluetooth? HCI/UART doesn't seem to have a lot of error handling. Maybe it has enough though. (I have bluetooth on UART1 ... of course we might not have the same problems on UART1 .. I haven't played with bluetooth much yet). I heard of solutions but don't recall as I personally didn't donate blood to get them working. I recall some activity timer + wake packets but would have to dig up old PPTs. 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 info at http://vger.kernel.org/majordomo-info.html
RE: patch tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA added to tty tree
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 to 57600 where we can wake up in time for to catch the first bit. So if you want power saving, drop the console buad rate. So I would suggest: - remove the autosuspend timeouts - allow runtime_pm to shutdown the device when it is not open, or when rate is 57600 or below, or when 'CREAD' is clear - keep runtime_pm active whenever there are bytes in the output queue or fifo Yes slower baud + use of flow control should help. OMAP4 is like 10x better than OMAP2 with OMAP3 in middle. The only case that wouldn't support is when a device will wake up the SOC by sending a non-break character which it is OK to receive corrupted. The tty would have to be in !CREAD for that to happen, and then there would be no way for the app to know that a non-break character was received. Would it be reasonable to treat any input while CREAD is clear as a break? Others would have to comment on this. I never took this step as I was ok with degradation on debug console. If ever I wanted better logs I tended to telnet/ssh in on a network port which was better at retry at higher level. 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 info at http://vger.kernel.org/majordomo-info.html
RE: patch tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA added to tty tree
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 with that kind of behaviour - yes, serial protocols may have retry built-in, but will they retry _before_ the port re-idles and the PLL shuts down? Can you be sure? What is acceptable depends on the hardware and applications stack ups being used. There are ways to work around issues along whole path in SW and HW. There is no single setup which makes all combinations work. Some old PC chassis may define 1 of many standards but they probably were not defined with very low power tradeoffs in mind. If the board designer hooks up all possible serial signals for uart/rs232/rs422/standard-xyz or just rx/tx, or adds some glue logic, or adds smart peripheral, or ..., there are will be constraints and ways to cope with issue being discussed. For most OMAP reference platforms the HW design links available UARTs with likely peripherals used in that timeframe. When it comes to making each UART work with PM some changes are usually needed per interface. Depending on the given stack up (to include bugs/limitations) some per interface tweak is always needed. It might be as you say you have to defeat PM on a port and only release after protocol handshaking with some modem firmware or it might be the debug UART expectation is lowered and allowed to work in a lossy mode so as not to destroy platform power for non-production port. [x] What is acceptable depends is not black and white. Is there some QOS mapping which can be set per channel which allows runtime PM to pick a best chose (which may allow for loss and frame issues)?. 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 info at http://vger.kernel.org/majordomo-info.html
RE: patch tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA added to tty tree
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 be set per channel which allows runtime PM to pick a best chose (which may allow for loss and frame issues)?. What you're asking is whether there's anything in the kernel which can predict when the next character is to arrive. No, this was not the comment's intent. But, the fact of the matter is that deriving the UART clocks from a PLL which takes a finite time to lock, and the PLL is shut down during runtime PM _is_ _going_ _to_ _cause_ _problems_. There is absolutely no getting away from that. Yes this is one of the issues to be worked around. Let's take your modem example. Modems today would typically be used with some IP based protocol, probably PPP based. Incoming traffic on IP is entirely unpredictable. You wouldn't know when the next character would be received. One solution to this is to transmit an 0xff character before your real data to ensure that your end is awake and properly synchronized... This approach as you say has issues. This is solved in different ways for modems. sleepMy observation is modem software which many talk over ppp over ip over serial of some sort (might be uart, might be usb), will send a command to the modem to go into a low power mode. Now you can cut clocks with out hurting modem and getting SOC power. wakeWhen some event happens at modem or processor (timer near beacon or other) the modem or apps processor can signal the other with some wake event (maybe over gpio) which then puts system in a state where it can receive data in trusted manner. The modem channel driver try's to inform kernel about entering/exiting modes to set expectation. So, go ahead with having PM drop random characters if you want, but don't expect anyone in their right mind to accept broken workarounds to the kernel serial driver to try to drop maybe 16 characters or more at a time on the floor when a framing error occurs just because the PM is broken. No character was dropped in modem example. On the UART-to-Debug console it may be ok to drop a character. Ether needs a coordination hook. Each stack needs some way to adjust expectations. Finding a way to isolate to a sub-layer of stack and not break everything is always the quest. And let's not forget the problem that current kernels have on OMAP34xx platforms. Literally minutes to get a dmesg out over a 115200 baud serial port, 16 characters at a time. I guess you're going to try to justify that as 'acceptable behaviour' from the system. Yes, of course it is. If you're dealing with a 1960s computer which processes that slowly. And I thought we were in 2012. This looks like a different issue. Years back with custom kernels with lots of hacks hack this was not the case. These days the job is harder to make it work more generally. Evolving for PM tradeoffs is painful in HW and SW. 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 info at http://vger.kernel.org/majordomo-info.html
RE: patch tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA added to tty tree
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 char seems to almost always happen if I set cpufreq to powersave, on performace it's almost always ok, so maybe it's some timing problem, I see that too - I'm glad someone else does :-) When you have aggressive PM working at the SOC level you many times lost a character on UART every since OMAP2. A strange but true statement is it is nice to see it losing a character on mainline as it as in indication that PM is likely working. If you just hook up simple RX and TX lines and not other flow control it is very likely especially with older OMAPs you can lose the 'wake' character on debug console. The UART operates on a derived clock from a 96MHz DPLL which was probably stopped. When the wakeup event hits the IO ring many internals may need to repower and its source DPLL needs to relock. This all can take a while and you can lose the start bit at high baud rate. If you use flow control you might be able to get ahead of it. As the silicon process has shrunk from 90nm (omap2) to 65nm (omap3) to 45nm (omap4) the DPLL relock times have dropped a lot. With certain DPLL parameters it could take hundreds of uS to relock in OMAP2. And there are more variables to latency stack up than just DPLL. Most of these have improved (gotten smaller) over time. Always the hack for debug console was activity timer along with denying idle while SW and HW TX FIFOs had characters in them. This made debug console useable. 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 showed up (as you had to wait several frame times before functional interrupt asserted) but there was no wake at anticipated frame timeout because lack of linking of internal event to wake event. Outside of debug console, this loss has not been huge. Protocols like irda would retransmit their magic wake packets. You can move between DMA and interrupt modes with activity. So far there has been a work around per attached device. If your screen blanks and you hit a char to wakeup, do you expect to see the character or do you throw it away? You can set some timeout or policy to deny lower c-states which can ensure a debug console doesn't have any issue. If your application is a phone it is not likely something you would do. Maybe your issue today is due to some other software bug... but at the end of the trail you still may have an issue unless your attached hardware accommodates. 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 info at http://vger.kernel.org/majordomo-info.html
RE: patch tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA added to tty tree
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 showed up (as you had to wait several frame times before functional interrupt asserted) but there was no wake at anticipated frame timeout because lack of linking of internal event to wake event. Indeed, it seems that we are just now working around these wakeup-related bugs. Kind of surprising that no errata showed up for them. There have been errata over time in this area. Several I hit were updated at 3630 time. UART did get IER2 but I don't recall all details for UART. Probably that is not being used. What's particularly remarkable is that it looks like the UARTs will idle-ack while their transmit FIFOs have data in them (!) Generally a module can ACK its ICLK if it is not used internally. The FCLK can push data out with out ICLK and is controlled separately always (omap4 changed encoding, to optional clock). This allows interconnect to idle during tx to save power. The trick is to ensure all module wakeup plumbing is enabled so a functional tx irq will flow. Audits last showed several drivers missing steps (omap specific). Some drivers seemed to rely on static dependencies or coincident neighbor activity to allow their functional interrupt to flow... to many interdependent custom details... and yes some errata. Anyway, even with all SOC specific wake bits you may lose the character with latency of restart. Point I was raising was external chip hook can not be neglected as its part of equation. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] OMAP4: cache fixes for 4460
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 As a quick and dirty test, it can be enabled in 'arch/arm/kernel/smp_scu.c' by just setting extra (1 3) bit in SCU Control Register from 'scu_enable' function. snip Be careful. That chip has PL310 r3p0 so it's affected by erratum 729806, Speculative reads from the Cortex-A9 MPCore processor can cause deadlock. For OMAP4's it should be OK as long as other necessary errata work arounds are activated in code today. However, As Mans points out other partner chips might have an issue. Your benchmark results are interesting. I did have a couple threads with an expert on this point and your result matches. Impact depends on data set size of use case and configured speed of pl310 logic. It was explained that when 1 processor requests shared data (all Linux-SMP memory is marked with S-bit), the SCU can signal a hint to PL310 to start a parallel L2-tag lookup while SCU-snoop-tag is checked (to see if coherency L1-cache-2-cache transfer needs to happen). In case of a snoop-cache-miss, you are now 2-3 cycles ahead of the game into the PL310 cache-tag lookup. If the data is in other processor you would have burned some power with needless lookup and perhaps (depending on resource load) delayed some valid request. Regard, Richard W. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 0/5] OMAP4: cache fixes for 4460
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 one documented. Do you have _any_ identifier for it? ARM expanded errata 752271 to cover DLF not working till r3p2 in errata version 13.1 (21 Nov 11), 4460 is r3p1-50rel0 and is impacted. Regards, Richard W. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
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 slow interconnect. My understanding is MPSS global clock domain can not gate unless each cpu is in wfi and other conditions are met. Other conditions are a wugen ack that there are no irqs and ocp-bridge logic giving its ok. What kind of local clock gating is there per cpu or sub-clock domains is not as clear. The mpu's pivot on individual wfi while other blocks in mpuss have other considerations. The spec is very clear about coherent programmation of wugen and gic. Like being discussed. Its examples are about how wugen used I've heard about are around transition in and out of standbys at wfi. Wugen will process all irqs before giving ack to sleep, it also has ability to fail sleep if new irqs come in before final idle. * It may be possible depending on clarifications to handle near wfi, but you might have to do it for -every- cpu's wfi unless you can coordinate who the last one is. Doing it as you go with gic would avoid redoing work over and over at the many wfi calls. This extra work costs in latency and power. Doing housekeeping along with gic seems better from a run time perspective. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: do not mark CPU 0 as hotpluggable
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 only on CPU0 and that's the biggest limitation. Other issues like hand-shake as you pointed out, power sequencing etc can be worked around. As you know well some of the secure APIs work on CPU1 and others do not. I notice in other thread Russell made assumption about CPU1 being able to use all because it could run some. This is not the case. I'll re-add because of the many power states omap4 adds atop of standard 3 arm states there exists a lot of states and not all state transitions are valid. This will increase complexity of practical usage. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: do not mark CPU 0 as hotpluggable
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 every platform treats CPU 0 as a special case that cannot be hotplugged. In fact every platform has identical code for platform_cpu_die which returns -EPERM in the case of CPU 0. Are you sure that's just not because everyone copied what Realview has been doing (highly likely)? I suspect that there's no reason that CPU0 can't be taken down, especially on those platforms which don't take the CPU fully offline but just put it into a WFI loop. Those which restart the CPUs through the boot loader probably detect CPU0 as the boot CPU, so they probably can't take CPU0 down. This was a hot topic a couple years back for hw folks... On 443x when you go to ARM-MPCore power states other than normal (dormant, powered-off) there are hardware and ti-trustzone-monitor constraints which dictate the CPU power state transition matrix (cpu1 can't make all calls cpu0 can and some hardware combinations were not validated). For MPU-domain (mpcore-cluster + l2cache ++) and its sub-domains (cpu0, cpu1, ...) there exists ability to set multiple states which wfi is a gate into (on, inactive, retention, partial-off, off). A big matrix of possible states results. Things were coded and system tested for only a subset of these. The ARM code did line up with these constraints. Maybe an offline to simple wfi loop is ok, but other lower states could not be entered from that state. Some folks were talking about relaxing cpu0/cpu1 constraints moving forward. Doing this could result in many more states-combinations to be validated at hardware level. Do you think Linux code would be simplified/enhanced such that it is worth the extra hardware validation effort? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: Android libjpeg
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 significant performance benefit to be achieved. One thing to keep in mind is that this code still supports armv6, so we'd probably want to preserve that. You have to be a little careful as ARM did drop some bad NEON errata in A9 which require care to work around. Some CPU versions are impacted while others are not, tanstaafl. Regards, Richard W. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: State of LDP3430 platform
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, 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 info at http://vger.kernel.org/majordomo-info.html
RE: State of LDP3430 platform
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. You might experiment with cold reset vs. warm reset for booting. Initial values of some blocks will be different. Reset tree is something not usually considered. The behavior depends on what level and when it is asserted. Software tends to act like all resets have same effect and this is not the case. I've seen folks burned in PM context several times at both OMAP and PMIC level. Also... something happen behind your back. You can program up the PMIC to take a softreset and issue a hardreset. 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 info at http://vger.kernel.org/majordomo-info.html
RE: State of LDP3430 platform
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 way and stays up. Weird. That is a bit weird. U-boot doesn't do much of anything but spin waiting for characters on serial. The watchdog normally isn't used. Thinking back I have experienced goofiness along these lines before. This had to do with some bad timer initial state assumptions. The timer's count values and states entering the kernel have caused a trip up. I had fixed some of these years back. Its possible some could have snuck back with all the recoding. Many times the simple have some unanticipated twist. The watchdog is something which the old kernel used to fall on also. There were a couple simple trip ups: -1- people forgot to turn clock on all together -2- next, it was touched before clock frame work was initialized -1+2- some code only 'wrote' to watchdog registers. When memory attribute is device, generally the imprecise abort is ignored by the arm. But some times weirdness slipped in around memory weak memory attribute mishandling. Sounds like a fun bug/puzzle which good ole Lauterbach would help in. 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 info at http://vger.kernel.org/majordomo-info.html
RE: State of LDP3430 platform
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 there a reason why OMAP uniquely does this? Not any good reason. I'm aware of historic porting issue and the missed/hidden need for early init for some time services. 1st attempts to do really early init (like 7 years back) were messed as not all kernel services used to be available when the time early time init functions happened. It was hidden because u-boot had already turned on the same clock the kernel level driver used. So there was no failure (until the kernel used something else). Recurring breaks fixes happened to out of trees as owners changed. The mainline never enabled driver till recently. 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 info at http://vger.kernel.org/majordomo-info.html
[Discuss] The first alpha release for PowerTOP 2.0
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 there. Might be distro naming. A quick hack allowed that to be bypassed. -2- Some include path issue perhaps do to hack around netlink.h. Again, hacked away. -3- It did build and run on old x86 after the above. Concepts and enhancements detailed in your blog look really nice. Thanks for efforts. Regards, Richard W. ___ Discuss mailing list Discuss@lesswatts.org http://lists.lesswatts.org/listinfo/discuss
RE: [PATCH v6 07/10] OMAP3: PM: Adding T2 enabling of smartreflex support
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 need to enable this as that path is not hooked up. I've not double checked details but that is recollection. This patch actually hangs the boot on 2430SDP. There were a lot of versions of 2430SDP boards PMIC-boards which created a variety of issues of someone is really watching the details. Issues which stopped booting as I recall in the past were: - Initial state of interrupts not good allowing boot to livelock - Old boards had poor power routing and min voltages needed to be higher. - General i2c service thread issues. I'd guess Thara has some random board with issues and Kevin's system is newer. Probably Kevin is seeing patch issue as SR doesn't seem to follow for OMAP2. 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 info at http://vger.kernel.org/majordomo-info.html
RE: userspace access to cache geometry information
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.) Part of this info is exported to user space through /proc/cpuinfo Catalin did post a patch long back to fix up decode for v7. I recall RMK not linking some aspect. The reasons are buried in mail archives. IIRC it had to do with expectations around that interface and the constant churn around he formatting that happened. There is enough info in cpuinfo you can guess, but you will be wrong due to errata modifications. Also there are a lot of cache options which are changeable. Things like if your using write-alloc or not will change results a lot. Is it possible on the tool to just have it take input from some config file? If you know your CPU it could fall back and use that information. Getting the cache information from the tool would be cool. If the kernel has some issues getting the info letting the user pick and having a default config would be next best. ... if you look at proc and see v7 and smp you can infer a lot of the configuration and pick a close default. Regards, Richard W. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] omap3: Prevent SDRC deadlock when L3 is changing frequency
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 prediction logic is disabled by clearing the Z-bit in the ARM AUX CTRL register. Small correction, Z bit is in CR register. AUX CTRL figures in with the ASA feature. Really nice changelog. I wish every patch had a description this good. Patch looks really good, too. Queued for 2.6.37. It is system specific if this change is required. It is probably safer to have it than not. If the AUX CTRL register has the ASA bit/feature active to allow speculative accesses to propagate past the L2 boundary the Z bit should be cleared as in the patch. However, if ASA bit is not activated then Z bit clearing should not be necessary as speculation will be squashed if there is no L2 hit (so no DDR request will be generated). It is not recommended to enable ASA bit as it is known to cause some issues on EMU/HS devices. It was also projected as loosing more than it gained across some benchmarks. Early boot loaders used to set the ASA. It was removed long back. Some kernels kept the value and opened up the lockup window. I don't recall the linux-omap open kernel having the issue. Some vendor ones did over time. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: Prevent SDRC deadlock when L3 is changing frequency
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 them upstream to the mainline tree. Many times there will be lag. In many cases the customer has written significant code. Until they publish this code or publicly post it for review its not something TI should not repost as is. I think many of the engineers do see the benefit of sharing. However, if they don't have a policy in place which allows them to post until after the production is released it won't happen early. Anymore, I like to advise a customer's team that it is ok to post patches for RFC even if they don't have time to follow up or it is against an 'old' kernel. Once this is done TI and others are free to make use of the info to better the common tree. The customer who found it will re-use the tree likely and get this plus other benefits. Its best to get this policy set at project start. Asking near launch may very well be denied. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 2/2]OMAP: Disable internal I2C pull-ups in OMAP3630
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. And the pull values are configurable with software. Even 3430 claimed to have this controllable in CONGROL.CONTROL_DEVCONF1[12,13,14] Last year I had read some of this for an omap34xx issue. A read of TRM + schematic might imply you have 4 possible resistors to watch out for on a typical I2C channel. 1 weak pull through standard padconf 2 stronger pull accessible in CONTROL block of SOC 3 pulls available on T2 (if your i2c target was twl5030) 4 possible pull on trace for board schematic Depending on the TRM/DM you look at guidance of value is given in terms of capacitive loading and speed of operation. A very strong pull might be good to overcome capacitive loading but it will burn more power per bit transmitted. I saw one customer stick with full speed and use a weaker pull just based on power savings. If you want to play around you can use pulls in parallel and attempt to make a stronger pull up. What you end up doing is really determined by what the signal looks like for that design. - Disable mux register pull-ups on 3630 and later - Allow setting the dedicated I2C pull-up values from board-*.c files for 3630 and later - Warn if the dedicated pull-up values are not configured on 3630 and later 3430 claims to have some dedicated ones. I have heard that seconded guessed. IIRC 2430 might even have had something. I don't think this is really so new for 36xx just no one used it. - Allow disabling the dedicated I2C pull-up values on 3630 and later in case external pull-up resistors are being used. The settings required are board specific and depend on speed in use. Having more than available is not necessary an error and might even be deliberate if someone was trying to be cleaver. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
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 wakelock aware user space to function properly? If the driver is added you want to make sure the benefit is there and testable for all userspaces. Early Android service managers did take/release userspace locks to ensure the handoff worked. Getting all these drivers is positive. Getting to some constraint mechanism is positive. It does need to exist end to end to make a difference at the battery. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] ETM/JTAG components states across OFF modes
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 original hack where a failed OFF mode needs to unlock the coresight registers at the fall through of WFI. I've finally got around to doing this. This is a rework of the previously posted [1] patch that implements ETM and JTAG context saving. There are two major changes since previous version: * coresight OS save/restore mechanism is used for saving the ETM context, so that it actually occupies ~54 words on omap3_arm_context instead of 128; Seems you found some nice optimization. I was thinking first patch was doing this in part. You read from a port address and it gives you internal registers as necessary. You written them back to port for restore. I came up with context size simply by inspecting # of times loop was necessary and looking at values written to save areas. I assume you would have done something similar to determine size. * a sysfs file is used to control if the ETM/JTAG context should be saved in OFF mode. Neat. This is much more friendly then a recompile. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] omap: pm34xx: Enable IO / IO-CHAIN wakeups for PER
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 idle. When core power state changed accounting was done for state. This scheme created a small time window where per wake events could be lost in handoff from gpio to io daisy chain when targeting chip off. In ES3.1 the EN_IO_CHAIN bit was added as a way to cover this hole. It allows enabling the wake up daisy chain in software prior to idling core. The trm does detail the exact steps. The 3.1 bug fix covered the transition window observed going to chip states but probably can cover here. I'm not sure about the patch as applied with studying. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags
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 below, and r1p7 on ES3.1.2. Not quite accurate for the 'below' but as they are non-production they are not so impacting. Current production CortexA8 chips for 3430: es3.2 : r1p7 es3.1 : r1p3 Earlier esX.Y used r0p0, r1p1, r1p2 Production candidate chips for 3630: es1.x : r3p2 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2 v2] OMAP3:clk - introduce DPLL4 jtype support
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 dco_sel_mask;
+ u32 sd_div_mask;
+ u8 jtype;
u32 idlest_mask;
u8 auto_recal_bit;
u8 recal_en_bit;
Are the dco_sel_mask and sd_div_mask needed in the struct or is the jtype flag
enough info?
Could you use OMAP3630_PERIPH_DPLL_DCO_SEL_MASK and
OMAP3630_PERIPH_DPLL_SD_DIV_MASK directly in omap3_noncore_dpll_program
instead of
dd-dco_sel_mask and sd_div_mask?
Could be done that way, seems a little better also to save structure space. To
make quick patch I just followed style/spirit of existing coding.
It will be a couple weeks before I'm near a 3630 again to test any change. I'm
ok if anyone is able to adjust.
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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2 v2] OMAP3:clk - introduce DPLL4 jtype support
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++; /* always n+1 below */
The N that's passed into lookup_dco_sddiv() is the real N -- that is, it's
the register bitfield plus one. That can be seen below in this line:
v |= (n - 1) __ffs(dd-div1_mask);
Given this, is the n++; above correct?
Probably not... Actually much of the original function path (setting dpll4) is
a bit suspect. Reprogramming of PER DPLL at kernel time would seem risky. The
service provided in this function maybe should only be available at early init
time. There is no notification in clock receiving drivers. For instance an
active UART would crash.
The rest of the code looks fine. (Of course, I can't review the
technical basis of the code since I don't have the 3630 docs yet, but I'm
fine with taking it in the meantime.)
I might change the 'u8 jtype;' field below into 'u8 flags;'; please let me
know if you foresee a problem with that.
Don't care. Jtype seemed description but flag |= jtype is just as descriptive
and can hold a few more.
Thanks for looking over.
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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: DVFS: No sdrc AC timing changes during core dvfs
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 that what Paul is suggesting is to change the ACTIM after ensuring that the DDR is in self-refresh. In that case it is perfectly valid; it is just tricky to ensure that all initiators are in mute before doing that. Yes that is true, however, ... That is not the way the code is setup and it’s a long way from that. Run time pause of drivers is a minefield. With out a broad notifier they best you would hope for is some opportunistic change time (against full system). You wouldn't have a guaranteed way to speed them up again where you need them most at high opp. Some minimal kernel not using dma and the like could do it but that is probably more misleading to put in the tree than something useful for most. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/17] PM: fix suspend control for IVA2
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 don't allow other device drivers to touch PRCM bits, so we should probably should remove all PRCM register accesses from the DSPBridge code, so all power control should go through the ARM. Is there a reason why the ARM code can't handle the DSP powerdomain? Sharing with DSP is something which probably could use some improvement. Today DSP self-manages its domain. Its (bios) micro-kernel makes decisions to optimize its domain. The ARM can't really micro-manage the DSP as he doesn't even want to know at the detail level what the DSP is up to at every instant. - During idle time cpuidle should just be checking dsp status to see if its current state gets in the way of a low c-state. - bridge does register with suspend frame work so he should do the right thing when in the system. * problem is when bridge isn't there what to do. This is especially after an unload of the bridge. What has been proposed in the past is like what Kevin inputted in related thread about having maintenance hand off. But for some reason it never quite to the top of the list. - bridge does request thought clock frame work clocks especially of those which are public peripherals. - bridge could request everything but it was not projected as power efficient waking up the big arm core for something the dsp could do itself and has all control over. This is especially true if you have dsp doing the rendering for something like mp3. it gets the wake ups and streaming and only every great while wakes the arm to give it a pile more data. Waking the arm every time it runs its equivalent of cpuidle was discourged. - main other sharing conflict was with irq routing between arm and bridge. Right now its kind of init mode setup. I guess this is ok for todays usage. .. so after context current code is not requesting through pm code purposefully. The hardware has been evolving from omap1,2,3,4 to make for more of a distributed model. After all the details/constraints are understood with silicon there is some time to re-evaluate if its paying back or not. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3:clk: introduce DPLL4 jtype support
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 DPLL4 compensation variables For 45nm it was necessary to use a different DPLL IP for DPLL4 (dpllj). The other DPLLs are same which was used in 65nm (dpllm). The register interface is slightly different. Code could have said is type A or B, but simple choice was to follow internal name convention. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: DVFS: No sdrc AC timing changes during core dvfs
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 risk, while the RFR CTRL value is safe to be updated. Signed-off-by: Rajendra Nayak rna...@ti.com just wanted to let you know, I haven't forgotten about this one. Am trying to get an answer from others as to whether AC timing register changes are completely unsafe, in which case your patch is probably the best way to move forward; or whether we can make the changes when no initiators are touching SDRAM. 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. A few years back before omap3 as part of omap2 lessons learned this issue was highlighted but design was not able to change. Recently implementation review at rtl provided the above points. I'm not aware of anyone seeing a crash but recommendation for safety is to not. 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 info at http://vger.kernel.org/majordomo-info.html
RE: MMC_CAP_SDIO_IRQ for omap 3430
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. For what its worth when I get a chance I'll take a peek. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
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 will be published. The issue is pretty
well understood now down to gate level so time to publish should be process.
Anyway, I guess the optimization would look something like this:
The below looks good.
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 210a806..7a98321 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -93,6 +93,8 @@ u32 voltage_off_while_idle;
OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
+#define INTC_SYSCONFIG 0x10
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -505,6 +507,12 @@ void omap_sram_idle(void)
prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
omap3_enable_io_chain();
}
+ /*
+* Disable INTC autoidle as it can cause interrupt controller
+* to enter unknown state with right combination of sleep / wakeup
+* transitions
+*/
+ omap_writel(0x0, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
/*
* On EMU/HS devices ROM code restores a SRDC value
@@ -561,6 +569,8 @@ void omap_sram_idle(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
}
+ /* Re-enable interrupt controller autoidle */
+ omap_writel(OMAP3430_AUTOIDLE, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
/*
* Enable smartreflex after WFI. Only needed if we
--
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
RE: OMAP2420-HS flashing question
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 developer must own the keys for particular CPU? It is possible to turn off the HS option so I'll be able to work with non-signed binaries? The problem is that I want to get kernel running on custom OMAP2420-HS board but have no keys. With out keys it's mostly impossible to introduce new boot code into the system. There isn't a practical way to 'turn off HS' with out destroying the omap chip itself. The way to add code would be through what ever mechanism the OEM has left to add code into the system (if any). From there depending on software some kind of KEXEC could be attempted. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: 3630: update is_chip variable
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/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -454,6 +454,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define CHIP_IS_OMAP3430ES2 (1 4) #define CHIP_IS_OMAP3430ES3_0(1 5) #define CHIP_IS_OMAP3430ES3_1(1 6) Should we add a little space for 3430 to grow? Current TRM already defines a 3.1.2. For this version changes are transparent to software. IIRC mostly internal cell tweaks to allow for expanded operating range. The CONTROL.CONTROL_IDCODE value is 0x0B6D 602F for OMAP34xx ES1.0. The CONTROL.CONTROL_IDCODE value is 0x1B7A E02F for OMAP34xx ES2.0. The CONTROL.CONTROL_IDCODE value is 0x2B7A E02F for OMAP34xx ES2.1. The CONTROL.CONTROL_IDCODE value is 0x3B7A E02F for OMAP34xx ES3.0. The CONTROL.CONTROL_IDCODE value is 0x4B7A E02F for OMAP34xx ES3.1. The CONTROL.CONTROL_IDCODE value is 0x7B7A E02F for OMAP34xx ES3.1.2. +#define CHIP_IS_OMAP3630ES1 (1 7) Its hard to guess how many more will come. Ideally it will be 3630 which is growing from this point on. It is faster/smaller/cheaper along with some bug fixes. 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 info at http://vger.kernel.org/majordomo-info.html
RE: MMC_CAP_SDIO_IRQ for omap 3430
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 make sure all power management is shut down during initial testing. The wake up mechanism for INACTIVE and OFF mode likely is not in place properly for MMC. This will make you a bit late for servicing interrupts. It seems unlikely you hit this issue yet, but you will. To wake from OFF mode you will need to set up a GPIO wake from SDIO line. Users I'm aware of so far (ti-wlan chips, etc) have used a separate gpio line for interrupts. 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 info at http://vger.kernel.org/majordomo-info.html
RE: MMC_CAP_SDIO_IRQ for omap 3430
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 make sure all power management is shut down during initial testing. The wake up mechanism for INACTIVE and OFF mode likely is not in place properly for MMC. This will make you a bit late for servicing interrupts. It seems unlikely you hit this issue yet, but you will. To wake from OFF mode you will need to set up a GPIO wake from SDIO line. Users I'm aware of so far (ti-wlan chips, etc) have used a separate gpio line for interrupts. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
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 controller and some interrupt. When this happens, interrupts are not delivered to ARM anymore and ARM will remain in WFI (wait for interrupt) until interrupt controller is forced to wake-up (i.e. lauterbach). Disable AUTOIDLE in INTC for now. Optimal work around enables and disables this around WFI. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
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 around WFI on custom board, works well but didn't get chance to measure the numbers. There was one report from a custom board when it made a difference. I've not tried to double check this data. I don't have the reporters setup so there is no guarantee I could reproduce anyway. In general optimization seemed to make sense. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RESEND] I2C: OMAP: Add missing wakeup events
/* 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) /* RX overflow wakeup */ +#define OMAP_I2C_WE_XUDF_WE (1 10) /* TX underflow wakeup */ These bits are not documented in OMAP3430, they are reserved. How can they be used? Hmm, that's a valid point. I will have to check if I can find more info on the background of this patch. AFAIK, these bits have been introduced in OMAP3630 as it has a new IP block for I2C. But these bits are reserved bits for OMAP3430. Couple notes: - IP block is updated but it is not new. These should just be some reserved bits converted. New bits expand wakeup capability and enhance FIFO operation with DMA. - Driver for a while supported OMAP1/2420 style I2C and OMAP2430/3/4 style I2C. Definitions between broad class drivers are different. The interrupt handler is easiest to see this. This is not so relevant to above bits but is good to keep in mind. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RESEND] I2C: OMAP: Add missing wakeup events
/* 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) /* RX overflow wakeup */ +#define OMAP_I2C_WE_XUDF_WE (1 10) /* TX underflow wakeup */ These bits are not documented in OMAP3430, they are reserved. How can they be used? Hmm, that's a valid point. I will have to check if I can find more info on the background of this patch. AFAIK, these bits have been introduced in OMAP3630 as it has a new IP block for I2C. But these bits are reserved bits for OMAP3430. Couple notes: - IP block is updated but it is not new. These should just be some reserved bits converted. New bits expand wakeup capability and enhance FIFO operation with DMA. - Driver for a while supported OMAP1/2420 style I2C and OMAP2430/3/4 style I2C. Definitions between broad class drivers are different. The interrupt handler is easiest to see this. This is not so relevant to above bits but is good to keep in mind. 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 info at http://vger.kernel.org/majordomo-info.html
RE: RE: Memory performance / Cache problem
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 just working with ONENAND. I found a patch which shows the L2 Cache status while kernel boot and implemented it : L2 Cache seems to be already enabled - so this is not the reason. So any other ideas? Are you confident your memory bus isn't running at 1/2 speed? I recall there was a couple day window during wtbu kernel upgrades where memory bus speed with pm was running 1/2 speed after kernel started up. This was somewhat a side effect of constraints frame work and a regression in forward porting. It seems unlikely psp kernel would have shipped with this bug but its something to check. This would match your results. If your memcpy() is neon based then I might be worried about l1neon-caching effects along with factors of (exlcusive-l1-l2-read-allocate cache + pld not being effective on l1 only l2). Which memcpy test are you using? Something in lmbench or just one you wrote. Generally results are a little hard to interpret with exclusive cache behavior in 3430's r1px core. 3630's r3p2 core gives more traditional results as exclusive feature has been removed by arm. If you have the ability using Lauterbach + per file will allow internal space dump which will show all critical parameters during test. It's a 1 minute check for someone who has done it before to ensure the few parameters needed are in line. I can send an example off line of how to do capture. I won't have time to expand on all relevant parameters. 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 info at http://vger.kernel.org/majordomo-info.html
RE: RE: RE: Memory performance / Cache problem
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 and timing, but memclock is fine. How did you physically verify this? Following Siarhei hints of initialize the buffers (around 1.2 MByte each) I get different results in 22kernel for use of malloc alone memcpy = 473.764, loop4 = 448.430, loop1 = 102.770, rand =29.641 calloc alone memcpy = 405.947, loop4 = 361.550, loop1 =95.441, rand =21.853 malloc+memset: memcpy = 239.294, loop4 = 188.617, loop1 =80.871, rand = 4.726 In 31kernel all 3 measures are about the same (unfortunatly low) level of malloc+memset in 22. Yes aligned buffers can make a difference. But probably more so for small copies. Of course you must touch the memory or mprotect() it so its faulted in, but indications are you have done this. I used a standard memcpy (think this is glib and hence not neonbased)? To be neonbased I guess it has to be recompiled? The version of glibc in use can make a difference. CodeSourcery in 2009 release added PLD's to mem operations. This can give a good benefit. It might be you have optimized library in one case and a non-optimized in another. 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 info at http://vger.kernel.org/majordomo-info.html
RE: RE: RE: RE: Memory performance / Cache problem
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 copies. Of course you must touch the memory or mprotect() it so its faulted in, but indications are you have done this. Mh, alignment (to an address) is done with malloc already. Probably you mean something different. I don't understand the difference. For me is malloc+memset=calloc. I'll send you the benchmark code, if you like. Ok, if it compiles I could try on sdp3430 or sdp3630. Alignment to a cache line is always best. This is 64 bytes in A8. Better yet, being 4K aligned is a good thing to reduce MMU effects. In both kernels I used the same rootfs (via NFS). Indeed I used CS2009q1 and its libs, but we are talking about factor 2..6. This must be something serious. 2009 pay version has optimized thrumb2 and arm mode libraries you download separately. I don't recall if free/lite version integrated this. What is your feeling? Does the 22 something strange or are the newer kernels slower that they have to be. There are a lot of differences between 22 kernel and current ones. First things I'd check would be around MMU settings, special ARM cp15 memory control regs, then omap memory and clock settings. Also some bad device could undercut you. Always good to cat /proc/interrupts and make sure something isn't spewing. Would be interesting to see results on other Omap3 boards with both old an new kernels. I've not noticed anything on sdp on somewhat recent kernels. 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 info at http://vger.kernel.org/majordomo-info.html
RE: Memory performance / Cache problem
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 misses on read operations and everything seems fast. This is unlikely to happen on real use, and it does not reflect real memory performance. So the benchmark is inadequate. Yep, benchmark is only useful so far. If you control factors it can be useful but it's far from 1-1, to extrapolate it to something meaningful at system level. You can actually get even 'better' numbers if you take the DDR part geometry into mind and SDRC (sdram-controller) scheduler. Our silicon validation people report out of this world numbers for very specific test cases. These are component tests for the memory controller to make sure it behaves. If you alternate between open banks you can do really fast operations. A good amount of that test is not practical to count on at HLOS level. It can help explain some anomalies and help in designing a fair test. 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 info at http://vger.kernel.org/majordomo-info.html
RE: Discussion: OMAP: PM: opp table handling
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 the performance delta from the nominal frequency. OPP25, OPP50, OPP80, OPP100, OPP120... NAK for two reasons: I wouldn't NAK too quickly. What does the load predictor use? Does it want to know about a million combinations? Not really. It is interesting to see if I'm on a 3GHz machine vs. a 1GHz one. But the predictor shouldn't care. What the predictor may care about is percentages and possible spacing between performance points. A well written user space program hopefully doesn't care in general either. I can recall the days when old apple games were ported and they were unusable for a bit because of all kinds of hardcoded timing loops. They were certainly not portable. Some drivers may practically care about frequency if they need to calculate some kind of QOS parameter but that is not the MPU. I do agree the hardware definition does at times change based on characterization data. We know that not every new OPP is even generally useful if its spacing is bad. A typical system might skip over some OPPs in actual use if spacing is not good. a) h/w changes language of OPP definitions every other silicons - OPP100 is not more informative than OPP1 or OPPX for that matter - with proper comments, even something like /* OPP25 - 25% of nominal performance */ #define VDD1_OPP_RELLLY_SLOW_OPP 1 Makes sense. b) if you look at discussion - we really DON'T want to use OPP definitions anymore - we would like folks to use frequency for precisely that reason - it is frequency that matters in the system. c) the field for OPP idx is probably redundant once we have proper APIs in place. At the lower level I do practically like some use of validated sets. Validation of every possible combination doesn't happen. There are 10 ways to program your DPLL for a similar output range. We should stick with what has been validated not create very big generalized functions. This functions get complex and many times miss out on obscure DPLL errata. At the high level use of percentage might be ideal then comes frequency. These values then are translated into discrete units which can be well tested. I'm not say ack or nak. Just that its not such a black white choice. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] OMAP: I2C: Add mpu wake up latency constraint in i2c
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 ~130us on fastest OPP. And when you add 70us of sleep transition into that, you get 200us at minimum. These values feel a bit on the high side. Have you measured since tweaking your DPLL M/N values? Are you measuring just across WFI or adding in some part of the idle code path? For us, the 500us constraint seems to work quite nicely. It removes the problems we had with i2c transfers timing out with off mode, and restores average transfer times (from clk_enable to clk_disable) to few hundred us (that were observed with retention). Some of the historic I2C timeout issues were from the wakeup sources not being programmed properly. Your constraint in my understanding is more about saving power. Today cpuidle doesn't predict interrupt events very well. As such the huge timeout used with i2c will never gate an off mode attempt. You will loose in context save and restore with out constraint. I floated some idea a while back on pm list to try and do something really simple with irqs. ... take a timestamp on last irq, when cpuilde goes to sleep if current time since last irq is too near then choose safe sleep state. Comments I got at that time was some didn't like extra overhead on irq path. However, I don't know I agree with that. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH][RFC] OMAP3: PM: Adding OSWR support
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 switch. Underlying spec's have always defined it as following: OSWR stands for Open SWitch Retention CSWR stands for Closed SWitch Retention 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 info at http://vger.kernel.org/majordomo-info.html
RE: Pull request for OMAP PM, clock, SDRC 2.6.32 patches
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 did set a date of the 16th as being the final date to sort out stuff (which was flexible to a degree) but since these patches were only posted on Saturday, and they're still being discussed, I don't think it would make sense for me to pull it today. I've dropped the two patches that are being discussed and reposted the remainder. The updated series is here (et seq.): http://marc.info/?l=linux-arm-kernelm=125059872200340w=2 and the pull request is here: http://marc.info/?l=linux-arm-kernelm=125059845132331w=2 Does this series conflict with patches already submitted on OMAP4? http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15488.html I'm not able to check now but its best to be careful here. Thanks, 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 info at http://vger.kernel.org/majordomo-info.html
RE: Pull request for OMAP PM, clock, SDRC 2.6.32 patches
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 comments, good, but is it conflicting? Thanks for clarifying, I'm not able to do a check right now and am hoping they don't interfere. Hopefully the series are not all too inter-related. Seems like getting to multiple and smaller feature branches will reduce collisions. Any big branch carries more risk (and potential reward also I suppose). 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 info at http://vger.kernel.org/majordomo-info.html
RE: [beagleboard] Re: USB EHCI problems
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 seem to get anyone around here to help me formalize exactly how to do this in the Kernel. So if you can figure it out, I would go ahead and do it. If you could please then post it to the community, that would be great. Gerald http://www.webos-internals.org/wiki/Patch_webOS_CPU_Frequency_or_Voltage_Sc aling#Enable_SmartReflex Seems hacking moves along fast, some basic info and mis-info on Pre. Pre kernel which is shipped needs a few patches and it is capable of running sr+dvfs at the same time. the file is there but after running echo -n 1 /sys/power/sr_vdd2_autocomp there is still zero in the file and in kernel log I see OPP3 doesn't support SmartReflex SR2: VDD autocomp not activated In older code you need both compile time and run time to get it to take. Just turning it on won't be so safe until some bug fixes make their way out. It may make sense to look at the 'pm' branch: http://elinux.org/OMAP_Power_Management pm branch needs a few changes to make it viable for sr. But this wiki page has comment: Enables SmartReflex autocompensation on VDD2 (Note: This feature can only be tested on a ES3.1 silicon): # echo 1 /sys/power/sr_vdd2_autocomp And AFAIK beagleboard revision C has ES3.0 silicon. So no luck here. Or can something still be done? You will only find characterized parameters for 3.1 and 3.1.1. These are production parts. I had heard a few bits of talk about running at lower voltage helping ehci out. That seems backwards even if tests show it working. I wonder if it is some artifact of a timing change which happens at lower voltage and because of some new internal chip activity. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3 14/20] OMAP: McBSP: Let element DMA mode hit retention also
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. Probably this behaves as you say but it seems possible that the bug is somewhere else in device handling. The generic hope is you can set smart-idle + wakeups at init time and never need to touch them again. There are a few known cases where the hardware IP does have some bug which force you to dynamically play with bits. Clockactivity settings are usually static also, but depending on how you configure your device (slave or master clocking) you will need to dynamically set these. It most you don't need all this dynamic twiddling of the idle protocol handshake bits. Doing it once at pm_init is what should be necessary. One example which comes to mind is MMC with DMA mode. Early drivers were finding RET was gated once the driver was active. In the first pass port to 3430 the writer toggled smart/no/forced idle and the system went happily back to sleep. However, after some profiling it was seen that this method of putting the device down ended up causing the clock disable to the device to take a very long time. Another level of digging into documents was done and it was found that it was necessary to reset some command line as part of a clean shut down. Doing it this way allowed the system to idle, and the time to shut down clocks was just a few nS instead of uS. As I recall some status was not cleared until the reset of the line. It did happen that toggling through handshakes had a side effect of also clearing it, but not in the intended way. 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 info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
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: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org Subject: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 Hi all, On OMAP3 we are creating a space for DSP components to have shared buffers using the boot arguments. mem=...@0x8000 mem=1...@0x8800 This creates a 40M hole for DSP components, the drivers dynamically do a request mem region and ioremap of pre-defined address space with in the 40M region. With the above setup, we see the system running for a while but then ends up with exception. Unable to handle kernel paging request at virtual address c7381000 The address reported here is not in kernel space, and this doesn't result in a kernel panic. Other observation: - The same setup works fine with no hole or space created. The 40M space for DSP components will be allocated at the end (216M). - If we increase the mem hole region we can make the system fail with in less time. - Free returns expected memory map While I am still debugging the issue, I thought of posting this message to know if there are any known issues with ARM architecture in handling such non contiguous space / mem hole. I see some special boot parameters for other architectures like exactmap, we don't see similar stuff on ARM. Do we need to port any such support for ARM ? Kindly advice, Thanks. Regards, Khasim -- 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 -- 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
RE: [PATCH v2] OMAP3: PM: USBHOST: clear wakeup events on both hosts
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. Because of the single WKST bit, we cannot know whether a wakeup event was on HOST1 or HOST2, so enable both fclocks before clearing the wakeup event to ensure both hosts can properly clear the event. Yes, if you need to clear bits clocks must be on. Question which comes to mind is if the wakeup bit should have been set for target mode. Ideally when this status is set the f-clk should have been already on. Does USB framework even export good control of possible sleep modes... Most WKST bits are used in conjunction with INACTIVE mode wakeup. The exception to this is WAKUP-domain WKSTs which are also used in wakes from RET or OFF mode. 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. Since the driver won't have access to PRCM registers the only places which can fix this issue today is the PRCM irq (like being proposed) or inside the clock-frame-work at the F-Clk shutdown point. Generally if status is hanging around when you try to sleep, you will have a failed sleep. Today what is happening is the prcm-irq will come and sweep up the status at some later time. This will allow an eventual sleep success. .. A - Sleeps states which don't require enumeration TARGET: INACTIVE mode+wakeup-capable-to-usb-resume (mstandby asserted dpll still requested) :: For USB, when it goes to USB-bus-suspend, if you want to wake on usb-bus-resume from the usb wake path, probably you would leave on the fclk. TARGET: RET/OFF mode+wakeup-capapble+USB-SAR (mstandby asserted no dpll requests) :: If you want to go to OFF or RET mode then you first move to usb-bus-suspend, then shut down f-clk, then setup for some io-ring wake event. B - Sleep states which require enumeration on wake -- mstandby must be asserted, however you can cheat to get there by using force-standby, forced-idle, then expect a full path reset and enumeration at wake up time. ... USB has a few state choices around sleep which it doesn't seem are well specified in code. Just hooking to existing suspend/resume handlers which are meant more for 'B' handling caused issues if people are going for the 'A' behavior. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] OMAP3: PM: USBHOST: clear wakeup events on both hosts
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 should really have done this as you don't always have a controlling USB driver. 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 info at http://vger.kernel.org/majordomo-info.html
linux symposium
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 info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [PATCH 1/2] ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache
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 is intended for only omap3 boards, move the function to the new file cache_flush.S. Minor point is file name or function name might change to be more reflective of what it does (cache_ops.S, and invalidate_dcache()). As there is not really any 'flush' (cleaning out dirty entries to main memory). Today the dcache is not even enabled in ARM ports. To do so requires MMU to be enabled to properly map IO regions as non-cached. As such all we ever need to do is possibly invalidate icache at run time (say you use Kermit to download something and try to execute it). The dcache invalidate today is only there to setup cache in clean state before calling the kernel. Later on a dcache-flush/icache-invalidate might need to be added if Dcache is actually enabled. Regards, Richard W. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
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-applied to current trees. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH -pm 1/2] SDRC: check for stuck DLL state machine and kick
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 that causes this problem? Perhaps the problem is partially related to PWDENA = 1 and erratum 1.150? Anyway, will do a test run here with this SDRC_POWER register value and see if the problem reproduces. It is my guess not for PWDENA as it was reported on a system with that not set. Yes that should not enabled per errata. Anyway it only does something in OFF type scenarios where you don't use self-refresh. Typical use cases don't seem to be using this. There are a few unlock events which are best for any focused test. Most are supposed to auto-relock but ... I've heard of some validation tests in a few areas maybe they will yield something. A quick note: in stress testing here, was able to confirm that SDRC_POWER = 0x000200AD causes problems under memory load and intensive CORE DVFS. SDRC_POWER = 0x0002009D seems to work fine. The difference is CLKCTRL = 1 (works) vs. CLKCTRL = 2 (fails). According to the TRM, CLKCTRL = 2 enables self-refresh when AUTOCOUNT reaches 0. There is probably some race between AUTOCOUNT and the CORE DVFS SRAM code, or it is tickling some SDRC bug. Will look into this further later. By the way, there appears to be a TRM bug in the Dynamic Power Saving Configurations table in the SDRC chapter. The External SDRC CLK column should have after AUTOCOUNT expiration for CLKCTRL = 1 rows. That is an interesting result. My suspicion also has been with some kind of self-refresh race and DLL lock/unlock conditions. DVFS would stress the DLL lock/unlock path. In your test did you have a crash or just find the DLL did not relock. The signature I'm looking for is not locking. A crash in this particular test might point more to some other issue in sequence. On another thread it was noted you had optimized out a needed delay after M2 divider change for DVFS. Fixing this might change behavior of this test. Stress testing in older code bases along with simulation result showed the delay was necessary. 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 info at http://vger.kernel.org/majordomo-info.html
RE: Reclaim address space on omaps, Tony on vacation in July
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 io.h clean-up patches. Looks like we should be able to reclaim about 454MB of the 640MB of the lost IO address space by doing the following: Using section entries to cover ranges provides superior performance. 1 TLB will cover a whole series of accesses when doing things like servicing an interrupt. Using fewer TLBs to cover system accesses leaves more in tact for application usage. I've not see recent data but long back TLB optimization provided sizeable performance boost for many applications. Additionally debug is simplified by having the simple static map around. Russell recently pointed out and David showed an example of how ioremap() can take an arch specific function which can return virtual address from already defined static ranges. I do think this is a nice clean up and optimization (to stop some double mapping which now happens with ioremap). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg03813.html So, I think yes moving to ioremap in all drivers is good, but it would use underlying static maps where they exist. It might be not _all_ ranges need to be fully static mapped, but the common device ones should be. On this thread there has been a mounting request for more physical memory. Starting to make a 2x2gig split option and perhaps understanding more how to use extended addressing like xscale is doing would be good road map stuff. If io.h is getting messy maybe it should be broken in to a couple files... Anyway, driver cleanup using common ioremap would be the big winner. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] OMAP3: PM: reset USB OTG module on boot
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 this is replacing was only being done on 34xx due to the smart-idle errata. However, this reset should be done even without any errata. Minor note, IIRC the different OTG IP used in OMAP2420 did require a similar force at boot time. That would be a different file if it exists. 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 info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3 PM: off-mode during idle, problem with UART1 console
-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. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH -pm 1/2] SDRC: check for stuck DLL state machine and kick
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? This is one pulled for a custom board: # ./readmem 0x6d70 0x000200AD 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH -pm 1/2] SDRC: check for stuck DLL state machine and kick
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 /* save value */ Richard, could this be done in one instruction, eliminating the need for the r5 temporary register? Or was this done intentionally? Its on purpose I suppose, perhaps there is an optimization. Above I want to make sure I restore the value I came in with for dlla_ctrl. I save off value in r5 for this. Below I clear and set dllidle bit. I don't take the time to figure out if it was set or not coming into function. I saved off value in r5 to allow for this. It is legal for it to be set or cleared in normal operation. The below set/clear needs to happen as 2 writes. The 3rd write is a restore. You could be mindful of input value and perhaps not do a 3rd write but my guess is that will take more code then it saves. + orr r6, r6, #0x10 /* dllidle on */ + str r6, [r4] + dsb + bic r6, #0x10 /* dllidle off */ + str r6, [r4] + dsb + str r6, [r4]/* restore old value */ + b wait_dll_lock_timed + 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH -pm 1/2] SDRC: check for stuck DLL state machine and kick
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 move to at least init. Having it at deadlock spot is a bit more conservative. Richard, since Paul and I cannot reproduce this currently, would you be able to test if a fix at init fixes the problems that you've seen? I did up the fix at this spot for a couple reasons. -1- This is where it was locked up... -2- This kind of operation needs to happen in uncached sram Doesn't doing at 1st init require pushing of another sram? Also as its not conclusive what causes it to enter this state other than SDRC_POWER association its safer to do it here. I think the boot loader should have tried to do this correctly. But I really don't know what it did. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH -pm 1/2] SDRC: check for stuck DLL state machine and kick
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 a bug. Thanks. Regards, Richard W.
RE: OMAP3 PM: off-mode during idle, problem with UART1 console
Kevin, Can you ping the system via network during on time? - generate some activity on uart to be awake then try. Why not fire up a second tty/shell on UART3 or just try with uart 3 on SDP. Bootargs change is easy enough. - this can say if you have uart specific issue or maybe 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 Subject: RE: OMAP3 PM: off-mode during idle, problem with UART1 console Kevin, What Silicon Rev does your SDP have? I currently am using an ES3.1 based SDP and I havent seen any of these issues you have reported with off-while-idle. Infact I have kept the board running overnight a couple times in the last week with off-while-idle and voltage scaling to 0v enabled, mainly to test the recent patch set (disabling Auto idle for PER in scratchpad memory) for stability. I will see if I can get hold of an ES3 and ES2.1 based SDP's and see if I reproduce the issue. Besides I use nfs and I am not sure if that's got something to do with it. Will try a ramdisk also. Does it take you a while to reproduce this, or is it seen after the very first UART inactivity? regards, Rajendra -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Wednesday, June 17, 2009 2:35 AM To: Nayak, Rajendra; Woodruff, Richard Cc: linux-omap@vger.kernel.org Subject: OMAP3 PM: off-mode during idle, problem with UART1 console Rajendra, Richard, Hoping you can shed some light, or give me some direction on where to debug this further... With the latest PM branch, I've notice that off-while idle isn't working on the SDP, but the same kernel works fine on the RX51. RET-while-idle works fine on both. This is with CPUidle disabled, so just using the default idle where MPU and CORE are changed together. More specifically, it seems to be the UART1 (CORE) console that never comes back from off-while-idle, but the UART3 (PER) console on RX51 works. On SDP, if I # echo 1 /sys/power/enable_off_mode # echo 1 /sys/power/voltage_off_while_idle # echo 1 /sys/power/sleep_while_idle After the UART inactivty timeout of 5 seconds, I start to see the sys_off_mode LED toggling between red and green with system timer wakeups. If I then push a key on the UART1 console, the LED goes green, stays for the 5 second UART inactivity and then goes back to toggling red/green again. However, I never get my console back and never see the characters on my console. If I keep typing, I keep the system from going back off (based on sys_off_mode LED) and as soon as I stop typing long enough for the inactivity timer to expiere (5 seconds) it goes back into off. Any ideas what's going on here? On RX51, the same thing works using UART3. Kevin -- 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 -- 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
RE: [PATCH 05/06] OMAP3: PM: Implement locking for any scratchpad access
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 access to scratchpad from OMAP and Baseband/Modem processor. This patch might be okay for the target use case. But there might still be a race window with this patch, where the modem could steal the MPU's lock or vice versa. That swp tries to guarantee atomicity through exclusive memory accesses, but the AXI2OCP bridge section of the TRM claims that the bridge translates exclusive accesses to non-exclusive read/write in the bridge (section 3.2.3.2). That seems to suggest that the memory accesses will be non-atomic and that therefore a race window exists. This is an incorrect interpretation. A race does not exist because of this point. The AXI2OCP does translate external excusive operations this way (STREX/LWREX). This is not the same for SWP. SWP generates a global bus lock. Exclusive operations do have a reservation in the L2 block. So they are good until they go to external memory. On OMAP these work as you expect with respect to the ARM, but won't work between ARM and DSP or other master. SWP on the other hand still works. SWP is a relative pig compared to STREX/LWREX as it locks the whole L3, compared to a small key address, but, it's a lot lighter than a mailbox. 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 info at http://vger.kernel.org/majordomo-info.html
RE: LDP support
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) 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. Yes. Today there are only r1pX OMAP3s today. In the future there will be r3px also. That's something that TI may know, but it's almost impossible for developers to know because: (a) the OMAP3430 TRMs aren't available. Yes it is publicly available in a few forms. Using google I was just able to find a few references. For public 3430 look here: http://focus.ti.com/pdfs/wtbu/SWPU114Q_PrelimFinal_EPDF_03_05_2009.pdf The 35xx one is out there also (mostly the same) and easier to find. The public TRM above has the ARM revision/patch version documented in section 3.1.2. The ARM core is r1p3 in OMAP3430-ES3.1 and r1p7 for OMAP3430-ES3.1.1. Last time I looked in an ID register it seemed ok but I had inside information and may have missed something. Your use of a run time check seemed good. Thanks, 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 info at http://vger.kernel.org/majordomo-info.html
RE: LDP support
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 can be hard to follow. There are public and private versions and many addendums. There are also 35xx vs. 34xx versions. In the end most of the necessary information is publically available. Sites like beagleboard and zoom try to make more of this digestible. 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 info at http://vger.kernel.org/majordomo-info.html
RE: LDP support
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 OMAP3s today. In the future there will be r3px also. Regards, 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] PM: drop clocks_off_while_idle
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 would be pretty useful to capture interface changes. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: disable OTG AUTOIDLE only with omap3430
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 (by Richard Woodruff/TI), as his comment : A new MUSB bug which is a match to data below was identified very recently (on hardware and in simulation). This bug is in 3430 and not 3630. As a priority test (and as new default) you should have engineers disable autoidle for MUSB block. This is the workaround which will show up in next errata. Signed-off-by: Niilo Minkkinen ext-niilo.1.minkki...@nokia.com Signed-off-by: Richard Woodruff r-woodru...@ti.com Yes this is needed for 34xx. Side note is this cost around 1mW of power during active mode of MUSB. When device is not active cost is not significant. System impact depends on duty cycle of MUSB in usecase. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/11] OMAP2/3: PM: push core PM code from linux-omap
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 resulting in full loss of state in the CPU. We seem to be able to avoid having to save the exception mode registers there. The same thing is done with sa11x0 and Samsung SoCs. I don't see any reason for OMAP to be special in this regard. The code flow is: - Wakeup event - ARM reboots and uses SOC mask ROM context restore helper - Mask ROM code jump to restore pointers with MMU OFF. - Restore code resets ARM CortexA8 state -*- Trustzone SMI calls are made to restore some secure state - Jump back from SRAM to C code The dangling question to me is if any of the cpu state is needed by the trustzone monitor code as a precondition. The doc's I have led me to believe its ok, but I've not verified this. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] PM: Disable usb host HW save and restore
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 use for this domain. Yes, usb-host autoidle was enabled when I was digging this issue. Host domain? (not host module). The USBTLL SAR in 3.0 and before silicon will case a deadlock on 2nd sleep attempt. On 3.1 and after its fixed. So ES3.0 devices are exposed to the cold reset issue (since USBTLL SAR is only enabled in ES3.1). Would you suspect that we can enable USB host SAR, if the AUTOIDLE is turned off? Then we would not need this patch. For 3.0 we used a software sar if ohci was in use. For ehci its not good enough as there is state not accessible by software. Not as you wrote. I was thinking you need to try to go to idle using CM_CLKSTCTRL_USBHOST = 1. Not at 0x3 and then waiting for a dependent event to trigger you. Once your preconditions are met you can initiate and idle ack sequence. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] PM: Disable usb host HW save and restore
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 transition from off to active state. Disabling for now. Some are is needed around USB host domain handling. There are a 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 use for this domain. You will want TLL or host SAR activated to minimally work around a possible false cold reset issue. There is a window coming back from OFF where a reset will be thrown. Enabling SAR conclusively moves the internal window so there is no danger. The error is fairly easily seen so if you start taking resets know this is likely the root cause. What Rev of CPU is the issue occurring on? The USBTLL SAR in 3.0 and before silicon will case a deadlock on 2nd sleep attempt. On 3.1 and after its fixed. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] PM: OMAP3 SDRC: fix some SDRAM settings for Qimonda parts
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 restrictions - any comments from TI on whether these 133.3MHz/66.6MHz rates should be dropped is most welcome. Alpha LDP board had only 133MHz rated memory on them. These were quickly replaced with beta then production boards with 166MHz rated memory. Probably only a few dumpsters at TI have 133MHz restricted alpha boards (and maybe at logicpd). I don’t' think you will even find an alpha in plastics. Nothing stops a person from running at 133 on the 166 rated parts. But most won't choose to on a 3430. Regards, Richard W.
RE: [PATCH 0/2] I2C: OMAP: spurious IRQ fixes
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 sleep while it waits for an I2C interrupt. It turns out that the current driver causes receive overruns also; it just hides them. The receive overruns are fairly straightforward to deal with by setting an MPU wakeup latency constraint during I2C operations. What kind of latency is being seen by i2c in kernel snapshot you are using? Do you have an idea of what is tolerable given an I2C frequency? Is this error showing up in 100k/400k/HS mode? Sometimes a constraint is the only way but it does have cost. 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 info at http://vger.kernel.org/majordomo-info.html
RE: PM: 4 Problems in OMAP3430 DVFS (SmartReflex, Cpufreq)
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 = mpu_opps + MAX_VDD1_OPP - 1; But in some cases, we should use 600Mhz for multimedia application. And, even thought we enable the maximum clock, CPU frequency seldom goes into maximum clock. I think we don't have to avoid registering the max OPP. Do you know if this restriction can be lifted now, i.e., can the silicon run at VDD1 OPP1 100% of the time and meet the device lifespan targets? So, there have been some characterization changes which give more leeway for software usage off overdrive. What you found before was guarantees against typical mobile usage for a few classes of devices. This was done using a mix of OPPs with the majority of active time in lower OPPs and inactive time in low idles (optimal usage for mix of typical operations, this is the way you would want to run ideally). Against this and many more variables, reliability data was validated and published. Recently there was some change to also measure active time at max overdrive for same usage mix. This resulted in still meeting lifetime goals for typical usage. This can translate to a smart phone maker of being able to use overdrive as they see fit and still have long life (assuming they can supply adequate power and still dissipate what ever additional heat there is). This is still not 100% of the time in active mode. I suspect TI will continue to create parts for certain markets when the need is there. The part might be nearly identical but the way it's rated (with chip binning and other tricks) will allow different guarantees. This fits well with mobile business customer needs. As an open source individual owner of a device, you might do things in a non-typical way. You are free to do this. Depending on which base chip variant you are using, its life may have some impact (or not). Your chip likely will still last many years. The phone or other device might die first. All that said, today personally, I feel much more comfortable exposing overdrives in the reference code. Mobile users and their devices which actually sleep at night should be pretty safe. Watch data sheets for details :) Regards, Richard W.
RE: 4 Problems in OMAP3430 DVFS (SmartReflex, Cpufreq)
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 transition_latency, so it becomes 10 seconds! It's really too long for DVFS. I measured transition latency by myself using oscilloscope and it's about 150 ~ 200m seconds. I think TI engineers may know more accurate figure. I wish we could update transition latency as soon as possible. That time sounds long. What points did you measure from and what was your system speeds? One thing to watch our for wait_clk_stable delay. PM branch needs some tweaks here. The value of 0x800 will result in a delay which can result in your display fifo under flowing. For an 800MHz Cortex a value of 0x18 will suffice. This value can be tuned to processor frequency if you like. When SDRC is disabled just above all traffic will be pended. You want to be past this as quick as possible. Regards, Richard W.
RE: 2.6.29 and SDP3430 now 2.6.30-rc2, q3-2007 compiler error
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_PERIODIC). The assembly generated looks shocking because it prepares the second function arguments in register R1 as expected and then 'pop' destroys it. A push before a function call is reasonable but this not quite understandable. Can this be taken up with Codesorcery team to check what is triggering compiler to generate such an assembly ? The compiler version is old enough I wouldn't anticipate they would do a fix unless someone was using this for production. Typically they release some for pay fix ups around a base. This may or may not be fixed in one of those. If anyone is using it they should speak up. The compiler probably noticed it could optimize away the function return point (can ret back to caller from called function instead of present one after call. It then messed up). 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 info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.29 and SDP3430
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 hang around: Kernels built with this compiler stuck into delay loop calibration. No idea why, but 2008q3-66 was working for me. 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. Calibration code is just is spinning and counting interrupts. 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 info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.29 and SDP3430
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, something is broke. Can put bad SDP kernel and vmlinux on a share and send me link? I'm feeling lazy, but could take a quick peek as it's curious :) Thanks, 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 info at http://vger.kernel.org/majordomo-info.html
RE: omap_wdt: modprobe fails
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 had noticed it broken in one older tree a while back. The probe routine at omap_wdt_disable() touches registers without trying to enable the clocks to the module. Before this a clk_get happens but no clk_enable. 314 platform_set_drvdata(pdev, wdev); 315 316 omap_wdt_disable(wdev); Actually there were a number of bugs here. The only reason the probe works at all is because the boot loader turned the clock on to stop it. If you make sure its shut off in loader you will crash here normally. Some fixes were made in an older tree which you can draw from to fix it. http://git.omapzoom.org/?p=repo/omapkernel.git;a=commitdiff;h=c1753c36b04db34660b6df94e5f395401985f0da 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 info at http://vger.kernel.org/majordomo-info.html
