[PATCH 0/3] MTD: OneNAND: Fix OneNAND DMA error handling and 2KiB pagesize

[Kyungmin Park]

On Wed, Sep 1, 2010 at 11:35 AM, Kyungmin Park <kmpark at infradead.org> wrote:
> On Wed, Sep 1, 2010 at 8:13 AM, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
>> On Tue, 2010-08-31 at 08:27 +0900, Kyungmin Park wrote:
>>> On Mon, Aug 30, 2010 at 9:52 PM, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
>>> > On Fri, 2010-08-27 at 11:55 +0900, Kyungmin Park wrote:
>>> >> Kyungmin Park (3):
>>> >>       MTD: OneNAND: Remove unused cmd_map at s5pc110
>>> >>       MTD: OneNAND: Fix loop hang when DMA error at Samsung SoCs
>>> >>       MTD: OneNAND: Fix 2KiB pagesize handling at Samsung SoCs
>>> >>
>>> >>  drivers/mtd/onenand/samsung.c |   17 +++++++----------
>>> >>  1 files changed, 7 insertions(+), 10 deletions(-)
>>> >
>>> > Taken patches 1 and 3, requested a change for patch 2. Pushed patches 1
>>> > and 3 to l2-mtd-2.6.git / dunno, thanks.
>>>
>>> To David, Artem,
>>> Can you include these patches to linux-2.6.36-rc4? since it's bug fixes.
>>>
>>> How do you think?
>>
>> Note, Linus nowadays tends to be stricter about what goes in -rc. Why
>> would the first patch be a fix deserving urgent merging?
>
> There's no problem with s5pc110 since there's no DMA error. but new
> SOC s5pc210 has some problem with DMA.
> it occurs the DMA error and can't exit the loop. as it's decided to
> use the 2.6.36 for s5pc210 we need to fix it ASAP.
>
>>
>> About the second patch, what if you was mistaken and 20msces is not
>> enough sometimes? Don't you afraid to introduce another bug with this?
> If it takes more then 20msec it's really slow device. I think I give
> the enough time to transfer 2KiB or 4KiB pagesize transfer at DMA.
>
> I'll measure the real time, how much time taken at 2.6.35 kernel and
> give exact number.

Unit is usec, so it takes 20 usec for 2KiB pagesize transfer. I use
the msec for some board don't implement the HRT or based on 10msec
timer. I give the 2 chances. As 10 msec can miss the time.
[   11.402082] s5pc210_dma_ops[575] 19
[   11.404445] s5pc210_dma_ops[575] 21
[   11.408790] s5pc210_dma_ops[575] 21
[   11.415221] s5pc210_dma_ops[575] 22
[   11.417433] s5pc210_dma_ops[575] 19
[   11.420867] s5pc210_dma_ops[575] 21
[   11.427553] s5pc210_dma_ops[575] 22
[   11.429736] s5pc210_dma_ops[575] 21
[   11.435615] s5pc210_dma_ops[575] 19
[   11.437885] s5pc210_dma_ops[575] 21
[   11.443540] s5pc210_dma_ops[575] 21
[   11.445726] s5pc210_dma_ops[575] 21
[   11.487652] s5pc210_dma_ops[575] 20
[   11.501755] s5pc210_dma_ops[575] 22
[   11.503941] s5pc210_dma_ops[575] 21
[   11.508539] s5pc210_dma_ops[575] 21
[   11.510879] s5pc210_dma_ops[575] 19
[   11.515527] s5pc210_dma_ops[575] 21
[   11.517840] s5pc210_dma_ops[575] 19
[   11.521170] s5pc210_dma_ops[575] 19
[   11.526044] s5pc210_dma_ops[575] 21
[   11.575904] s5pc210_dma_ops[575] 19

>
>>
>> Probably for 2.6.36 the older version of your patch can be merged, and
>> then you can add timeout support on top?
>
> Now I implemented it as DMA polling method, but also implemented the
> DMA interrupt codes. as it's new implementation. I don't expect it
> can't merge at this windows. so send fixed codes.
>
>>
>> Third patch is probably ok, if you really want it in 2.6.36.
>>
>> So, I've moved the third patch to l2-mtd-2.6.git / for-2.6.36, I've left
>> the first patch in the dunno branch, and I also put the original version
>> of the second patch to the for-2.6.36 branch.
>>
>> Please, add timeout on top of l2-mtd-2.6.git / for-2.6.36 and send it.
>> I'll then take care of it, or at least try.
>
> Thank you,
> Kyungmin Park
>>
>> --
>> Best Regards,
>> Artem Bityutskiy (Битюцкий Артём)
>>
>>
>