All,
We've learned a few more things:
1.) We have found a way to get it to happen pretty consistently. We simply run
iperf in a loop using the EMAC port to some other device.
2.) The crash ONLY happens on our custom board, not on the Twister dev kit.
This is true despite the fact that I
On Wed, Jun 6, 2012 at 11:44 AM, CF Adad cfa...@rocketmail.com wrote:
All,
We've learned a few more things:
1.) We have found a way to get it to happen pretty consistently. We simply
run iperf in a loop using the EMAC port to some other device.
2.) The crash ONLY happens on our custom
* Shilimkar, Santosh santosh.shilim...@ti.com [120605 23:41]:
I don't know the AMXX architecture that well but looking at the
crash-log, am not sure GPMC should play in role here.
What I think is, it is mostly memory corruption and can be caused by
many reasons as Tony outlined.
Bad GPMC
Hi Santosh,
Thanks for the comments! If you do not think the GPMC can be a factor here,
that's great news. I'd certainly love to take something off the list.
Unfortunately, we've run the memtester 200M (we only have 256MB) in constant
cycles for weekends at a time, and have not had it
Salut Paul,
On 6/6/2012 12:55 AM, Paul Walmsley wrote:
Hello Benoît
On Tue, 29 May 2012, Cousson, Benoit wrote:
On 5/25/2012 11:56 PM, Paul Walmsley wrote:
This patch is effectively a workaround for a hardware oversight. A
better hardware approach would have been to implement a smart-idle
Hi Tony,
Thanks again. I'm really starting to think the GPMC almost has to be
contributing. In our setup, we have 2 separate versions of a baseboard for the
TAM. One version has the LAN9221 as a secondary Ethernet, while the other does
not. Otherwise, they're basically the same. I can run
On 6/6/2012 2:28 AM, Paul Walmsley wrote:
Hello Benoît
On Tue, 5 Jun 2012, Paul Walmsley wrote:
On Tue, 29 May 2012, Cousson, Benoit wrote:
So in fact, I'm wondering if a new flag is needed. We can potentially
apply that if idlemodes == (SIDLE_FORCE | SIDLE_NO).
We need to check which IP
* Tomi Valkeinen tomi.valkei...@ti.com [120605 06:24]:
Hi,
On Tue, 2012-06-05 at 01:22 -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [120603 11:05]:
Looks like the DSS stuff has broken OMAP builds again during this
merge window:
* Russell King - ARM Linux li...@arm.linux.org.uk [120605 15:07]:
I pulled Linus' tree at 7am UTC, and reran the builds after updating
the build tree with that (plus my pending devel stuff). The resulting
randconfig spat out this:
arch/arm/mach-omap2/dsp.c: In function
Here are some fixes for review.
Regards,
Tony
---
Tony Lindgren (3):
ARM: OMAP: Fix MMC_OMAP build when only MMC_OMAP_HS is selected
ARM: OMAP3: Fix omap3_l3_block_irq warning when CONFIG_BUG is not set
ARM: OMAP2+: Fix compile for CONFIG_TIDSPBRIDGE platform init code
If CONFIG_MMC_OMAP is not set and CONFIG_MMC_OMAP_HS is set,
we can get error: redefinition of `omap242x_init_mmc' error.
Fix it by removing MMC_OMAP_HS from MMC_OMAP ifdefs as they do
not depend on each other.
While at it, also prettify the formatting a bit.
Signed-off-by: Tony Lindgren
Otherwise we will get:
arch/arm/mach-omap2/omap_l3_smx.c: In function ‘omap3_l3_block_irq’:
arch/arm/mach-omap2/omap_l3_smx.c:156: warning: unused variable ‘address’
arch/arm/mach-omap2/omap_l3_smx.c:155: warning: unused variable ‘multi’
arch/arm/mach-omap2/omap_l3_smx.c:154: warning: unused
Commit 7f28427b (ARM: OMAP2+: Move omap_dsp_reserve_sdram_memblock() to
mach-omap2)
moved DSP platform init code, but failed to include memblock.h causing:
arch/arm/mach-omap2/dsp.c: In function 'omap_dsp_reserve_sdram_memblock':
arch/arm/mach-omap2/dsp.c:58: error: implicit declaration of
* CF Adad cfa...@rocketmail.com [120606 00:55]:
Do you folks know of a good reference for properly calculating these GPMC
settings?
In theory you just need to know the timings of connected components,
then check which ones depend on cycles and which ones depend on time.
Also take into
Hi,
* Uri Yosef ur...@variscite.com [120517 05:34]:
Hi Tony,
This is the updated DTS patch for Vatiscite OMAP4 SOM support
Looks OK to me, but can you please repost one more time with
devicetree-disc...@lists.ozlabs.org in Cc so people have a chance
to ack this patch there?
Thanks,
Tony
Hi Kevin,
For panda and blaze, wl12xx sdio card can't be found without set on
label in struct omap4_clk32kg_idata,
and after search maillist I found Vishal had posted patch for it.
http://marc.info/?l=linux-omapm=132017988123957w=2
But after more investigations, if clk32kg regulator isn't on
my 2 cents.
On 06/06/2012 11:41 AM, Tony Lindgren wrote:
* CF Adad cfa...@rocketmail.com [120606 00:55]:
Do you folks know of a good reference for properly calculating these GPMC
settings?
In theory you just need to know the timings of connected components,
then check which ones depend
On Wed, May 30, 2012 at 2:51 AM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Timers in PER domain periodically report old time from TCRR in
posted mode if ick 4*fck. Therefore, set timer to non-posted
whenever ick 4*fck for all timers.
Is there an
Hi,
On Mon, May 28 2012, Felipe Balbi wrote:
On Sun, May 27, 2012 at 11:53:47PM -0700, Tony Lindgren wrote:
Commit b6e0703b (mmc: omap: make it behave well as a module) made some
__devinit changes but missed one function causing a section warning:
WARNING: vmlinux.o(.devinit.text+0x8604):
Hi,
On Mon, May 28 2012, Tony Lindgren wrote:
Commit b01a4f1c (mmc: omap: convert to per instance workqueue) initializes
the workqueue too late causing the following:
Unable to handle kernel NULL pointer dereference at virtual address
pgd = c0004000
[] *pgd=
Hi,
On Wed, May 30 2012, Tony Lindgren wrote:
Commit fa550189 (mmc: core: Prevent eMMC VCC supply to be cut from late init)
slightly affected timings for how things are done for the omap MMC driver
causing the MMC cards not getting detected any longer.
Turns out this was caused by buggy
Hi Kevin, Benoit, Paul,
On Fri, Jun 1, 2012 at 2:16 AM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 31 May 2012, ABRAHAM, KISHON VIJAY wrote:
I would mark the multiplexed device compatible with simple-bus, which
results in the child devices automatically getting added.
hmm.. ocp2scp has
All,
Thanks for all your input and time. We'll try rolling our sleeves up and
looking at these GPMC timings again. Looking through those links I shared
previously, it looks like the AM35xx GPMC may be setup a bit differently than
the OMAP or DM. What items should I be taking into account as
On Tue, Jun 05, 2012 at 02:19:02PM +0100, Jon Hunter wrote:
Hi Will,
Hi Jon,
On 06/04/2012 04:44 PM, Jon Hunter wrote:
Anyway, let me know what you think of this approach. An alternative is
to put the calls pm_runtime_get/put outside of the reserve/release_pmu,
which would be a simpler
Hi Will,
On 06/06/2012 12:33 PM, Will Deacon wrote:
On Tue, Jun 05, 2012 at 02:19:02PM +0100, Jon Hunter wrote:
Hi Will,
Hi Jon,
On 06/04/2012 04:44 PM, Jon Hunter wrote:
Anyway, let me know what you think of this approach. An alternative is
to put the calls pm_runtime_get/put outside
This seems to be something trivial, but so far we're stumped. The AM35xx has
the built-in DaVinci EMAC and the usual GPMC. Our board uses the EMAC coupled
with an SMSC LAN8710 PHY for one port, and a secondary port provided by a
LAN9221 wired up through the GPMC. The trouble is, if I enabled
Hi Tony,
On Tuesday 05 June 2012 12:12 PM, Tony Lindgren wrote:
* Rajendra Nayakrna...@ti.com [120601 05:13]:
The data is autogenerated using the OMAP autogeneration scripts (python
scripts). Thanks to Mike Turquette for the initial efforts in updating
the script which was later updated by
27 matches
Mail list logo
