From: Wolfram Sang <w.sang@pengutronix.de>
To: Huang Shijie <shijie8@gmail.com>
Cc: baruch@tkos.co.il, marek.vasut@gmail.com,
koen.beel.barco@gmail.com, Huang Shijie <b32955@freescale.com>,
linux-mtd@lists.infradead.org, Artem.Bityutskiy@intel.com,
linux-arm-kernel@lists.infradead.org, LW@karo-electronics.de
Subject: Re: [PATCH v2] MTD/GPMI bugfix : reset the BCH module when it is not MX23
Date: Sun, 1 Jan 2012 23:33:35 +0100 [thread overview]
Message-ID: <20120101223335.GA3756@pengutronix.de> (raw)
In-Reply-To: <CAMiH66HsFn4+6-whEC6G-qSPda3+3pBzd50i7iHh9Pg9TXHTXw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]
Hi,
> This happens because we do NOT follow the right init procedure. The IC
> guy told me.
> If the BCH was not initialized correctly, it can not guarantees the
> data is right.
> This is why the mx28 failed.
...
> For mx23, it should not reset the BCH, this is the right init
> procedure for mx23.
Okay, this was the information I was looking for. So, the MX23 cannot be reset
due to bug #2847. But it also does not NEED to be reset, which is unlike the
MX28 which needs the reset. Correct? Before that, it was only clear that MX23
cannot be reset. It was not clear (at least to me) if it still could then run
into the same problems as the MX28 after 10000+x boot cycles. That would be a
really bad situation: being in need of the reset which we can't do due to 2847.
> But I did not ever boot 10000 times on mx23. I am not sure if it can
> fail or not.
Hmm, can't your IC guy tell you? I was hoping he knows if the same problem which
happens on the MX28 can also happen on the MX23? I don't want to make your life
unnecessarily hard, but I'd really like to know if I need to warn customers
when using MX23 and NAND (and if so, we have to update the comment in the code).
> > bug 2847, we have a serious problem, because NAND won't work until the next
> > power-cycle? I am curious if my assumptions are true and we have a serious
> > problem on the MX23.
> You can test it if you have time. :)
Testing is guessing in this case, the problem could arise after <n+1> cycles if
I tested <n>. Actually knowing the situation would be more helpful, I'd think.
If this is not possible to find out, we'd need to add this as a comment, too,
so people experiencing problems have a pointer which can save them *a lot of*
time.
Kind regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: w.sang@pengutronix.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] MTD/GPMI bugfix : reset the BCH module when it is not MX23
Date: Sun, 1 Jan 2012 23:33:35 +0100 [thread overview]
Message-ID: <20120101223335.GA3756@pengutronix.de> (raw)
In-Reply-To: <CAMiH66HsFn4+6-whEC6G-qSPda3+3pBzd50i7iHh9Pg9TXHTXw@mail.gmail.com>
Hi,
> This happens because we do NOT follow the right init procedure. The IC
> guy told me.
> If the BCH was not initialized correctly, it can not guarantees the
> data is right.
> This is why the mx28 failed.
...
> For mx23, it should not reset the BCH, this is the right init
> procedure for mx23.
Okay, this was the information I was looking for. So, the MX23 cannot be reset
due to bug #2847. But it also does not NEED to be reset, which is unlike the
MX28 which needs the reset. Correct? Before that, it was only clear that MX23
cannot be reset. It was not clear (at least to me) if it still could then run
into the same problems as the MX28 after 10000+x boot cycles. That would be a
really bad situation: being in need of the reset which we can't do due to 2847.
> But I did not ever boot 10000 times on mx23. I am not sure if it can
> fail or not.
Hmm, can't your IC guy tell you? I was hoping he knows if the same problem which
happens on the MX28 can also happen on the MX23? I don't want to make your life
unnecessarily hard, but I'd really like to know if I need to warn customers
when using MX23 and NAND (and if so, we have to update the comment in the code).
> > bug 2847, we have a serious problem, because NAND won't work until the next
> > power-cycle? I am curious if my assumptions are true and we have a serious
> > problem on the MX23.
> You can test it if you have time. :)
Testing is guessing in this case, the problem could arise after <n+1> cycles if
I tested <n>. Actually knowing the situation would be more helpful, I'd think.
If this is not possible to find out, we'd need to add this as a comment, too,
so people experiencing problems have a pointer which can save them *a lot of*
time.
Kind regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120101/c526c02f/attachment-0001.sig>
next prev parent reply other threads:[~2012-01-01 22:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-30 8:27 [PATCH v2] MTD/GPMI bugfix : reset the BCH module when it is not MX23 Huang Shijie
2011-12-30 8:27 ` Huang Shijie
2011-12-30 14:01 ` Marek Vasut
2011-12-30 14:01 ` Marek Vasut
2011-12-30 14:36 ` Wolfram Sang
2011-12-30 14:36 ` Wolfram Sang
2011-12-31 2:23 ` Huang Shijie
2011-12-31 2:23 ` Huang Shijie
2011-12-31 3:15 ` Marek Vasut
2011-12-31 3:15 ` Marek Vasut
2011-12-31 3:31 ` Huang Shijie
2011-12-31 3:31 ` Huang Shijie
2011-12-31 4:45 ` Marek Vasut
2011-12-31 4:45 ` Marek Vasut
2011-12-31 15:43 ` Wolfram Sang
2011-12-31 15:43 ` Wolfram Sang
2012-01-01 15:23 ` Huang Shijie
2012-01-01 15:23 ` Huang Shijie
2012-01-01 22:33 ` Wolfram Sang [this message]
2012-01-01 22:33 ` Wolfram Sang
2012-01-03 2:30 ` Huang Shijie
2012-01-03 2:30 ` Huang Shijie
2012-01-03 11:11 ` Wolfram Sang
2012-01-03 11:11 ` Wolfram Sang
2012-01-04 2:43 ` Huang Shijie
2012-01-04 2:43 ` Huang Shijie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120101223335.GA3756@pengutronix.de \
--to=w.sang@pengutronix.de \
--cc=Artem.Bityutskiy@intel.com \
--cc=LW@karo-electronics.de \
--cc=b32955@freescale.com \
--cc=baruch@tkos.co.il \
--cc=koen.beel.barco@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=shijie8@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.