From patchwork Mon Aug 8 10:37:41 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Huang Shijie X-Patchwork-Id: 1043652 Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p78AY4be022718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Aug 2011 10:34:25 GMT Received: from canuck.infradead.org ([2001:4978:20e::1]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QqN9c-0000G1-Ot; Mon, 08 Aug 2011 10:33:52 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1QqN9c-0004GX-89; Mon, 08 Aug 2011 10:33:52 +0000 Received: from tx2ehsobe004.messaging.microsoft.com ([65.55.88.14] helo=TX2EHSOBE008.bigfish.com) by canuck.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QqN9Y-0004GC-A7; Mon, 08 Aug 2011 10:33:50 +0000 Received: from mail27-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Aug 2011 10:33:46 +0000 Received: from mail27-tx2 (localhost.localdomain [127.0.0.1]) by mail27-tx2-R.bigfish.com (Postfix) with ESMTP id 118A5D881B5; Mon, 8 Aug 2011 10:33:46 +0000 (UTC) X-SpamScore: -27 X-BigFish: VS-27(zz9371K1454K148cM119bM1521M1432Nc857h98dKzz1202h1082kzz8275bhz2dh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPVD:NLI; H:mail.freescale.net; RD:none; EFVD:NLI Received: from mail27-tx2 (localhost.localdomain [127.0.0.1]) by mail27-tx2 (MessageSwitch) id 1312799625797583_6915; Mon, 8 Aug 2011 10:33:45 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.250]) by mail27-tx2.bigfish.com (Postfix) with ESMTP id BD0C994804E; Mon, 8 Aug 2011 10:33:45 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 8 Aug 2011 10:33:45 +0000 Received: from az33smr02.freescale.net (10.64.34.200) by 039-SN1MMR1-003.039d.mgd.msft.net (10.84.1.16) with Microsoft SMTP Server id 14.1.323.2; Mon, 8 Aug 2011 05:33:44 -0500 Received: from localhost.localdomain (udp161135uds.ap.freescale.net [10.192.242.11]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id p78AXeU0028239; Mon, 8 Aug 2011 05:33:40 -0500 (CDT) Message-ID: <4E3FBC75.7010703@freescale.com> Date: Mon, 8 Aug 2011 18:37:41 +0800 From: Huang Shijie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Koen Beel Subject: Re: GPMI-NAND Status? References: <20110805135133.GA26981@pengutronix.de> <4E3F8087.6070206@freescale.com> In-Reply-To: X-OriginatorOrg: freescale.com X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110808_063348_586540_E09A9137 X-CRM114-Status: GOOD ( 55.12 ) X-Spam-Score: -2.3 (--) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (-2.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [65.55.88.14 listed in list.dnswl.org] Cc: Wolfram Sang , linux-mtd@lists.infradead.org, Shawn Guo , shijie8@gmail.com, linux-arm-kernel@lists.infradead.org, =?UTF-8?B?TG90aGFyIFdhw59tYW5u?= X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Mon, 08 Aug 2011 10:34:25 +0000 (UTC) Hi, > Hi Wolfram, > > Thanks for taking the initiative to summarize the current status. > Also thanks to Huang Shijie for all the work done so far. > > > On Mon, Aug 8, 2011 at 8:21 AM, Huang Shijie wrote: >> Hi Wolfram: >>> Hi, >>> >>> I am a bit uncertain how the state of the GPMI-NAND driver currently is, >>> so >>> I'll try to sum it up here. There is without doubt interest in getting the >>> driver into mainline from at least Huang, Shawn, Lothar, Koen and me, so I >>> wonder if we can join forces more effectively. First of all, I want to >>> thank >>> Huang Shijie for all his work so far which was already quite some effort; >>> this >>> sum-up is by no means meant as bashing, just trying to understand the >>> status >>> quo (Sidenote: I am more or less on holiday until Monday, so no time for >>> real >>> debugging myself. I write this mail so we hopefully gain a common >>> understanding. When I am back to full strength, I can then start working >>> on >>> what seems apropriate) >>> >>> Issues with the current driver I am aware of: >>> >>> DMA timeouts [1] >>> ================ >>> >>> [ 2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA >>> :1 >>> [ 3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!! >>> >>> Always reproducible by me when trying to format mtd0. Sometimes(always?) >>> seen >>> by Koen during boot (on read?). Never seen by Huang? It is currently >>> unclear if >> After I used a different .config, it never appears in my side. > flash_eraseall of mtd1 works for me. > ubi_format of mtd1 always gives the dma timeout > reading/writing of mtd0/1 always gives the dma timeout > I have seen dma timeout during boot if i try to enable ubi rootfs (so > that's the same issue as dma time during read/write). > > I don't use mtd0 for testing as this contains my uboot. > > I tested using Huang's .config and the Linaro git but still see > exactly the same issue. > strange. >>> the bug is in the GPMI driver, or in the MXS-DMA driver. Still, I'd say >>> the >>> issue is a show-stopper. We can't put a driver into mainline which leads >>> to the >>> above failure. The fact that there is _some_ configuration which works for >>> someone does not help, it doesn't work for Koen and me at least. We need > On my target, the mxs-dma is working for sdio until the gpmi-nand > gives a timeout. After that the dma for sdio is *not fully* working > anymore. > We need more log in following aspects: [1] apbh-dma registers [2] clk registers [3] gpmi registers Please git-apply the patch in the attachment. It will print out more DMA information WHEN dma-timeout occur. >> Hi Koen, do you test my uImage? >> Does the timeout occur? > I was not able to test you uImage. It ended with a "Kernel panic - not > syncing: read error". See (off list) mail from last week. > ok. >>> reliable drivers in mainline, so the issue needs to be resolved, >>> regardless >>> where the bug resides. >> ok. I will debug it too. >> >> >> Please test the driver again when you back to office. >> Pay attention to your version of /arch/arm/configs/mxs_defconfig. >> Your mxs_defconfig may miss Shawn Guo's patches. >> >> thanks. >> >> >>> problem overwriting all-0xff data in NAND [2] >>> ============================================= >>> >>> Although it occured only when writing JFFS2 images so far, this is a >>> generic >>> issue and needs to be fixed, right? >>> >> Artem said it should not change the driver, but the upper layer(jffs2). >> >> So I think i do not need to change the driver. >>> ecclayout needs to be used to show that OOB is fully in use [1] >>> =============================================================== >>> >>> Needed to make it work for JFFS2 and to pass the mtd-testsuite. A driver >>> only >>> working with UBIFS is surely not ready for mainline. >>> >> I programmed for mx6q in the recent days. I have no time to fix it. The mx6q >> can runs well now. >> >> So I will fix the issue in the following days. >> >>> Pecularities >>> ============ >>> >>> There are a few issues which are odd. I don't know if some are mainly >>> intended >>> for debugging, yet they shouldn't be in a mainline driver. At least: >>> >>> * custom sysfs-entries >> My sysfs-entries is in the GPMI-NAND directory. >> Does be a mainline driver means I should not have any sysfs-entries? >> If it does, i can remove it. >> >>> * custom kernel command line parameters >> The kernel command line 'gpmi_nand' is to avoid the conflict with other >> modules such as >> SD. >> >> If it's be removed, I have to use different config to resolve the issue >> which is not better either. :( >> >>> * namespacing (some functions have no prefix, some have "mil_", some have >>> mx23) >>> (I think 'mil' means 'mtd interface layer', but why is that needed?) >> The mil is used to make the gpmi_nand_data{} simple. >> Without it, the gpmi_nand_data{} will very big. >> >> The functions which have mx23 prefix are only used in mx23. >> The functions which have no prefix can used in both mx28 and mx23. >> >>> Complexity >>> ========== >>> >>> The driver is not easy to review. I wonder if it makes sense to use >>> incremental >>> patches for it? maybe making it a staging driver could be a solution for >>> that? >> Frankly speaking, the current driver is maybe the smallest version now. >> >> I even do not add the on-chip BBT feature now. >>> Huang, are you interested in accepting patches or do you prefer we just >>> point >>> at certain code and you then fix it? Starting with a simpler driver and >>> then >> Feel free to mail me the patch. it's welcome. >> >> >>> adding stuff might be another option if we can't chase all the bugs in the >>> current driver. >>> >>> That being said, I'd think fixing the DMA issue has prio #1 and maybe we >>> can >>> meet in IRC or something to work that out? Is there interest in that? >> What about gtalk? > Anything is good for me. > Could also be useful to make sure we test on the same HW as much as > possible and are using the same source tree. > HW I have: > - mx23evk rev C1 > - mx23evk rev B2 > - own target hw using mx23 lqfp-128 chip and different type of ddr and nand. > I have mx23evk rev C. Best Regards Huang Shijie From 69b5bf4d3bf73a89b521a7c592f5bea1d66c2755 Mon Sep 17 00:00:00 2001 From: Huang Shijie Date: Mon, 8 Aug 2011 18:39:11 +0800 Subject: [PATCH] print_more_log print out the DMA register when timeout occur. Signed-off-by: Huang Shijie --- drivers/dma/mxs-dma.c | 37 +++++++++++++++++++++++++++++++- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 2 + 2 files changed, 38 insertions(+), 1 deletions(-) diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c index 88aad4f..755cbfc 100644 --- a/drivers/dma/mxs-dma.c +++ b/drivers/dma/mxs-dma.c @@ -130,6 +130,7 @@ struct mxs_dma_engine { struct mxs_dma_chan mxs_chans[MXS_DMA_CHANNELS]; }; +struct mxs_dma_chan *g_mxs_chan; static void mxs_dma_reset_chan(struct mxs_dma_chan *mxs_chan) { struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma; @@ -239,6 +240,7 @@ static dma_cookie_t mxs_dma_tx_submit(struct dma_async_tx_descriptor *tx) struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(tx->chan); mxs_dma_enable_chan(mxs_chan); + g_mxs_chan = mxs_chan; return mxs_dma_assign_cookie(mxs_chan); } @@ -370,6 +372,7 @@ static void mxs_dma_free_chan_resources(struct dma_chan *chan) clk_disable(mxs_dma->clk); } +static int idx; static struct dma_async_tx_descriptor *mxs_dma_prep_slave_sg( struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len, enum dma_data_direction direction, @@ -381,7 +384,6 @@ static struct dma_async_tx_descriptor *mxs_dma_prep_slave_sg( struct scatterlist *sg; int i, j; u32 *pio; - static int idx; if (mxs_chan->status == DMA_IN_PROGRESS && !append) return NULL; @@ -606,6 +608,39 @@ err_out: return ret; } + +void dump_dma_reg(void) +{ + int i; + u32 stat1; + + struct mxs_dma_chan *mxs_chan = g_mxs_chan; + struct mxs_dma_engine *g_mxs_dma = mxs_chan->mxs_dma; + struct mxs_dma_ccw *ccw; + + printk("------------------------DMA DUMP END ------------\n"); + for (i = 0; i < 7; i++) { + stat1 = readl(g_mxs_dma->base + 0x10 * i); + printk("APBH REG :%x : %.8X\n", 0x10 * i, stat1); + } + for (i = 0; i < 7; i++) { + stat1 = readl(g_mxs_dma->base + 0x10 * i + 0x100); + printk("APBH REG :%x : %.8X\n", 0x10 * i + 0x100, stat1); + } + + for (i = 0; i < idx; i++) { + int j; + + ccw = &mxs_chan->ccw[i]; + printk("[ %d ] : ME : %.8x, next : %.8x, bits : %.8x, bytes : %.8x, buf : %.8x\n", + i, mxs_chan->ccw_phys + sizeof(*ccw) * i, + ccw->next, ccw->bits, ccw->xfer_bytes, ccw->bufaddr); + for (j = 0; j < 3; j++) + printk("[ %d ] PIO[%d] : %.8x\n", i, j, ccw->pio_words[j]); + } + printk("------------------------DMA DUMP END ------------\n"); +} + static int __init mxs_dma_probe(struct platform_device *pdev) { const struct platform_device_id *id_entry = diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c index 1c2cbc5..3d6895b 100644 --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c @@ -378,6 +378,7 @@ int start_dma_without_bch_irq(struct gpmi_nand_data *this, { struct completion *dma_c = &this->dma_done; int err; + extern void dump_dma_reg(void); init_completion(dma_c); @@ -391,6 +392,7 @@ int start_dma_without_bch_irq(struct gpmi_nand_data *this, if (err) { pr_info("DMA timeout, last DMA :%d\n", this->last_dma_type); if (gpmi_debug & GPMI_DEBUG_CRAZY) { + dump_dma_reg(); gpmi_show_regs(this); panic("-----------DMA FAILED------------------"); } -- 1.7.0.4