On Tue, Apr 17, 2012 at 5:30 PM, Kevin Hilman <khil...@ti.com> wrote:
> Grazvydas Ignotas <nota...@gmail.com> writes:
>>
>> Ok I did some tests, all in mostly idle system with just init, busybox
>> shell and dd doing a NAND read to /dev/null .
>
> Hmm, I seem to get a hang using dd to read from NAND /dev/mtdX on my
> Overo. I saw your patch 'mtd: omap2: fix resource leak in prefetch-busy
> path' but that didn't seem to help my crash.
I see overo doesn't set 16bit flag, I think it has NAND on 16bit bus?
Perhaps try this:
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -517,7 +517,7 @@ static void __init overo_init(void)
omap_serial_init();
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
- omap_nand_flash_init(0, overo_nand_partitions,
+ omap_nand_flash_init(NAND_BUSWIDTH_16, overo_nand_partitions,
ARRAY_SIZE(overo_nand_partitions));
usb_musb_init(NULL);
usbhs_init(&usbhs_bdata);
Also only pandora is using NAND DMA mode right now in mainline, the
default polling mode won't exhibit the latency problem (with all other
polling consequences like high CPU usage), so this is needed too for
the test:
--- a/arch/arm/mach-omap2/common-board-devices.c
+++ b/arch/arm/mach-omap2/common-board-devices.c
@@ -127,6 +127,7 @@ void __init omap_nand_flash_init(int options,
struct mtd_partition *parts,
nand_data.parts = parts;
nand_data.nr_parts = nr_parts;
nand_data.devsize = options;
+ nand_data.xfer_type = NAND_OMAP_PREFETCH_DMA;
printk(KERN_INFO "Registering NAND on CS%d\n", nandcs);
if (gpmc_nand_init(&nand_data) < 0)
I also forgot to mention I was using ubifs in my test (dd'ing large
file from it), I don't think it has much effect, but if you want to
try with that:
.config
CONFIG_MTD_UBI=y
CONFIG_UBIFS_FS=y
--
ubiformat /dev/mtdX -s 512
ubiattach /dev/ubi_ctrl -m X # X from mtdX
ubimkvol /dev/ubi0 -m -N somename
mount -t ubifs ubi0:somename /mnt
>> To me it looks like this results from many small things adding up..
>> Idle is called so often that pwrdm_p*_transition() and those
>> pwrdm_for_each_clkdm() walks start slowing everything down, perhaps
>> because they access lots of registers on slow buses?
>
> Yes PRCM register accesses are unfortunately rather slow, and we've
> known that for some time, but haven't done any detailed analysis of the
> overhead.
>
> Using the function_graph tracer, I was able to see that the pre/post
> transition are taking an enormous amount of time:
>
> - pwrdm pre-transition: 1400+ us at 600MHz (4000+ us at 125MHz)
> - pwrdm post-transtion: 1600+ us at 600MHz (6000+ us at 125MHz)
Hmm, with this it wouldn't be able to do ~500+ calls/sec I was seeing,
so the tracer overhead is probably quite large too..
> Notice the big difference between 600MHz OPP and 125MHz OPP. Are you
> using CPUfreq at all in your tests? If using cpufreq + ondemand
> governor, you're probably running at low OPP due to lack of CPU activity
> which will also affect the latencies in the idle path.
I used performance governor in my tests, so it all was at 600MHz.
> I'm looking into this in more detail know, and will likely have a few
> patches for you to experiment with.
Sounds good,
--
Gražvydas
--
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
