Using GPMI-NAND driver on iMX28 using 3.4-rc1?

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

Has anybody out there been successful in running the new GPMI-NAND
driver when running 3.4-rc1 kernel on any kind of MX28 hardware?

We have enabled options

CONFIG_SOC_IMX28=y
CONFIG_MTD_NAND_GPMI_NAND=y
CONFIG_MXS_DMA=y

When booting kernel with initcall_debug we never see that
gpmi_nand_probe() function is never getting called.

We have tried booting board with kernel parameters
mtdparts=gpmi-nand:10(m),-(user)  or
mtdparts=imx28-gpmi-nand:10(m),-(user)  without any luck.

I have gone through the MTD  mailinglist log, and I didn't find
details on how this GPMI-NAND driver was actually tested on hardware.

Would appreciate the help.

-Sam

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]


> When booting kernel with initcall_debug we never see that
> gpmi_nand_probe() function is never getting called.

You probably don't have a NAND device registered. Then, there is nothing to
bind a driver to.

> I have gone through the MTD  mailinglist log, and I didn't find
> details on how this GPMI-NAND driver was actually tested on hardware.

It should be there somewhere, the mach relevant patches have been mentioned
there, too.

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 --]

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

Okay I will track this down

I don't see any of the mach-* files setting up the
gpmi_nand_platform_data so I wonder if this GPMI-NAND driver for has
ever been tested for NAND on mx28?

I will do that setup for our hardware, but would like to at least hear
from anyone that has used new gpmi-nand driver sucessfully, i will
report back my findings.

-Sam

On Wed, Apr 4, 2012 at 12:01 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>
>> When booting kernel with initcall_debug we never see that
>> gpmi_nand_probe() function is never getting called.
>
> You probably don't have a NAND device registered. Then, there is nothing to
> bind a driver to.
>
>> I have gone through the MTD  mailinglist log, and I didn't find
>> details on how this GPMI-NAND driver was actually tested on hardware.
>
> It should be there somewhere, the mach relevant patches have been mentioned
> there, too.
>
> Regards,
>
>   Wolfram
>
> --
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]


> I don't see any of the mach-* files setting up the
> gpmi_nand_platform_data so I wonder if this GPMI-NAND driver for has
> ever been tested for NAND on mx28?

linux-mtd should contain quite some discussion about this driver :)
And yeah, I do use it.

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

Would love to see how you registering your nand device for your board,
if that can be shared?

I am using the 3.4-rc1 from kernel.org

I am registering nand device using function below, it is exact same
board as MX28EVK board as far as pin setups are ( fwiw on this board
older implementation NAND_NFC works just fine )

static int board_gpmi_nand_platform_init(void)
{
        return mxs_iomux_setup_multiple_pads(board_gpmi_nand_pads,
                                ARRAY_SIZE(board_gpmi_nand_pads));
}

struct gpmi_nand_platform_data amp_nand_config = {
        .platform_init = board_gpmi_nand_platform_init,
        .min_prop_delay_in_ns = 5,
        .max_prop_delay_in_ns = 9,
        .max_chip_count = 1,
        .partitions = 0,
        .partition_count = 0,
};
static void mx28_nand_register()
{
        mxs_add_gpmi_nand( &amp_nand_config  ,&mx28_gpmi_nand_data);
}

Now I boot the board with command mtdparts="gpmi-nand:10m(boot),-(fs)"
I do see /dev/mtd0, mtd1 cat /proc/mtd shows right information.

During init relevant messages related to nand are:

mxs-dma mxs-dma-apbh: initialized
mxs-dma mxs-dma-apbx: initialized
...
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08ABAEAH4)
Scanning device for bad blocks
Bad eraseblock 0 at 0x000000000000
GPMI NAND driver registered. (IMX)

However moment I try to do  flash_erase /dev/mtd1 0 0 I see following error:

kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
Modules linked in:
CPU: 0    Not tainted  (3.4.0-rc1-09874-g9e81810-dirty #6)
PC is at mxs_dma_int_handler+0xfc/0x16c
LR is at handle_irq_event_percpu+0xc4/0x258
pc : [<c024c924>]    lr : [<c006e47c>]    psr: 60000093
sp : c3b99b00  ip : c3b99b28  fp : c3b99b24
r10: 00000000  r9 : c0529058  r8 : 00000000
r7 : 00000010  r6 : 00000004  r5 : c3811000  r4 : 00000004
r3 : c38111e0  r2 : 00000000  r1 : 00000000  r0 : 00000058
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: 42ce4000  DAC: 00000015
Process flash_erase (pid: 1214, stack limit = 0xc3b98270)


-Sam

On Wed, Apr 4, 2012 at 11:33 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>
>> I don't see any of the mach-* files setting up the
>> gpmi_nand_platform_data so I wonder if this GPMI-NAND driver for has
>> ever been tested for NAND on mx28?
>
> linux-mtd should contain quite some discussion about this driver :)
> And yeah, I do use it.
>
> --
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEUEARECAAYFAk98k+oACgkQD27XaX1/VRsaggCfcBhlEj9Yyof2YTcFMlPRBtto
> R3UAmJr1XJ8681YRJJhWYGzLiPYAdfo=
> =EEDL
> -----END PGP SIGNATURE-----
>

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Fabio Estevam]

On Wed, Apr 4, 2012 at 5:27 PM, Sam Gandhi <samgandhi9@gmail.com> wrote:

> However moment I try to do  flash_erase /dev/mtd1 0 0 I see following error:
>
> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
> Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
> Modules linked in:
> CPU: 0    Not tainted  (3.4.0-rc1-09874-g9e81810-dirty #6)
> PC is at mxs_dma_int_handler+0xfc/0x16c
> LR is at handle_irq_event_percpu+0xc4/0x258
> pc : [<c024c924>]    lr : [<c006e47c>]    psr: 60000093
> sp : c3b99b00  ip : c3b99b28  fp : c3b99b24
> r10: 00000000  r9 : c0529058  r8 : 00000000
> r7 : 00000010  r6 : 00000004  r5 : c3811000  r4 : 00000004
> r3 : c38111e0  r2 : 00000000  r1 : 00000000  r0 : 00000058
> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 0005317f  Table: 42ce4000  DAC: 00000015
> Process flash_erase (pid: 1214, stack limit = 0xc3b98270)

Please try reverting commit 00292bbf. Check
http://www.spinics.net/lists/kernel/msg1321399.html

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

On Wed, Apr 4, 2012 at 1:55 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Wed, Apr 4, 2012 at 5:27 PM, Sam Gandhi <samgandhi9@gmail.com> wrote:
>
>> However moment I try to do  flash_erase /dev/mtd1 0 0 I see following error:
>>
>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
>> Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
>> Modules linked in:
>> CPU: 0    Not tainted  (3.4.0-rc1-09874-g9e81810-dirty #6)
>> PC is at mxs_dma_int_handler+0xfc/0x16c
>> LR is at handle_irq_event_percpu+0xc4/0x258
>> pc : [<c024c924>]    lr : [<c006e47c>]    psr: 60000093
>> sp : c3b99b00  ip : c3b99b28  fp : c3b99b24
>> r10: 00000000  r9 : c0529058  r8 : 00000000
>> r7 : 00000010  r6 : 00000004  r5 : c3811000  r4 : 00000004
>> r3 : c38111e0  r2 : 00000000  r1 : 00000000  r0 : 00000058
>> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
>> Control: 0005317f  Table: 42ce4000  DAC: 00000015
>> Process flash_erase (pid: 1214, stack limit = 0xc3b98270)
>
> Please try reverting commit 00292bbf. Check
> http://www.spinics.net/lists/kernel/msg1321399.html

I reverted that commit and I still see following  error!

flash_erase /dev/mtd1 0 0
Erasing 1------------[ cut here ]------------
kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
Modules linked in:
CPU: 0    Not tainted  (3.4.0-rc1-09876-g2e4bb28-dirty #1)
PC is at mxs_dma_int_handler+0xfc/0x16c
LR is at handle_irq_event_percpu+0xc4/0x258
pc : [<c024c924>]    lr : [<c006e47c>]    psr: 60000093
sp : c3aadb00  ip : c3aadb28  fp : c3aadb24
r10: 00000000  r9 : c0529058  r8 : 00000000
r7 : 00000010  r6 : 00000004  r5 : c3811000  r4 : 00000004
r3 : c38111e0  r2 : 00000000  r1 : 00000000  r0 : 00000058
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: 42cd8000  DAC: 00000015
Process flash_erase (pid: 1205, stack limit = 0xc3aac270)
Stack: (0xc3aadb00 to 0xc3aae000)
db00: c026514c c006e5d4 c39c5800 00000058 f5000000 c3aadc0c c3aadb64 c3aadb28
db20: c006e47c c024c838 c3aadb54 c3aadb38 c000c5a8 c000b0dc c000b0fc c0529058
db40: c39c5800 f5000000 c3aadc0c ffffffff 00000000 00000000 c3aadb7c c3aadb68
db60: c006e674 c006e3c8 c0529058 00000000 c3aadb94 c3aadb80 c0071040 c006e620
db80: c0070f7c 00000058 c3aadbac c3aadb98 c006dcc0 c0070f8c 00000130 00000058
dba0: c3aadbc4 c3aadbb0 c0009f1c c006dca0 c024c338 20000013 c3aadbd4 c3aadbc8
dbc0: c0008648 c0009ebc c3aadc34 c3aadbd8 c03a3894 c0008640 00007efa f5004000
dbe0: 00000300 c3811268 c3811294 c3811294 00000000 c3811268 ffffffff 00000000
dc00: 00000000 c3aadc34 f5004000 c3aadc20 c024c32c c024c338 20000013 ffffffff
dc20: c024c308 c390b000 c3aadc54 c3aadc38 c0291ad8 c024c318 00000001 c390b000
dc40: 00000000 c390b4dc c3aadc8c c3aadc58 c0292600 c0291a9c 00000003 00000000
dc60: 00000006 00830001 00000000 00000000 c390b000 00000070 ffffffff c390b078
dc80: c3aadca4 c3aadc90 c02910f4 c0292500 c02910a0 c390b298 c3aadccc c3aadca8
dca0: c028cb40 c02910b0 c390b078 c390b298 c390b298 00000000 0000000b c2cd45c0
dcc0: c3aadce4 c3aadcd0 c0288f44 c028ca48 c390b078 c2cb9540 c3aadd84 c3aadce8
dce0: c028d7ec c0288f18 00020000 00000000 c026514c c006e5d4 00000000 00000000
dd00: c2cb9540 00000040 00000000 00000000 045e0000 00000000 00000000 00000000
dd20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dd40: 00000000 00000000 00000000 00000000 00000000 00000000 c3aadd84 00a00000
dd60: 00000000 c2cb9540 c39da000 00000238 00000000 c2cd45c0 c3aadd94 c3aadd88
dd80: c028db74 c028d720 c3aaddbc c3aadd98 c0284018 c028db68 c0283fd8 becdd8f0
dda0: c39da000 03be0000 00000000 00020000 c3aadde4 c3aaddc0 c0281648 c0283fe8
ddc0: c028609c becdd8f0 c3aadef8 c2cb9540 c3aac000 c3aac000 c3aadf24 c3aadde8
dde0: c0286b38 c02815d8 c000c5a8 c000b0dc c000b0fc c3aac000 00000000 c2cd45c0
de00: c00497a8 00000000 00000000 c000c594 c3aade64 c3aade50 c03a5978 c0260854
de20: 00000000 c03a5978 c3aade54 c3aade38 c000c5a8 c01dc574 00000003 00000001
de40: c3aade9c c3aade50 c01dc574 c007374c c3aade7c c3aade60 c000c5a8 c000b0dc
de60: c000b0fc 0007ffff 00000000 ffffffff 00000003 00000000 00000001 c3b3a980
de80: c38bba08 000000a4 c3aadec4 c2cf8b80 c3aadeb4 c3aadea0 c01e1c48 c01dc4c8
dea0: c3aadec4 00000000 c3aadf54 c3aadeb8 c01e1d04 c01e1c04 00000000 c03a58c4
dec0: 00000000 00000001 00000000 c38bb830 c34a6500 00000000 00000000 00000000
dee0: 03be0000 00000000 00020000 00000000 00000000 00000000 c3aadef8 c3aadef8
df00: c053e0c0 c38bba00 becdd8f0 40104d14 00000000 00000000 c3aadf44 c3aadf28
df20: c02871f8 c02866e4 becdd8f0 00005452 40104d14 00000003 c3aadf54 c3aadf48
df40: c00eb238 c02871cc c3aadf74 c3aadf58 c00ebf2c c00eb214 c3aadf74 c3aadf68
df60: c38bba00 becdd8f0 c3aadfa4 c3aadf78 c00ebfb0 c00ebd78 c3aadf9c 00000000
df80: c0009f20 becdd958 00013008 00000003 00000036 c00091a8 00000000 c3aadfa8
dfa0: c0008f40 c00ebf60 becdd958 00013008 00000003 40104d14 becdd8f0 00000001
dfc0: becdd958 00013008 00000003 00000036 000001df 00000000 00000008 00000000
dfe0: 00000000 becdd8e0 b6eb4f28 b6e3926c 20000010 00000003 00000001 00000000
Backtrace:
[<c024c828>] (mxs_dma_int_handler+0x0/0x16c) from [<c006e47c>]
(handle_irq_event_percpu+0xc4/0x258)
 r7:c3aadc0c r6:f5000000 r5:00000058 r4:c39c5800
[<c006e3b8>] (handle_irq_event_percpu+0x0/0x258) from [<c006e674>]
(handle_irq_event+0x64/0x84)
[<c006e610>] (handle_irq_event+0x0/0x84) from [<c0071040>]
(handle_level_irq+0xc4/0xf8)
 r5:00000000 r4:c0529058
[<c0070f7c>] (handle_level_irq+0x0/0xf8) from [<c006dcc0>]
(generic_handle_irq+0x30/0x40)
 r4:00000058 r3:c0070f7c
[<c006dc90>] (generic_handle_irq+0x0/0x40) from [<c0009f1c>]
(handle_IRQ+0x70/0x94)
 r4:00000058 r3:00000130
[<c0009eac>] (handle_IRQ+0x0/0x94) from [<c0008648>] (asm_do_IRQ+0x18/0x1c)
 r5:20000013 r4:c024c338
[<c0008630>] (asm_do_IRQ+0x0/0x1c) from [<c03a3894>] (__irq_svc+0x34/0x78)
Exception stack(0xc3aadbd8 to 0xc3aadc20)
dbc0:                                                       00007efa f5004000
dbe0: 00000300 c3811268 c3811294 c3811294 00000000 c3811268 ffffffff 00000000
dc00: 00000000 c3aadc34 f5004000 c3aadc20 c024c32c c024c338 20000013 ffffffff
[<c024c308>] (mxs_dma_tx_submit+0x0/0x44) from [<c0291ad8>]
(start_dma_without_bch_irq+0x4c/0xa0)
 r4:c390b000 r3:c024c308
[<c0291a8c>] (start_dma_without_bch_irq+0x0/0xa0) from [<c0292600>]
(gpmi_send_command+0x110/0x120)
 r6:c390b4dc r5:00000000 r4:c390b000 r3:00000001
[<c02924f0>] (gpmi_send_command+0x0/0x120) from [<c02910f4>]
(gpmi_cmd_ctrl+0x54/0x78)
 r7:c390b078 r6:ffffffff r5:00000070 r4:c390b000
[<c02910a0>] (gpmi_cmd_ctrl+0x0/0x78) from [<c028cb40>]
(nand_command_lp+0x108/0x260)
 r4:c390b298 r3:c02910a0
[<c028ca38>] (nand_command_lp+0x0/0x260) from [<c0288f44>]
(nand_check_wp+0x3c/0x60)
[<c0288f08>] (nand_check_wp+0x0/0x60) from [<c028d7ec>]
(nand_erase_nand+0xdc/0x448)
 r5:c2cb9540 r4:c390b078
[<c028d710>] (nand_erase_nand+0x0/0x448) from [<c028db74>]
(nand_erase+0x1c/0x20)
[<c028db58>] (nand_erase+0x0/0x20) from [<c0284018>] (part_erase+0x40/0x8c)
[<c0283fd8>] (part_erase+0x0/0x8c) from [<c0281648>] (mtd_erase+0x80/0x94)
 r8:00020000 r7:00000000 r6:03be0000 r5:c39da000 r4:becdd8f0
r3:c0283fd8
[<c02815c8>] (mtd_erase+0x0/0x94) from [<c0286b38>] (mtdchar_ioctl+0x464/0xae8)
 r9:c3aac000 r8:c3aac000 r7:c2cb9540 r6:c3aadef8 r4:becdd8f0
r3:c028609c
[<c02866d4>] (mtdchar_ioctl+0x0/0xae8) from [<c02871f8>]
(mtdchar_unlocked_ioctl+0x3c/0x54)
[<c02871bc>] (mtdchar_unlocked_ioctl+0x0/0x54) from [<c00eb238>]
(vfs_ioctl+0x34/0x50)
 r7:00000003 r6:40104d14 r5:00005452 r4:becdd8f0
[<c00eb204>] (vfs_ioctl+0x0/0x50) from [<c00ebf2c>] (do_vfs_ioctl+0x1c4/0x1e8)
[<c00ebd68>] (do_vfs_ioctl+0x0/0x1e8) from [<c00ebfb0>] (sys_ioctl+0x60/0x84)
 r5:becdd8f0 r4:c38bba00
[<c00ebf50>] (sys_ioctl+0x0/0x84) from [<c0008f40>] (ret_fast_syscall+0x0/0x2c)
 r8:c00091a8 r7:00000036 r6:00000003 r5:00013008 r4:becdd958
Code: 1a000006 e59310b4 e3510000 ca000000 (e7f001f2)
28 Kibyte @ 35c0000 -- 2---[ end trace 5deaba3c2a545554 ]---

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Fabio Estevam]

On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi <samgandhi9@gmail.com> wrote:

> I reverted that commit and I still see following  error!

Huang,

Are you able to use gpmi on mx28 running 3.4-rc1?

>
> flash_erase /dev/mtd1 0 0
> Erasing 1------------[ cut here ]------------
> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
> Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
> Modules linked in:
> CPU: 0    Not tainted  (3.4.0-rc1-09876-g2e4bb28-dirty #1)
> PC is at mxs_dma_int_handler+0xfc/0x16c
> LR is at handle_irq_event_percpu+0xc4/0x258
> pc : [<c024c924>]    lr : [<c006e47c>]    psr: 60000093
> sp : c3aadb00  ip : c3aadb28  fp : c3aadb24
> r10: 00000000  r9 : c0529058  r8 : 00000000
> r7 : 00000010  r6 : 00000004  r5 : c3811000  r4 : 00000004
> r3 : c38111e0  r2 : 00000000  r1 : 00000000  r0 : 00000058
> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 0005317f  Table: 42cd8000  DAC: 00000015
> Process flash_erase (pid: 1205, stack limit = 0xc3aac270)
> Stack: (0xc3aadb00 to 0xc3aae000)
> db00: c026514c c006e5d4 c39c5800 00000058 f5000000 c3aadc0c c3aadb64 c3aadb28
> db20: c006e47c c024c838 c3aadb54 c3aadb38 c000c5a8 c000b0dc c000b0fc c0529058
> db40: c39c5800 f5000000 c3aadc0c ffffffff 00000000 00000000 c3aadb7c c3aadb68
> db60: c006e674 c006e3c8 c0529058 00000000 c3aadb94 c3aadb80 c0071040 c006e620
> db80: c0070f7c 00000058 c3aadbac c3aadb98 c006dcc0 c0070f8c 00000130 00000058
> dba0: c3aadbc4 c3aadbb0 c0009f1c c006dca0 c024c338 20000013 c3aadbd4 c3aadbc8
> dbc0: c0008648 c0009ebc c3aadc34 c3aadbd8 c03a3894 c0008640 00007efa f5004000
> dbe0: 00000300 c3811268 c3811294 c3811294 00000000 c3811268 ffffffff 00000000
> dc00: 00000000 c3aadc34 f5004000 c3aadc20 c024c32c c024c338 20000013 ffffffff
> dc20: c024c308 c390b000 c3aadc54 c3aadc38 c0291ad8 c024c318 00000001 c390b000
> dc40: 00000000 c390b4dc c3aadc8c c3aadc58 c0292600 c0291a9c 00000003 00000000
> dc60: 00000006 00830001 00000000 00000000 c390b000 00000070 ffffffff c390b078
> dc80: c3aadca4 c3aadc90 c02910f4 c0292500 c02910a0 c390b298 c3aadccc c3aadca8
> dca0: c028cb40 c02910b0 c390b078 c390b298 c390b298 00000000 0000000b c2cd45c0
> dcc0: c3aadce4 c3aadcd0 c0288f44 c028ca48 c390b078 c2cb9540 c3aadd84 c3aadce8
> dce0: c028d7ec c0288f18 00020000 00000000 c026514c c006e5d4 00000000 00000000
> dd00: c2cb9540 00000040 00000000 00000000 045e0000 00000000 00000000 00000000
> dd20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> dd40: 00000000 00000000 00000000 00000000 00000000 00000000 c3aadd84 00a00000
> dd60: 00000000 c2cb9540 c39da000 00000238 00000000 c2cd45c0 c3aadd94 c3aadd88
> dd80: c028db74 c028d720 c3aaddbc c3aadd98 c0284018 c028db68 c0283fd8 becdd8f0
> dda0: c39da000 03be0000 00000000 00020000 c3aadde4 c3aaddc0 c0281648 c0283fe8
> ddc0: c028609c becdd8f0 c3aadef8 c2cb9540 c3aac000 c3aac000 c3aadf24 c3aadde8
> dde0: c0286b38 c02815d8 c000c5a8 c000b0dc c000b0fc c3aac000 00000000 c2cd45c0
> de00: c00497a8 00000000 00000000 c000c594 c3aade64 c3aade50 c03a5978 c0260854
> de20: 00000000 c03a5978 c3aade54 c3aade38 c000c5a8 c01dc574 00000003 00000001
> de40: c3aade9c c3aade50 c01dc574 c007374c c3aade7c c3aade60 c000c5a8 c000b0dc
> de60: c000b0fc 0007ffff 00000000 ffffffff 00000003 00000000 00000001 c3b3a980
> de80: c38bba08 000000a4 c3aadec4 c2cf8b80 c3aadeb4 c3aadea0 c01e1c48 c01dc4c8
> dea0: c3aadec4 00000000 c3aadf54 c3aadeb8 c01e1d04 c01e1c04 00000000 c03a58c4
> dec0: 00000000 00000001 00000000 c38bb830 c34a6500 00000000 00000000 00000000
> dee0: 03be0000 00000000 00020000 00000000 00000000 00000000 c3aadef8 c3aadef8
> df00: c053e0c0 c38bba00 becdd8f0 40104d14 00000000 00000000 c3aadf44 c3aadf28
> df20: c02871f8 c02866e4 becdd8f0 00005452 40104d14 00000003 c3aadf54 c3aadf48
> df40: c00eb238 c02871cc c3aadf74 c3aadf58 c00ebf2c c00eb214 c3aadf74 c3aadf68
> df60: c38bba00 becdd8f0 c3aadfa4 c3aadf78 c00ebfb0 c00ebd78 c3aadf9c 00000000
> df80: c0009f20 becdd958 00013008 00000003 00000036 c00091a8 00000000 c3aadfa8
> dfa0: c0008f40 c00ebf60 becdd958 00013008 00000003 40104d14 becdd8f0 00000001
> dfc0: becdd958 00013008 00000003 00000036 000001df 00000000 00000008 00000000
> dfe0: 00000000 becdd8e0 b6eb4f28 b6e3926c 20000010 00000003 00000001 00000000
> Backtrace:
> [<c024c828>] (mxs_dma_int_handler+0x0/0x16c) from [<c006e47c>]
> (handle_irq_event_percpu+0xc4/0x258)
>  r7:c3aadc0c r6:f5000000 r5:00000058 r4:c39c5800
> [<c006e3b8>] (handle_irq_event_percpu+0x0/0x258) from [<c006e674>]
> (handle_irq_event+0x64/0x84)
> [<c006e610>] (handle_irq_event+0x0/0x84) from [<c0071040>]
> (handle_level_irq+0xc4/0xf8)
>  r5:00000000 r4:c0529058
> [<c0070f7c>] (handle_level_irq+0x0/0xf8) from [<c006dcc0>]
> (generic_handle_irq+0x30/0x40)
>  r4:00000058 r3:c0070f7c
> [<c006dc90>] (generic_handle_irq+0x0/0x40) from [<c0009f1c>]
> (handle_IRQ+0x70/0x94)
>  r4:00000058 r3:00000130
> [<c0009eac>] (handle_IRQ+0x0/0x94) from [<c0008648>] (asm_do_IRQ+0x18/0x1c)
>  r5:20000013 r4:c024c338
> [<c0008630>] (asm_do_IRQ+0x0/0x1c) from [<c03a3894>] (__irq_svc+0x34/0x78)
> Exception stack(0xc3aadbd8 to 0xc3aadc20)
> dbc0:                                                       00007efa f5004000
> dbe0: 00000300 c3811268 c3811294 c3811294 00000000 c3811268 ffffffff 00000000
> dc00: 00000000 c3aadc34 f5004000 c3aadc20 c024c32c c024c338 20000013 ffffffff
> [<c024c308>] (mxs_dma_tx_submit+0x0/0x44) from [<c0291ad8>]
> (start_dma_without_bch_irq+0x4c/0xa0)
>  r4:c390b000 r3:c024c308
> [<c0291a8c>] (start_dma_without_bch_irq+0x0/0xa0) from [<c0292600>]
> (gpmi_send_command+0x110/0x120)
>  r6:c390b4dc r5:00000000 r4:c390b000 r3:00000001
> [<c02924f0>] (gpmi_send_command+0x0/0x120) from [<c02910f4>]
> (gpmi_cmd_ctrl+0x54/0x78)
>  r7:c390b078 r6:ffffffff r5:00000070 r4:c390b000
> [<c02910a0>] (gpmi_cmd_ctrl+0x0/0x78) from [<c028cb40>]
> (nand_command_lp+0x108/0x260)
>  r4:c390b298 r3:c02910a0
> [<c028ca38>] (nand_command_lp+0x0/0x260) from [<c0288f44>]
> (nand_check_wp+0x3c/0x60)
> [<c0288f08>] (nand_check_wp+0x0/0x60) from [<c028d7ec>]
> (nand_erase_nand+0xdc/0x448)
>  r5:c2cb9540 r4:c390b078
> [<c028d710>] (nand_erase_nand+0x0/0x448) from [<c028db74>]
> (nand_erase+0x1c/0x20)
> [<c028db58>] (nand_erase+0x0/0x20) from [<c0284018>] (part_erase+0x40/0x8c)
> [<c0283fd8>] (part_erase+0x0/0x8c) from [<c0281648>] (mtd_erase+0x80/0x94)
>  r8:00020000 r7:00000000 r6:03be0000 r5:c39da000 r4:becdd8f0
> r3:c0283fd8
> [<c02815c8>] (mtd_erase+0x0/0x94) from [<c0286b38>] (mtdchar_ioctl+0x464/0xae8)
>  r9:c3aac000 r8:c3aac000 r7:c2cb9540 r6:c3aadef8 r4:becdd8f0
> r3:c028609c
> [<c02866d4>] (mtdchar_ioctl+0x0/0xae8) from [<c02871f8>]
> (mtdchar_unlocked_ioctl+0x3c/0x54)
> [<c02871bc>] (mtdchar_unlocked_ioctl+0x0/0x54) from [<c00eb238>]
> (vfs_ioctl+0x34/0x50)
>  r7:00000003 r6:40104d14 r5:00005452 r4:becdd8f0
> [<c00eb204>] (vfs_ioctl+0x0/0x50) from [<c00ebf2c>] (do_vfs_ioctl+0x1c4/0x1e8)
> [<c00ebd68>] (do_vfs_ioctl+0x0/0x1e8) from [<c00ebfb0>] (sys_ioctl+0x60/0x84)
>  r5:becdd8f0 r4:c38bba00
> [<c00ebf50>] (sys_ioctl+0x0/0x84) from [<c0008f40>] (ret_fast_syscall+0x0/0x2c)
>  r8:c00091a8 r7:00000036 r6:00000003 r5:00013008 r4:becdd958
> Code: 1a000006 e59310b4 e3510000 ca000000 (e7f001f2)
> 28 Kibyte @ 35c0000 -- 2---[ end trace 5deaba3c2a545554 ]---

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Huang Shijie]

> Huang,
>
> Are you able to use gpmi on mx28 running 3.4-rc1?
I will test it today.

BR
Huang Shijie
>> >

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Huang Shijie]

Hi All:
> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi<samgandhi9@gmail.com>  wrote:
>
>> I reverted that commit and I still see following  error!
> Huang,
>
> Are you able to use gpmi on mx28 running 3.4-rc1?
>
I also meet the same problem today.


>> flash_erase /dev/mtd1 0 0
>> Erasing 1------------[ cut here ]------------
>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
the mxs-dma has added some patches about the cookie.
The bug is in the dmaengine.h.

So let more people know this bug.

BR
Huang Shijie


>> Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
>> Modules linked in:
>> CPU: 0    Not tainted  (3.4.0-rc1-09876-g2e4bb28-dirty #1)
>> PC is at mxs_dma_int_handler+0xfc/0x16c
>> LR is at handle_irq_event_percpu+0xc4/0x258
>> pc : [<c024c924>]    lr : [<c006e47c>]    psr: 60000093
>> sp : c3aadb00  ip : c3aadb28  fp : c3aadb24
>> r10: 00000000  r9 : c0529058  r8 : 00000000
>> r7 : 00000010  r6 : 00000004  r5 : c3811000  r4 : 00000004
>> r3 : c38111e0  r2 : 00000000  r1 : 00000000  r0 : 00000058
>> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
>> Control: 0005317f  Table: 42cd8000  DAC: 00000015
>> Process flash_erase (pid: 1205, stack limit = 0xc3aac270)
>> Stack: (0xc3aadb00 to 0xc3aae000)
>> db00: c026514c c006e5d4 c39c5800 00000058 f5000000 c3aadc0c c3aadb64 c3aadb28
>> db20: c006e47c c024c838 c3aadb54 c3aadb38 c000c5a8 c000b0dc c000b0fc c0529058
>> db40: c39c5800 f5000000 c3aadc0c ffffffff 00000000 00000000 c3aadb7c c3aadb68
>> db60: c006e674 c006e3c8 c0529058 00000000 c3aadb94 c3aadb80 c0071040 c006e620
>> db80: c0070f7c 00000058 c3aadbac c3aadb98 c006dcc0 c0070f8c 00000130 00000058
>> dba0: c3aadbc4 c3aadbb0 c0009f1c c006dca0 c024c338 20000013 c3aadbd4 c3aadbc8
>> dbc0: c0008648 c0009ebc c3aadc34 c3aadbd8 c03a3894 c0008640 00007efa f5004000
>> dbe0: 00000300 c3811268 c3811294 c3811294 00000000 c3811268 ffffffff 00000000
>> dc00: 00000000 c3aadc34 f5004000 c3aadc20 c024c32c c024c338 20000013 ffffffff
>> dc20: c024c308 c390b000 c3aadc54 c3aadc38 c0291ad8 c024c318 00000001 c390b000
>> dc40: 00000000 c390b4dc c3aadc8c c3aadc58 c0292600 c0291a9c 00000003 00000000
>> dc60: 00000006 00830001 00000000 00000000 c390b000 00000070 ffffffff c390b078
>> dc80: c3aadca4 c3aadc90 c02910f4 c0292500 c02910a0 c390b298 c3aadccc c3aadca8
>> dca0: c028cb40 c02910b0 c390b078 c390b298 c390b298 00000000 0000000b c2cd45c0
>> dcc0: c3aadce4 c3aadcd0 c0288f44 c028ca48 c390b078 c2cb9540 c3aadd84 c3aadce8
>> dce0: c028d7ec c0288f18 00020000 00000000 c026514c c006e5d4 00000000 00000000
>> dd00: c2cb9540 00000040 00000000 00000000 045e0000 00000000 00000000 00000000
>> dd20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> dd40: 00000000 00000000 00000000 00000000 00000000 00000000 c3aadd84 00a00000
>> dd60: 00000000 c2cb9540 c39da000 00000238 00000000 c2cd45c0 c3aadd94 c3aadd88
>> dd80: c028db74 c028d720 c3aaddbc c3aadd98 c0284018 c028db68 c0283fd8 becdd8f0
>> dda0: c39da000 03be0000 00000000 00020000 c3aadde4 c3aaddc0 c0281648 c0283fe8
>> ddc0: c028609c becdd8f0 c3aadef8 c2cb9540 c3aac000 c3aac000 c3aadf24 c3aadde8
>> dde0: c0286b38 c02815d8 c000c5a8 c000b0dc c000b0fc c3aac000 00000000 c2cd45c0
>> de00: c00497a8 00000000 00000000 c000c594 c3aade64 c3aade50 c03a5978 c0260854
>> de20: 00000000 c03a5978 c3aade54 c3aade38 c000c5a8 c01dc574 00000003 00000001
>> de40: c3aade9c c3aade50 c01dc574 c007374c c3aade7c c3aade60 c000c5a8 c000b0dc
>> de60: c000b0fc 0007ffff 00000000 ffffffff 00000003 00000000 00000001 c3b3a980
>> de80: c38bba08 000000a4 c3aadec4 c2cf8b80 c3aadeb4 c3aadea0 c01e1c48 c01dc4c8
>> dea0: c3aadec4 00000000 c3aadf54 c3aadeb8 c01e1d04 c01e1c04 00000000 c03a58c4
>> dec0: 00000000 00000001 00000000 c38bb830 c34a6500 00000000 00000000 00000000
>> dee0: 03be0000 00000000 00020000 00000000 00000000 00000000 c3aadef8 c3aadef8
>> df00: c053e0c0 c38bba00 becdd8f0 40104d14 00000000 00000000 c3aadf44 c3aadf28
>> df20: c02871f8 c02866e4 becdd8f0 00005452 40104d14 00000003 c3aadf54 c3aadf48
>> df40: c00eb238 c02871cc c3aadf74 c3aadf58 c00ebf2c c00eb214 c3aadf74 c3aadf68
>> df60: c38bba00 becdd8f0 c3aadfa4 c3aadf78 c00ebfb0 c00ebd78 c3aadf9c 00000000
>> df80: c0009f20 becdd958 00013008 00000003 00000036 c00091a8 00000000 c3aadfa8
>> dfa0: c0008f40 c00ebf60 becdd958 00013008 00000003 40104d14 becdd8f0 00000001
>> dfc0: becdd958 00013008 00000003 00000036 000001df 00000000 00000008 00000000
>> dfe0: 00000000 becdd8e0 b6eb4f28 b6e3926c 20000010 00000003 00000001 00000000
>> Backtrace:
>> [<c024c828>] (mxs_dma_int_handler+0x0/0x16c) from [<c006e47c>]
>> (handle_irq_event_percpu+0xc4/0x258)
>>   r7:c3aadc0c r6:f5000000 r5:00000058 r4:c39c5800
>> [<c006e3b8>] (handle_irq_event_percpu+0x0/0x258) from [<c006e674>]
>> (handle_irq_event+0x64/0x84)
>> [<c006e610>] (handle_irq_event+0x0/0x84) from [<c0071040>]
>> (handle_level_irq+0xc4/0xf8)
>>   r5:00000000 r4:c0529058
>> [<c0070f7c>] (handle_level_irq+0x0/0xf8) from [<c006dcc0>]
>> (generic_handle_irq+0x30/0x40)
>>   r4:00000058 r3:c0070f7c
>> [<c006dc90>] (generic_handle_irq+0x0/0x40) from [<c0009f1c>]
>> (handle_IRQ+0x70/0x94)
>>   r4:00000058 r3:00000130
>> [<c0009eac>] (handle_IRQ+0x0/0x94) from [<c0008648>] (asm_do_IRQ+0x18/0x1c)
>>   r5:20000013 r4:c024c338
>> [<c0008630>] (asm_do_IRQ+0x0/0x1c) from [<c03a3894>] (__irq_svc+0x34/0x78)
>> Exception stack(0xc3aadbd8 to 0xc3aadc20)
>> dbc0:                                                       00007efa f5004000
>> dbe0: 00000300 c3811268 c3811294 c3811294 00000000 c3811268 ffffffff 00000000
>> dc00: 00000000 c3aadc34 f5004000 c3aadc20 c024c32c c024c338 20000013 ffffffff
>> [<c024c308>] (mxs_dma_tx_submit+0x0/0x44) from [<c0291ad8>]
>> (start_dma_without_bch_irq+0x4c/0xa0)
>>   r4:c390b000 r3:c024c308
>> [<c0291a8c>] (start_dma_without_bch_irq+0x0/0xa0) from [<c0292600>]
>> (gpmi_send_command+0x110/0x120)
>>   r6:c390b4dc r5:00000000 r4:c390b000 r3:00000001
>> [<c02924f0>] (gpmi_send_command+0x0/0x120) from [<c02910f4>]
>> (gpmi_cmd_ctrl+0x54/0x78)
>>   r7:c390b078 r6:ffffffff r5:00000070 r4:c390b000
>> [<c02910a0>] (gpmi_cmd_ctrl+0x0/0x78) from [<c028cb40>]
>> (nand_command_lp+0x108/0x260)
>>   r4:c390b298 r3:c02910a0
>> [<c028ca38>] (nand_command_lp+0x0/0x260) from [<c0288f44>]
>> (nand_check_wp+0x3c/0x60)
>> [<c0288f08>] (nand_check_wp+0x0/0x60) from [<c028d7ec>]
>> (nand_erase_nand+0xdc/0x448)
>>   r5:c2cb9540 r4:c390b078
>> [<c028d710>] (nand_erase_nand+0x0/0x448) from [<c028db74>]
>> (nand_erase+0x1c/0x20)
>> [<c028db58>] (nand_erase+0x0/0x20) from [<c0284018>] (part_erase+0x40/0x8c)
>> [<c0283fd8>] (part_erase+0x0/0x8c) from [<c0281648>] (mtd_erase+0x80/0x94)
>>   r8:00020000 r7:00000000 r6:03be0000 r5:c39da000 r4:becdd8f0
>> r3:c0283fd8
>> [<c02815c8>] (mtd_erase+0x0/0x94) from [<c0286b38>] (mtdchar_ioctl+0x464/0xae8)
>>   r9:c3aac000 r8:c3aac000 r7:c2cb9540 r6:c3aadef8 r4:becdd8f0
>> r3:c028609c
>> [<c02866d4>] (mtdchar_ioctl+0x0/0xae8) from [<c02871f8>]
>> (mtdchar_unlocked_ioctl+0x3c/0x54)
>> [<c02871bc>] (mtdchar_unlocked_ioctl+0x0/0x54) from [<c00eb238>]
>> (vfs_ioctl+0x34/0x50)
>>   r7:00000003 r6:40104d14 r5:00005452 r4:becdd8f0
>> [<c00eb204>] (vfs_ioctl+0x0/0x50) from [<c00ebf2c>] (do_vfs_ioctl+0x1c4/0x1e8)
>> [<c00ebd68>] (do_vfs_ioctl+0x0/0x1e8) from [<c00ebfb0>] (sys_ioctl+0x60/0x84)
>>   r5:becdd8f0 r4:c38bba00
>> [<c00ebf50>] (sys_ioctl+0x0/0x84) from [<c0008f40>] (ret_fast_syscall+0x0/0x2c)
>>   r8:c00091a8 r7:00000036 r6:00000003 r5:00013008 r4:becdd958
>> Code: 1a000006 e59310b4 e3510000 ca000000 (e7f001f2)
>> 28 Kibyte @ 35c0000 -- 2---[ end trace 5deaba3c2a545554 ]---

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Huang Shijie]

Hi All:
> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi<samgandhi9@gmail.com>  wrote:
>
>> I reverted that commit and I still see following  error!
> Huang,
>
> Are you able to use gpmi on mx28 running 3.4-rc1?
>
I also meet the same problem today.


>> flash_erase /dev/mtd1 0 0
>> Erasing 1------------[ cut here ]------------
>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
the mxs-dma has added some patches about the cookie.
The bug is in the dmaengine.h.

So let more people know this bug.

BR
Huang Shijie


>> Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
>> Modules linked in:
>> CPU: 0    Not tainted  (3.4.0-rc1-09876-g2e4bb28-dirty #1)
>> PC is at mxs_dma_int_handler+0xfc/0x16c
>> LR is at handle_irq_event_percpu+0xc4/0x258
>> pc : [<c024c924>]    lr : [<c006e47c>]    psr: 60000093
>> sp : c3aadb00  ip : c3aadb28  fp : c3aadb24
>> r10: 00000000  r9 : c0529058  r8 : 00000000
>> r7 : 00000010  r6 : 00000004  r5 : c3811000  r4 : 00000004
>> r3 : c38111e0  r2 : 00000000  r1 : 00000000  r0 : 00000058
>> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
>> Control: 0005317f  Table: 42cd8000  DAC: 00000015
>> Process flash_erase (pid: 1205, stack limit = 0xc3aac270)
>> Stack: (0xc3aadb00 to 0xc3aae000)
>> db00: c026514c c006e5d4 c39c5800 00000058 f5000000 c3aadc0c c3aadb64 c3aadb28
>> db20: c006e47c c024c838 c3aadb54 c3aadb38 c000c5a8 c000b0dc c000b0fc c0529058
>> db40: c39c5800 f5000000 c3aadc0c ffffffff 00000000 00000000 c3aadb7c c3aadb68
>> db60: c006e674 c006e3c8 c0529058 00000000 c3aadb94 c3aadb80 c0071040 c006e620
>> db80: c0070f7c 00000058 c3aadbac c3aadb98 c006dcc0 c0070f8c 00000130 00000058
>> dba0: c3aadbc4 c3aadbb0 c0009f1c c006dca0 c024c338 20000013 c3aadbd4 c3aadbc8
>> dbc0: c0008648 c0009ebc c3aadc34 c3aadbd8 c03a3894 c0008640 00007efa f5004000
>> dbe0: 00000300 c3811268 c3811294 c3811294 00000000 c3811268 ffffffff 00000000
>> dc00: 00000000 c3aadc34 f5004000 c3aadc20 c024c32c c024c338 20000013 ffffffff
>> dc20: c024c308 c390b000 c3aadc54 c3aadc38 c0291ad8 c024c318 00000001 c390b000
>> dc40: 00000000 c390b4dc c3aadc8c c3aadc58 c0292600 c0291a9c 00000003 00000000
>> dc60: 00000006 00830001 00000000 00000000 c390b000 00000070 ffffffff c390b078
>> dc80: c3aadca4 c3aadc90 c02910f4 c0292500 c02910a0 c390b298 c3aadccc c3aadca8
>> dca0: c028cb40 c02910b0 c390b078 c390b298 c390b298 00000000 0000000b c2cd45c0
>> dcc0: c3aadce4 c3aadcd0 c0288f44 c028ca48 c390b078 c2cb9540 c3aadd84 c3aadce8
>> dce0: c028d7ec c0288f18 00020000 00000000 c026514c c006e5d4 00000000 00000000
>> dd00: c2cb9540 00000040 00000000 00000000 045e0000 00000000 00000000 00000000
>> dd20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> dd40: 00000000 00000000 00000000 00000000 00000000 00000000 c3aadd84 00a00000
>> dd60: 00000000 c2cb9540 c39da000 00000238 00000000 c2cd45c0 c3aadd94 c3aadd88
>> dd80: c028db74 c028d720 c3aaddbc c3aadd98 c0284018 c028db68 c0283fd8 becdd8f0
>> dda0: c39da000 03be0000 00000000 00020000 c3aadde4 c3aaddc0 c0281648 c0283fe8
>> ddc0: c028609c becdd8f0 c3aadef8 c2cb9540 c3aac000 c3aac000 c3aadf24 c3aadde8
>> dde0: c0286b38 c02815d8 c000c5a8 c000b0dc c000b0fc c3aac000 00000000 c2cd45c0
>> de00: c00497a8 00000000 00000000 c000c594 c3aade64 c3aade50 c03a5978 c0260854
>> de20: 00000000 c03a5978 c3aade54 c3aade38 c000c5a8 c01dc574 00000003 00000001
>> de40: c3aade9c c3aade50 c01dc574 c007374c c3aade7c c3aade60 c000c5a8 c000b0dc
>> de60: c000b0fc 0007ffff 00000000 ffffffff 00000003 00000000 00000001 c3b3a980
>> de80: c38bba08 000000a4 c3aadec4 c2cf8b80 c3aadeb4 c3aadea0 c01e1c48 c01dc4c8
>> dea0: c3aadec4 00000000 c3aadf54 c3aadeb8 c01e1d04 c01e1c04 00000000 c03a58c4
>> dec0: 00000000 00000001 00000000 c38bb830 c34a6500 00000000 00000000 00000000
>> dee0: 03be0000 00000000 00020000 00000000 00000000 00000000 c3aadef8 c3aadef8
>> df00: c053e0c0 c38bba00 becdd8f0 40104d14 00000000 00000000 c3aadf44 c3aadf28
>> df20: c02871f8 c02866e4 becdd8f0 00005452 40104d14 00000003 c3aadf54 c3aadf48
>> df40: c00eb238 c02871cc c3aadf74 c3aadf58 c00ebf2c c00eb214 c3aadf74 c3aadf68
>> df60: c38bba00 becdd8f0 c3aadfa4 c3aadf78 c00ebfb0 c00ebd78 c3aadf9c 00000000
>> df80: c0009f20 becdd958 00013008 00000003 00000036 c00091a8 00000000 c3aadfa8
>> dfa0: c0008f40 c00ebf60 becdd958 00013008 00000003 40104d14 becdd8f0 00000001
>> dfc0: becdd958 00013008 00000003 00000036 000001df 00000000 00000008 00000000
>> dfe0: 00000000 becdd8e0 b6eb4f28 b6e3926c 20000010 00000003 00000001 00000000
>> Backtrace:
>> [<c024c828>] (mxs_dma_int_handler+0x0/0x16c) from [<c006e47c>]
>> (handle_irq_event_percpu+0xc4/0x258)
>>   r7:c3aadc0c r6:f5000000 r5:00000058 r4:c39c5800
>> [<c006e3b8>] (handle_irq_event_percpu+0x0/0x258) from [<c006e674>]
>> (handle_irq_event+0x64/0x84)
>> [<c006e610>] (handle_irq_event+0x0/0x84) from [<c0071040>]
>> (handle_level_irq+0xc4/0xf8)
>>   r5:00000000 r4:c0529058
>> [<c0070f7c>] (handle_level_irq+0x0/0xf8) from [<c006dcc0>]
>> (generic_handle_irq+0x30/0x40)
>>   r4:00000058 r3:c0070f7c
>> [<c006dc90>] (generic_handle_irq+0x0/0x40) from [<c0009f1c>]
>> (handle_IRQ+0x70/0x94)
>>   r4:00000058 r3:00000130
>> [<c0009eac>] (handle_IRQ+0x0/0x94) from [<c0008648>] (asm_do_IRQ+0x18/0x1c)
>>   r5:20000013 r4:c024c338
>> [<c0008630>] (asm_do_IRQ+0x0/0x1c) from [<c03a3894>] (__irq_svc+0x34/0x78)
>> Exception stack(0xc3aadbd8 to 0xc3aadc20)
>> dbc0:                                                       00007efa f5004000
>> dbe0: 00000300 c3811268 c3811294 c3811294 00000000 c3811268 ffffffff 00000000
>> dc00: 00000000 c3aadc34 f5004000 c3aadc20 c024c32c c024c338 20000013 ffffffff
>> [<c024c308>] (mxs_dma_tx_submit+0x0/0x44) from [<c0291ad8>]
>> (start_dma_without_bch_irq+0x4c/0xa0)
>>   r4:c390b000 r3:c024c308
>> [<c0291a8c>] (start_dma_without_bch_irq+0x0/0xa0) from [<c0292600>]
>> (gpmi_send_command+0x110/0x120)
>>   r6:c390b4dc r5:00000000 r4:c390b000 r3:00000001
>> [<c02924f0>] (gpmi_send_command+0x0/0x120) from [<c02910f4>]
>> (gpmi_cmd_ctrl+0x54/0x78)
>>   r7:c390b078 r6:ffffffff r5:00000070 r4:c390b000
>> [<c02910a0>] (gpmi_cmd_ctrl+0x0/0x78) from [<c028cb40>]
>> (nand_command_lp+0x108/0x260)
>>   r4:c390b298 r3:c02910a0
>> [<c028ca38>] (nand_command_lp+0x0/0x260) from [<c0288f44>]
>> (nand_check_wp+0x3c/0x60)
>> [<c0288f08>] (nand_check_wp+0x0/0x60) from [<c028d7ec>]
>> (nand_erase_nand+0xdc/0x448)
>>   r5:c2cb9540 r4:c390b078
>> [<c028d710>] (nand_erase_nand+0x0/0x448) from [<c028db74>]
>> (nand_erase+0x1c/0x20)
>> [<c028db58>] (nand_erase+0x0/0x20) from [<c0284018>] (part_erase+0x40/0x8c)
>> [<c0283fd8>] (part_erase+0x0/0x8c) from [<c0281648>] (mtd_erase+0x80/0x94)
>>   r8:00020000 r7:00000000 r6:03be0000 r5:c39da000 r4:becdd8f0
>> r3:c0283fd8
>> [<c02815c8>] (mtd_erase+0x0/0x94) from [<c0286b38>] (mtdchar_ioctl+0x464/0xae8)
>>   r9:c3aac000 r8:c3aac000 r7:c2cb9540 r6:c3aadef8 r4:becdd8f0
>> r3:c028609c
>> [<c02866d4>] (mtdchar_ioctl+0x0/0xae8) from [<c02871f8>]
>> (mtdchar_unlocked_ioctl+0x3c/0x54)
>> [<c02871bc>] (mtdchar_unlocked_ioctl+0x0/0x54) from [<c00eb238>]
>> (vfs_ioctl+0x34/0x50)
>>   r7:00000003 r6:40104d14 r5:00005452 r4:becdd8f0
>> [<c00eb204>] (vfs_ioctl+0x0/0x50) from [<c00ebf2c>] (do_vfs_ioctl+0x1c4/0x1e8)
>> [<c00ebd68>] (do_vfs_ioctl+0x0/0x1e8) from [<c00ebfb0>] (sys_ioctl+0x60/0x84)
>>   r5:becdd8f0 r4:c38bba00
>> [<c00ebf50>] (sys_ioctl+0x0/0x84) from [<c0008f40>] (ret_fast_syscall+0x0/0x2c)
>>   r8:c00091a8 r7:00000036 r6:00000003 r5:00013008 r4:becdd958
>> Code: 1a000006 e59310b4 e3510000 ca000000 (e7f001f2)
>> 28 Kibyte @ 35c0000 -- 2---[ end trace 5deaba3c2a545554 ]---

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

2012/4/4 Huang Shijie <b32955@freescale.com>:
> Hi All:
>> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi<samgandhi9@gmail.com>  wrote:
>>
>>> I reverted that commit and I still see following  error!
>> Huang,
>>
>> Are you able to use gpmi on mx28 running 3.4-rc1?
>>
> I also meet the same problem today.
>
>
>>> flash_erase /dev/mtd1 0 0
>>> Erasing 1------------[ cut here ]------------
>>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
> the mxs-dma has added some patches about the cookie.
> The bug is in the dmaengine.h.
>
> So let more people know this bug.
>
> BR
> Huang Shijie
>
>
FWIW, Just a data point.

I coverted BUG_ON in dmaengine.h to printk as shown below. With this
change I was able to format nand, create UBI partition. I have been
running UBI torture test called integck on my board that does lot of
I/O, mounting/unmounting of filesystem for close to 8 hour now without
crash. But I do see those printks. I haven't followed logic of
tx->cookie well enough to figure out what the appropriate change
should be. Note this is with commit
00292bbf769620dea923dbd906afd88955f7ea19 reverted in my tree.

Cookie 0  completed 102118268 DMA_MIN 1
Cookie 0  completed 102120401 DMA_MIN 1
Cookie 0  completed 102237726 DMA_MIN 1

git diff drivers/dma/dmaengine.h
diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
index 17f983a..3d10a70 100644
--- a/drivers/dma/dmaengine.h
+++ b/drivers/dma/dmaengine.h
@@ -50,7 +50,11 @@ static inline dma_cookie_t dma_cookie_assign(struct
dma_async_tx_descriptor *tx)
  */
 static inline void dma_cookie_complete(struct dma_async_tx_descriptor *tx)
 {
-       BUG_ON(tx->cookie < DMA_MIN_COOKIE);
+       if ( tx->cookie < DMA_MIN_COOKIE)
+               printk(KERN_ERR "Cookie %d,  completed %d DMA_MIN %d
",tx->cookie,
+               tx->chan->completed_cookie,
+               DMA_MIN_COOKIE);
+       /* BUG_ON(tx->cookie < DMA_MIN_COOKIE); */
        tx->chan->completed_cookie = tx->cookie;
        tx->cookie = 0;
 }

Regards,
-Sam

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

2012/4/4 Huang Shijie <b32955@freescale.com>:
> Hi All:
>> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi<samgandhi9@gmail.com> ?wrote:
>>
>>> I reverted that commit and I still see following ?error!
>> Huang,
>>
>> Are you able to use gpmi on mx28 running 3.4-rc1?
>>
> I also meet the same problem today.
>
>
>>> flash_erase /dev/mtd1 0 0
>>> Erasing 1------------[ cut here ]------------
>>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
> the mxs-dma has added some patches about the cookie.
> The bug is in the dmaengine.h.
>
> So let more people know this bug.
>
> BR
> Huang Shijie
>
>
FWIW, Just a data point.

I coverted BUG_ON in dmaengine.h to printk as shown below. With this
change I was able to format nand, create UBI partition. I have been
running UBI torture test called integck on my board that does lot of
I/O, mounting/unmounting of filesystem for close to 8 hour now without
crash. But I do see those printks. I haven't followed logic of
tx->cookie well enough to figure out what the appropriate change
should be. Note this is with commit
00292bbf769620dea923dbd906afd88955f7ea19 reverted in my tree.

Cookie 0  completed 102118268 DMA_MIN 1
Cookie 0  completed 102120401 DMA_MIN 1
Cookie 0  completed 102237726 DMA_MIN 1

git diff drivers/dma/dmaengine.h
diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
index 17f983a..3d10a70 100644
--- a/drivers/dma/dmaengine.h
+++ b/drivers/dma/dmaengine.h
@@ -50,7 +50,11 @@ static inline dma_cookie_t dma_cookie_assign(struct
dma_async_tx_descriptor *tx)
  */
 static inline void dma_cookie_complete(struct dma_async_tx_descriptor *tx)
 {
-       BUG_ON(tx->cookie < DMA_MIN_COOKIE);
+       if ( tx->cookie < DMA_MIN_COOKIE)
+               printk(KERN_ERR "Cookie %d,  completed %d DMA_MIN %d
",tx->cookie,
+               tx->chan->completed_cookie,
+               DMA_MIN_COOKIE);
+       /* BUG_ON(tx->cookie < DMA_MIN_COOKIE); */
        tx->chan->completed_cookie = tx->cookie;
        tx->cookie = 0;
 }

Regards,
-Sam

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Vinod Koul]

On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote:
> 2012/4/4 Huang Shijie <b32955@freescale.com>:
> > Hi All:
> >> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi<samgandhi9@gmail.com>  wrote:
> >>
> >>> I reverted that commit and I still see following  error!
> >> Huang,
> >>
> >> Are you able to use gpmi on mx28 running 3.4-rc1?
> >>
> > I also meet the same problem today.
> >
> >
> >>> flash_erase /dev/mtd1 0 0
> >>> Erasing 1------------[ cut here ]------------
> >>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
> > the mxs-dma has added some patches about the cookie.
> > The bug is in the dmaengine.h.
> >
> > So let more people know this bug.
> >
> > BR
> > Huang Shijie
> >
> >
> FWIW, Just a data point.
> 
> I coverted BUG_ON in dmaengine.h to printk as shown below. With this
> change I was able to format nand, create UBI partition. I have been
> running UBI torture test called integck on my board that does lot of
> I/O, mounting/unmounting of filesystem for close to 8 hour now without
> crash. But I do see those printks. I haven't followed logic of
> tx->cookie well enough to figure out what the appropriate change
> should be. Note this is with commit
> 00292bbf769620dea923dbd906afd88955f7ea19 reverted in my tree.
> 
> Cookie 0  completed 102118268 DMA_MIN 1
> Cookie 0  completed 102120401 DMA_MIN 1
> Cookie 0  completed 102237726 DMA_MIN 1
> 
> git diff drivers/dma/dmaengine.h
> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
> index 17f983a..3d10a70 100644
> --- a/drivers/dma/dmaengine.h
> +++ b/drivers/dma/dmaengine.h
> @@ -50,7 +50,11 @@ static inline dma_cookie_t dma_cookie_assign(struct
> dma_async_tx_descriptor *tx)
>   */
>  static inline void dma_cookie_complete(struct dma_async_tx_descriptor *tx)
>  {
> -       BUG_ON(tx->cookie < DMA_MIN_COOKIE);
> +       if ( tx->cookie < DMA_MIN_COOKIE)
> +               printk(KERN_ERR "Cookie %d,  completed %d DMA_MIN %d
> ",tx->cookie,
> +               tx->chan->completed_cookie,
> +               DMA_MIN_COOKIE);
> +       /* BUG_ON(tx->cookie < DMA_MIN_COOKIE); */
>         tx->chan->completed_cookie = tx->cookie;
>         tx->cookie = 0;
>  }
This means you are trying to mark a cookie complete when it is already
marked so!, hence dmaengine screams.
The bug is is mxs-dma.
Let me know if below fixes it (assuming you are not using cyclic API,
that would need fixup as well)

diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index c81ef7e..5ddd84e 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor
*mxs_dma_prep_slave_sg(
 		ccw->bits &= ~CCW_DEC_SEM;
 	} else {
 		idx = 0;
+		/* assign cookie here,
+		 * hopefully for above case we dont need it
+		 */
+		dma_cookie_assign(&mxs_chan->desc);
 	}
 
 	if (direction == DMA_TRANS_NONE) {

-- 
~Vinod

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Vinod Koul]

On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote:
> 2012/4/4 Huang Shijie <b32955@freescale.com>:
> > Hi All:
> >> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi<samgandhi9@gmail.com>  wrote:
> >>
> >>> I reverted that commit and I still see following  error!
> >> Huang,
> >>
> >> Are you able to use gpmi on mx28 running 3.4-rc1?
> >>
> > I also meet the same problem today.
> >
> >
> >>> flash_erase /dev/mtd1 0 0
> >>> Erasing 1------------[ cut here ]------------
> >>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
> > the mxs-dma has added some patches about the cookie.
> > The bug is in the dmaengine.h.
> >
> > So let more people know this bug.
> >
> > BR
> > Huang Shijie
> >
> >
> FWIW, Just a data point.
> 
> I coverted BUG_ON in dmaengine.h to printk as shown below. With this
> change I was able to format nand, create UBI partition. I have been
> running UBI torture test called integck on my board that does lot of
> I/O, mounting/unmounting of filesystem for close to 8 hour now without
> crash. But I do see those printks. I haven't followed logic of
> tx->cookie well enough to figure out what the appropriate change
> should be. Note this is with commit
> 00292bbf769620dea923dbd906afd88955f7ea19 reverted in my tree.
> 
> Cookie 0  completed 102118268 DMA_MIN 1
> Cookie 0  completed 102120401 DMA_MIN 1
> Cookie 0  completed 102237726 DMA_MIN 1
> 
> git diff drivers/dma/dmaengine.h
> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
> index 17f983a..3d10a70 100644
> --- a/drivers/dma/dmaengine.h
> +++ b/drivers/dma/dmaengine.h
> @@ -50,7 +50,11 @@ static inline dma_cookie_t dma_cookie_assign(struct
> dma_async_tx_descriptor *tx)
>   */
>  static inline void dma_cookie_complete(struct dma_async_tx_descriptor *tx)
>  {
> -       BUG_ON(tx->cookie < DMA_MIN_COOKIE);
> +       if ( tx->cookie < DMA_MIN_COOKIE)
> +               printk(KERN_ERR "Cookie %d,  completed %d DMA_MIN %d
> ",tx->cookie,
> +               tx->chan->completed_cookie,
> +               DMA_MIN_COOKIE);
> +       /* BUG_ON(tx->cookie < DMA_MIN_COOKIE); */
>         tx->chan->completed_cookie = tx->cookie;
>         tx->cookie = 0;
>  }
This means you are trying to mark a cookie complete when it is already
marked so!, hence dmaengine screams.
The bug is is mxs-dma.
Let me know if below fixes it (assuming you are not using cyclic API,
that would need fixup as well)

diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index c81ef7e..5ddd84e 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor
*mxs_dma_prep_slave_sg(
 		ccw->bits &= ~CCW_DEC_SEM;
 	} else {
 		idx = 0;
+		/* assign cookie here,
+		 * hopefully for above case we dont need it
+		 */
+		dma_cookie_assign(&mxs_chan->desc);
 	}
 
 	if (direction == DMA_TRANS_NONE) {

-- 
~Vinod

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

Vinod,

On Thu, Apr 5, 2012 at 5:27 AM, Vinod Koul <vinod.koul@linux.intel.com> wrote:
> On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote:
>> 2012/4/4 Huang Shijie <b32955@freescale.com>:
>> > Hi All:
>> >> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi<samgandhi9@gmail.com>  wrote:
>> >>
>> >>> I reverted that commit and I still see following  error!
>> >> Huang,
>> >>
>> >> Are you able to use gpmi on mx28 running 3.4-rc1?
>> >>
>> > I also meet the same problem today.
>> >
>> >
>> >>> flash_erase /dev/mtd1 0 0
>> >>> Erasing 1------------[ cut here ]------------
>> >>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
>> > the mxs-dma has added some patches about the cookie.
>> > The bug is in the dmaengine.h.
>> >
>> > So let more people know this bug.
>> >
>> > BR
>> > Huang Shijie
>> >
>> >
>> FWIW, Just a data point.
>>
>> I coverted BUG_ON in dmaengine.h to printk as shown below. With this
>> change I was able to format nand, create UBI partition. I have been
>> running UBI torture test called integck on my board that does lot of
>> I/O, mounting/unmounting of filesystem for close to 8 hour now without
>> crash. But I do see those printks. I haven't followed logic of
>> tx->cookie well enough to figure out what the appropriate change
>> should be. Note this is with commit
>> 00292bbf769620dea923dbd906afd88955f7ea19 reverted in my tree.
>>
>> Cookie 0  completed 102118268 DMA_MIN 1
>> Cookie 0  completed 102120401 DMA_MIN 1
>> Cookie 0  completed 102237726 DMA_MIN 1
>>
>> git diff drivers/dma/dmaengine.h
>> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
>> index 17f983a..3d10a70 100644
>> --- a/drivers/dma/dmaengine.h
>> +++ b/drivers/dma/dmaengine.h
>> @@ -50,7 +50,11 @@ static inline dma_cookie_t dma_cookie_assign(struct
>> dma_async_tx_descriptor *tx)
>>   */
>>  static inline void dma_cookie_complete(struct dma_async_tx_descriptor *tx)
>>  {
>> -       BUG_ON(tx->cookie < DMA_MIN_COOKIE);
>> +       if ( tx->cookie < DMA_MIN_COOKIE)
>> +               printk(KERN_ERR "Cookie %d,  completed %d DMA_MIN %d
>> ",tx->cookie,
>> +               tx->chan->completed_cookie,
>> +               DMA_MIN_COOKIE);
>> +       /* BUG_ON(tx->cookie < DMA_MIN_COOKIE); */
>>         tx->chan->completed_cookie = tx->cookie;
>>         tx->cookie = 0;
>>  }
> This means you are trying to mark a cookie complete when it is already
> marked so!, hence dmaengine screams.
> The bug is is mxs-dma.
> Let me know if below fixes it (assuming you are not using cyclic API,
> that would need fixup as well)
>
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index c81ef7e..5ddd84e 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor
> *mxs_dma_prep_slave_sg(
>                ccw->bits &= ~CCW_DEC_SEM;
>        } else {
>                idx = 0;
> +               /* assign cookie here,
> +                * hopefully for above case we dont need it
> +                */
> +               dma_cookie_assign(&mxs_chan->desc);
>        }
>
>        if (direction == DMA_TRANS_NONE) {
>
I applied your suggested change and don't hit the BUG_ON in
dmaengine.h with this change UBI torture test has run for last 30 min
or so I will let it run for a day. [ I will let mxs-dma authors
comment if this is a right change.. ]

-Sam

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

Vinod,

On Thu, Apr 5, 2012 at 5:27 AM, Vinod Koul <vinod.koul@linux.intel.com> wrote:
> On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote:
>> 2012/4/4 Huang Shijie <b32955@freescale.com>:
>> > Hi All:
>> >> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi<samgandhi9@gmail.com> ?wrote:
>> >>
>> >>> I reverted that commit and I still see following ?error!
>> >> Huang,
>> >>
>> >> Are you able to use gpmi on mx28 running 3.4-rc1?
>> >>
>> > I also meet the same problem today.
>> >
>> >
>> >>> flash_erase /dev/mtd1 0 0
>> >>> Erasing 1------------[ cut here ]------------
>> >>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
>> > the mxs-dma has added some patches about the cookie.
>> > The bug is in the dmaengine.h.
>> >
>> > So let more people know this bug.
>> >
>> > BR
>> > Huang Shijie
>> >
>> >
>> FWIW, Just a data point.
>>
>> I coverted BUG_ON in dmaengine.h to printk as shown below. With this
>> change I was able to format nand, create UBI partition. I have been
>> running UBI torture test called integck on my board that does lot of
>> I/O, mounting/unmounting of filesystem for close to 8 hour now without
>> crash. But I do see those printks. I haven't followed logic of
>> tx->cookie well enough to figure out what the appropriate change
>> should be. Note this is with commit
>> 00292bbf769620dea923dbd906afd88955f7ea19 reverted in my tree.
>>
>> Cookie 0 ?completed 102118268 DMA_MIN 1
>> Cookie 0 ?completed 102120401 DMA_MIN 1
>> Cookie 0 ?completed 102237726 DMA_MIN 1
>>
>> git diff drivers/dma/dmaengine.h
>> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
>> index 17f983a..3d10a70 100644
>> --- a/drivers/dma/dmaengine.h
>> +++ b/drivers/dma/dmaengine.h
>> @@ -50,7 +50,11 @@ static inline dma_cookie_t dma_cookie_assign(struct
>> dma_async_tx_descriptor *tx)
>> ? */
>> ?static inline void dma_cookie_complete(struct dma_async_tx_descriptor *tx)
>> ?{
>> - ? ? ? BUG_ON(tx->cookie < DMA_MIN_COOKIE);
>> + ? ? ? if ( tx->cookie < DMA_MIN_COOKIE)
>> + ? ? ? ? ? ? ? printk(KERN_ERR "Cookie %d, ?completed %d DMA_MIN %d
>> ",tx->cookie,
>> + ? ? ? ? ? ? ? tx->chan->completed_cookie,
>> + ? ? ? ? ? ? ? DMA_MIN_COOKIE);
>> + ? ? ? /* BUG_ON(tx->cookie < DMA_MIN_COOKIE); */
>> ? ? ? ? tx->chan->completed_cookie = tx->cookie;
>> ? ? ? ? tx->cookie = 0;
>> ?}
> This means you are trying to mark a cookie complete when it is already
> marked so!, hence dmaengine screams.
> The bug is is mxs-dma.
> Let me know if below fixes it (assuming you are not using cyclic API,
> that would need fixup as well)
>
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index c81ef7e..5ddd84e 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor
> *mxs_dma_prep_slave_sg(
> ? ? ? ? ? ? ? ?ccw->bits &= ~CCW_DEC_SEM;
> ? ? ? ?} else {
> ? ? ? ? ? ? ? ?idx = 0;
> + ? ? ? ? ? ? ? /* assign cookie here,
> + ? ? ? ? ? ? ? ?* hopefully for above case we dont need it
> + ? ? ? ? ? ? ? ?*/
> + ? ? ? ? ? ? ? dma_cookie_assign(&mxs_chan->desc);
> ? ? ? ?}
>
> ? ? ? ?if (direction == DMA_TRANS_NONE) {
>
I applied your suggested change and don't hit the BUG_ON in
dmaengine.h with this change UBI torture test has run for last 30 min
or so I will let it run for a day. [ I will let mxs-dma authors
comment if this is a right change.. ]

-Sam

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Vinod Koul]

On Thu, 2012-04-05 at 06:02 -0700, Sam Gandhi wrote:
> Vinod,
> 
> On Thu, Apr 5, 2012 at 5:27 AM, Vinod Koul <vinod.koul@linux.intel.com> wrote:
> > On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote:
> >> 2012/4/4 Huang Shijie <b32955@freescale.com>:
> >> > Hi All:
> >> >> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi<samgandhi9@gmail.com>  wrote:
> >> >>
> >> >>> I reverted that commit and I still see following  error!
> >> >> Huang,
> >> >>
> >> >> Are you able to use gpmi on mx28 running 3.4-rc1?
> >> >>
> >> > I also meet the same problem today.
> >> >
> >> >
> >> >>> flash_erase /dev/mtd1 0 0
> >> >>> Erasing 1------------[ cut here ]------------
> >> >>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
> >> > the mxs-dma has added some patches about the cookie.
> >> > The bug is in the dmaengine.h.
> >> >
> >> > So let more people know this bug.
> >> >
> >> > BR
> >> > Huang Shijie
> >> >
> >> >
> >> FWIW, Just a data point.
> >>
> >> I coverted BUG_ON in dmaengine.h to printk as shown below. With this
> >> change I was able to format nand, create UBI partition. I have been
> >> running UBI torture test called integck on my board that does lot of
> >> I/O, mounting/unmounting of filesystem for close to 8 hour now without
> >> crash. But I do see those printks. I haven't followed logic of
> >> tx->cookie well enough to figure out what the appropriate change
> >> should be. Note this is with commit
> >> 00292bbf769620dea923dbd906afd88955f7ea19 reverted in my tree.
> >>
> >> Cookie 0  completed 102118268 DMA_MIN 1
> >> Cookie 0  completed 102120401 DMA_MIN 1
> >> Cookie 0  completed 102237726 DMA_MIN 1
> >>
> >> git diff drivers/dma/dmaengine.h
> >> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
> >> index 17f983a..3d10a70 100644
> >> --- a/drivers/dma/dmaengine.h
> >> +++ b/drivers/dma/dmaengine.h
> >> @@ -50,7 +50,11 @@ static inline dma_cookie_t dma_cookie_assign(struct
> >> dma_async_tx_descriptor *tx)
> >>   */
> >>  static inline void dma_cookie_complete(struct dma_async_tx_descriptor *tx)
> >>  {
> >> -       BUG_ON(tx->cookie < DMA_MIN_COOKIE);
> >> +       if ( tx->cookie < DMA_MIN_COOKIE)
> >> +               printk(KERN_ERR "Cookie %d,  completed %d DMA_MIN %d
> >> ",tx->cookie,
> >> +               tx->chan->completed_cookie,
> >> +               DMA_MIN_COOKIE);
> >> +       /* BUG_ON(tx->cookie < DMA_MIN_COOKIE); */
> >>         tx->chan->completed_cookie = tx->cookie;
> >>         tx->cookie = 0;
> >>  }
> > This means you are trying to mark a cookie complete when it is already
> > marked so!, hence dmaengine screams.
> > The bug is is mxs-dma.
> > Let me know if below fixes it (assuming you are not using cyclic API,
> > that would need fixup as well)
> >
> > diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> > index c81ef7e..5ddd84e 100644
> > --- a/drivers/dma/mxs-dma.c
> > +++ b/drivers/dma/mxs-dma.c
> > @@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor
> > *mxs_dma_prep_slave_sg(
> >                ccw->bits &= ~CCW_DEC_SEM;
> >        } else {
> >                idx = 0;
> > +               /* assign cookie here,
> > +                * hopefully for above case we dont need it
> > +                */
> > +               dma_cookie_assign(&mxs_chan->desc);
> >        }
> >
> >        if (direction == DMA_TRANS_NONE) {
> >
> I applied your suggested change and don't hit the BUG_ON in
> dmaengine.h with this change UBI torture test has run for last 30 min
> or so I will let it run for a day. [ I will let mxs-dma authors
> comment if this is a right change.. ]
Good I will apply this and send to Linus.
Care to give your tested-by.


-- 
~Vinod

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Vinod Koul]

On Thu, 2012-04-05 at 06:02 -0700, Sam Gandhi wrote:
> Vinod,
> 
> On Thu, Apr 5, 2012 at 5:27 AM, Vinod Koul <vinod.koul@linux.intel.com> wrote:
> > On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote:
> >> 2012/4/4 Huang Shijie <b32955@freescale.com>:
> >> > Hi All:
> >> >> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi<samgandhi9@gmail.com>  wrote:
> >> >>
> >> >>> I reverted that commit and I still see following  error!
> >> >> Huang,
> >> >>
> >> >> Are you able to use gpmi on mx28 running 3.4-rc1?
> >> >>
> >> > I also meet the same problem today.
> >> >
> >> >
> >> >>> flash_erase /dev/mtd1 0 0
> >> >>> Erasing 1------------[ cut here ]------------
> >> >>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
> >> > the mxs-dma has added some patches about the cookie.
> >> > The bug is in the dmaengine.h.
> >> >
> >> > So let more people know this bug.
> >> >
> >> > BR
> >> > Huang Shijie
> >> >
> >> >
> >> FWIW, Just a data point.
> >>
> >> I coverted BUG_ON in dmaengine.h to printk as shown below. With this
> >> change I was able to format nand, create UBI partition. I have been
> >> running UBI torture test called integck on my board that does lot of
> >> I/O, mounting/unmounting of filesystem for close to 8 hour now without
> >> crash. But I do see those printks. I haven't followed logic of
> >> tx->cookie well enough to figure out what the appropriate change
> >> should be. Note this is with commit
> >> 00292bbf769620dea923dbd906afd88955f7ea19 reverted in my tree.
> >>
> >> Cookie 0  completed 102118268 DMA_MIN 1
> >> Cookie 0  completed 102120401 DMA_MIN 1
> >> Cookie 0  completed 102237726 DMA_MIN 1
> >>
> >> git diff drivers/dma/dmaengine.h
> >> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
> >> index 17f983a..3d10a70 100644
> >> --- a/drivers/dma/dmaengine.h
> >> +++ b/drivers/dma/dmaengine.h
> >> @@ -50,7 +50,11 @@ static inline dma_cookie_t dma_cookie_assign(struct
> >> dma_async_tx_descriptor *tx)
> >>   */
> >>  static inline void dma_cookie_complete(struct dma_async_tx_descriptor *tx)
> >>  {
> >> -       BUG_ON(tx->cookie < DMA_MIN_COOKIE);
> >> +       if ( tx->cookie < DMA_MIN_COOKIE)
> >> +               printk(KERN_ERR "Cookie %d,  completed %d DMA_MIN %d
> >> ",tx->cookie,
> >> +               tx->chan->completed_cookie,
> >> +               DMA_MIN_COOKIE);
> >> +       /* BUG_ON(tx->cookie < DMA_MIN_COOKIE); */
> >>         tx->chan->completed_cookie = tx->cookie;
> >>         tx->cookie = 0;
> >>  }
> > This means you are trying to mark a cookie complete when it is already
> > marked so!, hence dmaengine screams.
> > The bug is is mxs-dma.
> > Let me know if below fixes it (assuming you are not using cyclic API,
> > that would need fixup as well)
> >
> > diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> > index c81ef7e..5ddd84e 100644
> > --- a/drivers/dma/mxs-dma.c
> > +++ b/drivers/dma/mxs-dma.c
> > @@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor
> > *mxs_dma_prep_slave_sg(
> >                ccw->bits &= ~CCW_DEC_SEM;
> >        } else {
> >                idx = 0;
> > +               /* assign cookie here,
> > +                * hopefully for above case we dont need it
> > +                */
> > +               dma_cookie_assign(&mxs_chan->desc);
> >        }
> >
> >        if (direction == DMA_TRANS_NONE) {
> >
> I applied your suggested change and don't hit the BUG_ON in
> dmaengine.h with this change UBI torture test has run for last 30 min
> or so I will let it run for a day. [ I will let mxs-dma authors
> comment if this is a right change.. ]
Good I will apply this and send to Linus.
Care to give your tested-by.


-- 
~Vinod

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

On Thu, Apr 5, 2012 at 6:48 AM, Vinod Koul <vinod.koul@linux.intel.com> wrote:
> On Thu, 2012-04-05 at 06:02 -0700, Sam Gandhi wrote:
>> Vinod,
>>
>> On Thu, Apr 5, 2012 at 5:27 AM, Vinod Koul <vinod.koul@linux.intel.com> wrote:
>> > On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote:
>> >> 2012/4/4 Huang Shijie <b32955@freescale.com>:
>> >> > Hi All:
>> >> >> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi<samgandhi9@gmail.com>  wrote:
>> >> >>
>> >> >>> I reverted that commit and I still see following  error!
>> >> >> Huang,
>> >> >>
>> >> >> Are you able to use gpmi on mx28 running 3.4-rc1?
>> >> >>
>> >> > I also meet the same problem today.
>> >> >
>> >> >
>> >> >>> flash_erase /dev/mtd1 0 0
>> >> >>> Erasing 1------------[ cut here ]------------
>> >> >>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
>> >> > the mxs-dma has added some patches about the cookie.
>> >> > The bug is in the dmaengine.h.
>> >> >
>> >> > So let more people know this bug.
>> >> >
>> >> > BR
>> >> > Huang Shijie
>> >> >
>> >> >
>> >> FWIW, Just a data point.
>> >>
>> >> I coverted BUG_ON in dmaengine.h to printk as shown below. With this
>> >> change I was able to format nand, create UBI partition. I have been
>> >> running UBI torture test called integck on my board that does lot of
>> >> I/O, mounting/unmounting of filesystem for close to 8 hour now without
>> >> crash. But I do see those printks. I haven't followed logic of
>> >> tx->cookie well enough to figure out what the appropriate change
>> >> should be. Note this is with commit
>> >> 00292bbf769620dea923dbd906afd88955f7ea19 reverted in my tree.
>> >>
>> >> Cookie 0  completed 102118268 DMA_MIN 1
>> >> Cookie 0  completed 102120401 DMA_MIN 1
>> >> Cookie 0  completed 102237726 DMA_MIN 1
>> >>
>> >> git diff drivers/dma/dmaengine.h
>> >> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
>> >> index 17f983a..3d10a70 100644
>> >> --- a/drivers/dma/dmaengine.h
>> >> +++ b/drivers/dma/dmaengine.h
>> >> @@ -50,7 +50,11 @@ static inline dma_cookie_t dma_cookie_assign(struct
>> >> dma_async_tx_descriptor *tx)
>> >>   */
>> >>  static inline void dma_cookie_complete(struct dma_async_tx_descriptor *tx)
>> >>  {
>> >> -       BUG_ON(tx->cookie < DMA_MIN_COOKIE);
>> >> +       if ( tx->cookie < DMA_MIN_COOKIE)
>> >> +               printk(KERN_ERR "Cookie %d,  completed %d DMA_MIN %d
>> >> ",tx->cookie,
>> >> +               tx->chan->completed_cookie,
>> >> +               DMA_MIN_COOKIE);
>> >> +       /* BUG_ON(tx->cookie < DMA_MIN_COOKIE); */
>> >>         tx->chan->completed_cookie = tx->cookie;
>> >>         tx->cookie = 0;
>> >>  }
>> > This means you are trying to mark a cookie complete when it is already
>> > marked so!, hence dmaengine screams.
>> > The bug is is mxs-dma.
>> > Let me know if below fixes it (assuming you are not using cyclic API,
>> > that would need fixup as well)
>> >
>> > diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
>> > index c81ef7e..5ddd84e 100644
>> > --- a/drivers/dma/mxs-dma.c
>> > +++ b/drivers/dma/mxs-dma.c
>> > @@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor
>> > *mxs_dma_prep_slave_sg(
>> >                ccw->bits &= ~CCW_DEC_SEM;
>> >        } else {
>> >                idx = 0;
>> > +               /* assign cookie here,
>> > +                * hopefully for above case we dont need it
>> > +                */
>> > +               dma_cookie_assign(&mxs_chan->desc);
>> >        }
>> >
>> >        if (direction == DMA_TRANS_NONE) {
>> >
>> I applied your suggested change and don't hit the BUG_ON in
>> dmaengine.h with this change UBI torture test has run for last 30 min
>> or so I will let it run for a day. [ I will let mxs-dma authors
>> comment if this is a right change.. ]
> Good I will apply this and send to Linus.
> Care to give your tested-by.

Sure.

-Sam (samgandhi9@gmail.com )

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

On Thu, Apr 5, 2012 at 6:48 AM, Vinod Koul <vinod.koul@linux.intel.com> wrote:
> On Thu, 2012-04-05 at 06:02 -0700, Sam Gandhi wrote:
>> Vinod,
>>
>> On Thu, Apr 5, 2012 at 5:27 AM, Vinod Koul <vinod.koul@linux.intel.com> wrote:
>> > On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote:
>> >> 2012/4/4 Huang Shijie <b32955@freescale.com>:
>> >> > Hi All:
>> >> >> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi<samgandhi9@gmail.com> ?wrote:
>> >> >>
>> >> >>> I reverted that commit and I still see following ?error!
>> >> >> Huang,
>> >> >>
>> >> >> Are you able to use gpmi on mx28 running 3.4-rc1?
>> >> >>
>> >> > I also meet the same problem today.
>> >> >
>> >> >
>> >> >>> flash_erase /dev/mtd1 0 0
>> >> >>> Erasing 1------------[ cut here ]------------
>> >> >>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
>> >> > the mxs-dma has added some patches about the cookie.
>> >> > The bug is in the dmaengine.h.
>> >> >
>> >> > So let more people know this bug.
>> >> >
>> >> > BR
>> >> > Huang Shijie
>> >> >
>> >> >
>> >> FWIW, Just a data point.
>> >>
>> >> I coverted BUG_ON in dmaengine.h to printk as shown below. With this
>> >> change I was able to format nand, create UBI partition. I have been
>> >> running UBI torture test called integck on my board that does lot of
>> >> I/O, mounting/unmounting of filesystem for close to 8 hour now without
>> >> crash. But I do see those printks. I haven't followed logic of
>> >> tx->cookie well enough to figure out what the appropriate change
>> >> should be. Note this is with commit
>> >> 00292bbf769620dea923dbd906afd88955f7ea19 reverted in my tree.
>> >>
>> >> Cookie 0 ?completed 102118268 DMA_MIN 1
>> >> Cookie 0 ?completed 102120401 DMA_MIN 1
>> >> Cookie 0 ?completed 102237726 DMA_MIN 1
>> >>
>> >> git diff drivers/dma/dmaengine.h
>> >> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
>> >> index 17f983a..3d10a70 100644
>> >> --- a/drivers/dma/dmaengine.h
>> >> +++ b/drivers/dma/dmaengine.h
>> >> @@ -50,7 +50,11 @@ static inline dma_cookie_t dma_cookie_assign(struct
>> >> dma_async_tx_descriptor *tx)
>> >> ? */
>> >> ?static inline void dma_cookie_complete(struct dma_async_tx_descriptor *tx)
>> >> ?{
>> >> - ? ? ? BUG_ON(tx->cookie < DMA_MIN_COOKIE);
>> >> + ? ? ? if ( tx->cookie < DMA_MIN_COOKIE)
>> >> + ? ? ? ? ? ? ? printk(KERN_ERR "Cookie %d, ?completed %d DMA_MIN %d
>> >> ",tx->cookie,
>> >> + ? ? ? ? ? ? ? tx->chan->completed_cookie,
>> >> + ? ? ? ? ? ? ? DMA_MIN_COOKIE);
>> >> + ? ? ? /* BUG_ON(tx->cookie < DMA_MIN_COOKIE); */
>> >> ? ? ? ? tx->chan->completed_cookie = tx->cookie;
>> >> ? ? ? ? tx->cookie = 0;
>> >> ?}
>> > This means you are trying to mark a cookie complete when it is already
>> > marked so!, hence dmaengine screams.
>> > The bug is is mxs-dma.
>> > Let me know if below fixes it (assuming you are not using cyclic API,
>> > that would need fixup as well)
>> >
>> > diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
>> > index c81ef7e..5ddd84e 100644
>> > --- a/drivers/dma/mxs-dma.c
>> > +++ b/drivers/dma/mxs-dma.c
>> > @@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor
>> > *mxs_dma_prep_slave_sg(
>> > ? ? ? ? ? ? ? ?ccw->bits &= ~CCW_DEC_SEM;
>> > ? ? ? ?} else {
>> > ? ? ? ? ? ? ? ?idx = 0;
>> > + ? ? ? ? ? ? ? /* assign cookie here,
>> > + ? ? ? ? ? ? ? ?* hopefully for above case we dont need it
>> > + ? ? ? ? ? ? ? ?*/
>> > + ? ? ? ? ? ? ? dma_cookie_assign(&mxs_chan->desc);
>> > ? ? ? ?}
>> >
>> > ? ? ? ?if (direction == DMA_TRANS_NONE) {
>> >
>> I applied your suggested change and don't hit the BUG_ON in
>> dmaengine.h with this change UBI torture test has run for last 30 min
>> or so I will let it run for a day. [ I will let mxs-dma authors
>> comment if this is a right change.. ]
> Good I will apply this and send to Linus.
> Care to give your tested-by.

Sure.

-Sam (samgandhi9 at gmail.com )

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Shawn Guo]

On Thu, Apr 05, 2012 at 05:57:41PM +0530, Vinod Koul wrote:
> On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote:
> > 2012/4/4 Huang Shijie <b32955@freescale.com>:
...
> > >>> flash_erase /dev/mtd1 0 0
> > >>> Erasing 1------------[ cut here ]------------
> > >>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
> > > the mxs-dma has added some patches about the cookie.
> > > The bug is in the dmaengine.h.
> > >
> > > So let more people know this bug.
> > >

I'm still trying to understand why I did run into the BUG_ON when I
test it with mxs mmc and sound drivers.

...

> This means you are trying to mark a cookie complete when it is already
> marked so!, hence dmaengine screams.
> The bug is is mxs-dma.
> Let me know if below fixes it (assuming you are not using cyclic API,
> that would need fixup as well)
> 
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index c81ef7e..5ddd84e 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor
> *mxs_dma_prep_slave_sg(
>  		ccw->bits &= ~CCW_DEC_SEM;
>  	} else {
>  		idx = 0;
> +		/* assign cookie here,
> +		 * hopefully for above case we dont need it
> +		 */
> +		dma_cookie_assign(&mxs_chan->desc);

Isn't it done in mxs_dma_tx_submit() already? The gpmi driver somehow
misses the call to dmaengine_submit() for some case?

Regards,
Shawn

>  	}
>  
>  	if (direction == DMA_TRANS_NONE) {
> 
> -- 

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Shawn Guo]

On Thu, Apr 05, 2012 at 05:57:41PM +0530, Vinod Koul wrote:
> On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote:
> > 2012/4/4 Huang Shijie <b32955@freescale.com>:
...
> > >>> flash_erase /dev/mtd1 0 0
> > >>> Erasing 1------------[ cut here ]------------
> > >>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
> > > the mxs-dma has added some patches about the cookie.
> > > The bug is in the dmaengine.h.
> > >
> > > So let more people know this bug.
> > >

I'm still trying to understand why I did run into the BUG_ON when I
test it with mxs mmc and sound drivers.

...

> This means you are trying to mark a cookie complete when it is already
> marked so!, hence dmaengine screams.
> The bug is is mxs-dma.
> Let me know if below fixes it (assuming you are not using cyclic API,
> that would need fixup as well)
> 
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index c81ef7e..5ddd84e 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor
> *mxs_dma_prep_slave_sg(
>  		ccw->bits &= ~CCW_DEC_SEM;
>  	} else {
>  		idx = 0;
> +		/* assign cookie here,
> +		 * hopefully for above case we dont need it
> +		 */
> +		dma_cookie_assign(&mxs_chan->desc);

Isn't it done in mxs_dma_tx_submit() already? The gpmi driver somehow
misses the call to dmaengine_submit() for some case?

Regards,
Shawn

>  	}
>  
>  	if (direction == DMA_TRANS_NONE) {
> 
> -- 

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Huang Shijie]

hi,
> Isn't it done in mxs_dma_tx_submit() already? The gpmi driver somehow
> misses the call to dmaengine_submit() for some case?
>
I checked the code again. It seems I do not miss the call to 
dmaengine_submit().

There are five places where call the dmaengine_submit() by 
start_dma_with_bch_irq()/start_dma_without_bch_irq():
         gpmi_send_command(),gpmi_send_data(),gpmi_read_data(), 
gpmi_send_page(), gpmi_read_page().

The gpmi nand code runs well in previous mxs-dma code.

BR
Huang Shijie

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Huang Shijie]

hi,
> Isn't it done in mxs_dma_tx_submit() already? The gpmi driver somehow
> misses the call to dmaengine_submit() for some case?
>
I checked the code again. It seems I do not miss the call to 
dmaengine_submit().

There are five places where call the dmaengine_submit() by 
start_dma_with_bch_irq()/start_dma_without_bch_irq():
         gpmi_send_command(),gpmi_send_data(),gpmi_read_data(), 
gpmi_send_page(), gpmi_read_page().

The gpmi nand code runs well in previous mxs-dma code.

BR
Huang Shijie

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Shawn Guo]

On Fri, Apr 06, 2012 at 10:45:07AM +0800, Huang Shijie wrote:
> hi,
> >Isn't it done in mxs_dma_tx_submit() already? The gpmi driver somehow
> >misses the call to dmaengine_submit() for some case?
> >
> I checked the code again. It seems I do not miss the call to
> dmaengine_submit().
> 
I do not have nand device to play.  Maybe you want to have a check
if dma_cookie_assign (dmaengine_submit) and dma_cookie_complete
(via mxs_dma_int_handler) are being called as a pair for gpmi.

-- 
Regards,
Shawn

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Shawn Guo]

On Fri, Apr 06, 2012 at 10:45:07AM +0800, Huang Shijie wrote:
> hi,
> >Isn't it done in mxs_dma_tx_submit() already? The gpmi driver somehow
> >misses the call to dmaengine_submit() for some case?
> >
> I checked the code again. It seems I do not miss the call to
> dmaengine_submit().
> 
I do not have nand device to play.  Maybe you want to have a check
if dma_cookie_assign (dmaengine_submit) and dma_cookie_complete
(via mxs_dma_int_handler) are being called as a pair for gpmi.

-- 
Regards,
Shawn

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Huang Shijie]

于 2012年04月06日 10:23, Shawn Guo 写道:
> On Thu, Apr 05, 2012 at 05:57:41PM +0530, Vinod Koul wrote:
>> On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote:
>>> 2012/4/4 Huang Shijie<b32955@freescale.com>:
> ...
>>>>>> flash_erase /dev/mtd1 0 0
>>>>>> Erasing 1------------[ cut here ]------------
>>>>>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
>>>> the mxs-dma has added some patches about the cookie.
>>>> The bug is in the dmaengine.h.
>>>>
>>>> So let more people know this bug.
>>>>
> I'm still trying to understand why I did run into the BUG_ON when I
> test it with mxs mmc and sound drivers.
>
> ...
>
>> This means you are trying to mark a cookie complete when it is already
>> marked so!, hence dmaengine screams.
>> The bug is is mxs-dma.
>> Let me know if below fixes it (assuming you are not using cyclic API,
>> that would need fixup as well)
>>
>> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
>> index c81ef7e..5ddd84e 100644
>> --- a/drivers/dma/mxs-dma.c
>> +++ b/drivers/dma/mxs-dma.c
>> @@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor
>> *mxs_dma_prep_slave_sg(
>>   		ccw->bits&= ~CCW_DEC_SEM;
>>   	} else {
>>   		idx = 0;
>> +		/* assign cookie here,
>> +		 * hopefully for above case we dont need it
>> +		 */
>> +		dma_cookie_assign(&mxs_chan->desc);
> Isn't it done in mxs_dma_tx_submit() already? The gpmi driver somehow

It's maybe too late to assign the DMA cookie after mxs_dma_enable_chan() 
in mxs_dma_tx_submit().
The interrupt may arise before the dma_cookie_assign() finishes.

Why mmc/audio do not have this bug? their interrupt arise too slow.

I tested the following code :
==============================================================

diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index 5978113..0f5b09a 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct 
dma_cha
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);
+ dma_cookie_t c;

+ c = dma_cookie_assign(tx);
mxs_dma_enable_chan(mxs_chan);

- return dma_cookie_assign(tx);
+ return c;
}

static void mxs_dma_tasklet(unsigned long data)


> misses the call to dmaengine_submit() for some case?
>
> Regards,
> Shawn
>
>>   	}
>>
>>   	if (direction == DMA_TRANS_NONE) {
>>
>> -- 

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Huang Shijie]

? 2012?04?06? 10:23, Shawn Guo ??:
> On Thu, Apr 05, 2012 at 05:57:41PM +0530, Vinod Koul wrote:
>> On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote:
>>> 2012/4/4 Huang Shijie<b32955@freescale.com>:
> ...
>>>>>> flash_erase /dev/mtd1 0 0
>>>>>> Erasing 1------------[ cut here ]------------
>>>>>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53!
>>>> the mxs-dma has added some patches about the cookie.
>>>> The bug is in the dmaengine.h.
>>>>
>>>> So let more people know this bug.
>>>>
> I'm still trying to understand why I did run into the BUG_ON when I
> test it with mxs mmc and sound drivers.
>
> ...
>
>> This means you are trying to mark a cookie complete when it is already
>> marked so!, hence dmaengine screams.
>> The bug is is mxs-dma.
>> Let me know if below fixes it (assuming you are not using cyclic API,
>> that would need fixup as well)
>>
>> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
>> index c81ef7e..5ddd84e 100644
>> --- a/drivers/dma/mxs-dma.c
>> +++ b/drivers/dma/mxs-dma.c
>> @@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor
>> *mxs_dma_prep_slave_sg(
>>   		ccw->bits&= ~CCW_DEC_SEM;
>>   	} else {
>>   		idx = 0;
>> +		/* assign cookie here,
>> +		 * hopefully for above case we dont need it
>> +		 */
>> +		dma_cookie_assign(&mxs_chan->desc);
> Isn't it done in mxs_dma_tx_submit() already? The gpmi driver somehow

It's maybe too late to assign the DMA cookie after mxs_dma_enable_chan() 
in mxs_dma_tx_submit().
The interrupt may arise before the dma_cookie_assign() finishes.

Why mmc/audio do not have this bug? their interrupt arise too slow.

I tested the following code :
==============================================================

diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index 5978113..0f5b09a 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct 
dma_cha
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);
+ dma_cookie_t c;

+ c = dma_cookie_assign(tx);
mxs_dma_enable_chan(mxs_chan);

- return dma_cookie_assign(tx);
+ return c;
}

static void mxs_dma_tasklet(unsigned long data)


> misses the call to dmaengine_submit() for some case?
>
> Regards,
> Shawn
>
>>   	}
>>
>>   	if (direction == DMA_TRANS_NONE) {
>>
>> -- 

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Shawn Guo]

On Fri, Apr 06, 2012 at 06:34:23PM +0800, Huang Shijie wrote:
...
> It's maybe too late to assign the DMA cookie after
> mxs_dma_enable_chan() in mxs_dma_tx_submit().
> The interrupt may arise before the dma_cookie_assign() finishes.
> 
> Why mmc/audio do not have this bug? their interrupt arise too slow.
> 
> I tested the following code :

Great.  Send a formal patch to Vinod?

Regards,
Shawn

> ==============================================================
> 
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index 5978113..0f5b09a 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -202,10 +202,12 @@ static struct mxs_dma_chan
> *to_mxs_dma_chan(struct dma_cha
> 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);
> + dma_cookie_t c;
> 
> + c = dma_cookie_assign(tx);
> mxs_dma_enable_chan(mxs_chan);
> 
> - return dma_cookie_assign(tx);
> + return c;
> }
> 
> static void mxs_dma_tasklet(unsigned long data)
> 

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Shawn Guo]

On Fri, Apr 06, 2012 at 06:34:23PM +0800, Huang Shijie wrote:
...
> It's maybe too late to assign the DMA cookie after
> mxs_dma_enable_chan() in mxs_dma_tx_submit().
> The interrupt may arise before the dma_cookie_assign() finishes.
> 
> Why mmc/audio do not have this bug? their interrupt arise too slow.
> 
> I tested the following code :

Great.  Send a formal patch to Vinod?

Regards,
Shawn

> ==============================================================
> 
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index 5978113..0f5b09a 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -202,10 +202,12 @@ static struct mxs_dma_chan
> *to_mxs_dma_chan(struct dma_cha
> 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);
> + dma_cookie_t c;
> 
> + c = dma_cookie_assign(tx);
> mxs_dma_enable_chan(mxs_chan);
> 
> - return dma_cookie_assign(tx);
> + return c;
> }
> 
> static void mxs_dma_tasklet(unsigned long data)
> 

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

>
>
> It's maybe too late to assign the DMA cookie after mxs_dma_enable_chan() in
> mxs_dma_tx_submit().
> The interrupt may arise before the dma_cookie_assign() finishes.
>
> Why mmc/audio do not have this bug? their interrupt arise too slow.
>
> I tested the following code :
> ==============================================================
>
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index 5978113..0f5b09a 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct
> dma_cha
> 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);
> + dma_cookie_t c;
>
> + c = dma_cookie_assign(tx);
> mxs_dma_enable_chan(mxs_chan);
>
> - return dma_cookie_assign(tx);
> + return c;
> }
>
If this is the issue, then why not have mxs_dma_enable_chan itself
call dma_cookie_assign() and return that cookie.

That way mxs_dma_enable_chan() is self contained function that assign
the cookie, enables channel and returns assigned cookie. And nobody
will make mistake of calling just mxs_dma_enable_chan without first
calling dma_cookie_assign?

-Sam

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

>
>
> It's maybe too late to assign the DMA cookie after mxs_dma_enable_chan() in
> mxs_dma_tx_submit().
> The interrupt may arise before the dma_cookie_assign() finishes.
>
> Why mmc/audio do not have this bug? their interrupt arise too slow.
>
> I tested the following code :
> ==============================================================
>
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index 5978113..0f5b09a 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct
> dma_cha
> 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);
> + dma_cookie_t c;
>
> + c = dma_cookie_assign(tx);
> mxs_dma_enable_chan(mxs_chan);
>
> - return dma_cookie_assign(tx);
> + return c;
> }
>
If this is the issue, then why not have mxs_dma_enable_chan itself
call dma_cookie_assign() and return that cookie.

That way mxs_dma_enable_chan() is self contained function that assign
the cookie, enables channel and returns assigned cookie. And nobody
will make mistake of calling just mxs_dma_enable_chan without first
calling dma_cookie_assign?

-Sam

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Shawn Guo]

On Fri, Apr 06, 2012 at 06:49:05AM -0700, Sam Gandhi wrote:
> >
> >
> > It's maybe too late to assign the DMA cookie after mxs_dma_enable_chan() in
> > mxs_dma_tx_submit().
> > The interrupt may arise before the dma_cookie_assign() finishes.
> >
> > Why mmc/audio do not have this bug? their interrupt arise too slow.
> >
> > I tested the following code :
> > ==============================================================
> >
> > diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> > index 5978113..0f5b09a 100644
> > --- a/drivers/dma/mxs-dma.c
> > +++ b/drivers/dma/mxs-dma.c
> > @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct
> > dma_cha
> > 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);
> > + dma_cookie_t c;
> >
> > + c = dma_cookie_assign(tx);
> > mxs_dma_enable_chan(mxs_chan);
> >
> > - return dma_cookie_assign(tx);
> > + return c;
> > }
> >
> If this is the issue, then why not have mxs_dma_enable_chan itself
> call dma_cookie_assign() and return that cookie.
> 
As the function name tells, mxs_dma_enable_chan is to only operate dma
hardware to enable the channel but nothing else.

> That way mxs_dma_enable_chan() is self contained function that assign
> the cookie, enables channel and returns assigned cookie. And nobody
> will make mistake of calling just mxs_dma_enable_chan without first
> calling dma_cookie_assign?
> 
mxs_dma_enable_chan() is a mxs-dma private call.  Nobody but only
mxs-dma driver itself can call it.

-- 
Regards,
Shawn

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Shawn Guo]

On Fri, Apr 06, 2012 at 06:49:05AM -0700, Sam Gandhi wrote:
> >
> >
> > It's maybe too late to assign the DMA cookie after mxs_dma_enable_chan() in
> > mxs_dma_tx_submit().
> > The interrupt may arise before the dma_cookie_assign() finishes.
> >
> > Why mmc/audio do not have this bug? their interrupt arise too slow.
> >
> > I tested the following code :
> > ==============================================================
> >
> > diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> > index 5978113..0f5b09a 100644
> > --- a/drivers/dma/mxs-dma.c
> > +++ b/drivers/dma/mxs-dma.c
> > @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct
> > dma_cha
> > 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);
> > + dma_cookie_t c;
> >
> > + c = dma_cookie_assign(tx);
> > mxs_dma_enable_chan(mxs_chan);
> >
> > - return dma_cookie_assign(tx);
> > + return c;
> > }
> >
> If this is the issue, then why not have mxs_dma_enable_chan itself
> call dma_cookie_assign() and return that cookie.
> 
As the function name tells, mxs_dma_enable_chan is to only operate dma
hardware to enable the channel but nothing else.

> That way mxs_dma_enable_chan() is self contained function that assign
> the cookie, enables channel and returns assigned cookie. And nobody
> will make mistake of calling just mxs_dma_enable_chan without first
> calling dma_cookie_assign?
> 
mxs_dma_enable_chan() is a mxs-dma private call.  Nobody but only
mxs-dma driver itself can call it.

-- 
Regards,
Shawn

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

On Fri, Apr 6, 2012 at 6:59 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Fri, Apr 06, 2012 at 06:49:05AM -0700, Sam Gandhi wrote:
>> >
>> >
>> > It's maybe too late to assign the DMA cookie after mxs_dma_enable_chan() in
>> > mxs_dma_tx_submit().
>> > The interrupt may arise before the dma_cookie_assign() finishes.
>> >
>> > Why mmc/audio do not have this bug? their interrupt arise too slow.
>> >
>> > I tested the following code :
>> > ==============================================================
>> >
>> > diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
>> > index 5978113..0f5b09a 100644
>> > --- a/drivers/dma/mxs-dma.c
>> > +++ b/drivers/dma/mxs-dma.c
>> > @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct
>> > dma_cha
>> > 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);
>> > + dma_cookie_t c;
>> >
>> > + c = dma_cookie_assign(tx);
>> > mxs_dma_enable_chan(mxs_chan);
>> >
>> > - return dma_cookie_assign(tx);
>> > + return c;
>> > }
>> >
>> If this is the issue, then why not have mxs_dma_enable_chan itself
>> call dma_cookie_assign() and return that cookie.
>>
> As the function name tells, mxs_dma_enable_chan is to only operate dma
> hardware to enable the channel but nothing else.
>
Well then change the name of the function
mxs_assign_cookie_enable_chan(), my point still stands.

As the case illustrates  cookie needs to assigned before enabling the
channel then why not do it in that function itself. At worst please
put a comment in mxs_assign_cookie_enable() that says cookie must be
assigned prior to calling enable channel.

-Sam

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

On Fri, Apr 6, 2012 at 6:59 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Fri, Apr 06, 2012 at 06:49:05AM -0700, Sam Gandhi wrote:
>> >
>> >
>> > It's maybe too late to assign the DMA cookie after mxs_dma_enable_chan() in
>> > mxs_dma_tx_submit().
>> > The interrupt may arise before the dma_cookie_assign() finishes.
>> >
>> > Why mmc/audio do not have this bug? their interrupt arise too slow.
>> >
>> > I tested the following code :
>> > ==============================================================
>> >
>> > diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
>> > index 5978113..0f5b09a 100644
>> > --- a/drivers/dma/mxs-dma.c
>> > +++ b/drivers/dma/mxs-dma.c
>> > @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct
>> > dma_cha
>> > 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);
>> > + dma_cookie_t c;
>> >
>> > + c = dma_cookie_assign(tx);
>> > mxs_dma_enable_chan(mxs_chan);
>> >
>> > - return dma_cookie_assign(tx);
>> > + return c;
>> > }
>> >
>> If this is the issue, then why not have mxs_dma_enable_chan itself
>> call dma_cookie_assign() and return that cookie.
>>
> As the function name tells, mxs_dma_enable_chan is to only operate dma
> hardware to enable the channel but nothing else.
>
Well then change the name of the function
mxs_assign_cookie_enable_chan(), my point still stands.

As the case illustrates  cookie needs to assigned before enabling the
channel then why not do it in that function itself. At worst please
put a comment in mxs_assign_cookie_enable() that says cookie must be
assigned prior to calling enable channel.

-Sam

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Shawn Guo]

On Fri, Apr 06, 2012 at 07:06:41AM -0700, Sam Gandhi wrote:
...
> Well then change the name of the function
> mxs_assign_cookie_enable_chan(), my point still stands.
> 
I just do not see the need of such churn.

> As the case illustrates  cookie needs to assigned before enabling the
> channel then why not do it in that function itself.

It's simply because cookie is cookie and channel is channel.

> At worst please
> put a comment in mxs_assign_cookie_enable() that says cookie must be
> assigned prior to calling enable channel.
> 
It's the best rather than worst to me. 

-- 
Regards,
Shawn

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Shawn Guo]

On Fri, Apr 06, 2012 at 07:06:41AM -0700, Sam Gandhi wrote:
...
> Well then change the name of the function
> mxs_assign_cookie_enable_chan(), my point still stands.
> 
I just do not see the need of such churn.

> As the case illustrates  cookie needs to assigned before enabling the
> channel then why not do it in that function itself.

It's simply because cookie is cookie and channel is channel.

> At worst please
> put a comment in mxs_assign_cookie_enable() that says cookie must be
> assigned prior to calling enable channel.
> 
It's the best rather than worst to me. 

-- 
Regards,
Shawn

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

> I tested the following code :
> ==============================================================
>
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index 5978113..0f5b09a 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct
> dma_cha
> 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);
> + dma_cookie_t c;
>
> + c = dma_cookie_assign(tx);
> mxs_dma_enable_chan(mxs_chan);
>
> - return dma_cookie_assign(tx);
> + return c;
> }
>
> static void mxs_dma_tasklet(unsigned long data)
>
>
Ack on testing.

I reverted the change that Vinod had suggested earlier, and applied
Huang's suggested change and it fixed the issue. Successfully erased
NAND, made UBI partitions and ran integck tests for several hours.

-Sam

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Sam Gandhi]

> I tested the following code :
> ==============================================================
>
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index 5978113..0f5b09a 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct
> dma_cha
> 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);
> + dma_cookie_t c;
>
> + c = dma_cookie_assign(tx);
> mxs_dma_enable_chan(mxs_chan);
>
> - return dma_cookie_assign(tx);
> + return c;
> }
>
> static void mxs_dma_tasklet(unsigned long data)
>
>
Ack on testing.

I reverted the change that Vinod had suggested earlier, and applied
Huang's suggested change and it fixed the issue. Successfully erased
NAND, made UBI partitions and ran integck tests for several hours.

-Sam

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Russell King - ARM Linux]

On Fri, Apr 06, 2012 at 06:34:23PM +0800, Huang Shijie wrote:
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index 5978113..0f5b09a 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct  
> dma_cha
> 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);
> + dma_cookie_t c;
>
> + c = dma_cookie_assign(tx);
> mxs_dma_enable_chan(mxs_chan);
>
> - return dma_cookie_assign(tx);
> + return c;

Hang on, why are you enabling a channel (and presumably allowing this
transaction to be issued) before dma_async_issue_pending() has been
called for the channel?

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Russell King - ARM Linux]

On Fri, Apr 06, 2012 at 06:34:23PM +0800, Huang Shijie wrote:
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index 5978113..0f5b09a 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct  
> dma_cha
> 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);
> + dma_cookie_t c;
>
> + c = dma_cookie_assign(tx);
> mxs_dma_enable_chan(mxs_chan);
>
> - return dma_cookie_assign(tx);
> + return c;

Hang on, why are you enabling a channel (and presumably allowing this
transaction to be issued) before dma_async_issue_pending() has been
called for the channel?

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Shawn Guo]

On Tue, Apr 10, 2012 at 10:42:23AM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 06, 2012 at 06:34:23PM +0800, Huang Shijie wrote:
> > diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> > index 5978113..0f5b09a 100644
> > --- a/drivers/dma/mxs-dma.c
> > +++ b/drivers/dma/mxs-dma.c
> > @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct  
> > dma_cha
> > 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);
> > + dma_cookie_t c;
> >
> > + c = dma_cookie_assign(tx);
> > mxs_dma_enable_chan(mxs_chan);
> >
> > - return dma_cookie_assign(tx);
> > + return c;
> 
> Hang on, why are you enabling a channel (and presumably allowing this
> transaction to be issued) before dma_async_issue_pending() has been
> called for the channel?

When mxs-dma driver was created, we chose to only support a single
descriptor at the beginning, and mxs_dma_issue_pending() is an empty
function right now .  This is something needs to be improved, but it
should be orthogonal to the bug fix posted here.

-- 
Regards,
Shawn

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Shawn Guo]

On Tue, Apr 10, 2012 at 10:42:23AM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 06, 2012 at 06:34:23PM +0800, Huang Shijie wrote:
> > diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> > index 5978113..0f5b09a 100644
> > --- a/drivers/dma/mxs-dma.c
> > +++ b/drivers/dma/mxs-dma.c
> > @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct  
> > dma_cha
> > 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);
> > + dma_cookie_t c;
> >
> > + c = dma_cookie_assign(tx);
> > mxs_dma_enable_chan(mxs_chan);
> >
> > - return dma_cookie_assign(tx);
> > + return c;
> 
> Hang on, why are you enabling a channel (and presumably allowing this
> transaction to be issued) before dma_async_issue_pending() has been
> called for the channel?

When mxs-dma driver was created, we chose to only support a single
descriptor at the beginning, and mxs_dma_issue_pending() is an empty
function right now .  This is something needs to be improved, but it
should be orthogonal to the bug fix posted here.

-- 
Regards,
Shawn

Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Russell King - ARM Linux]

On Tue, Apr 10, 2012 at 08:39:58PM +0800, Shawn Guo wrote:
> When mxs-dma driver was created, we chose to only support a single
> descriptor at the beginning, and mxs_dma_issue_pending() is an empty
> function right now .  This is something needs to be improved, but it
> should be orthogonal to the bug fix posted here.

You could view it as being the reason that the bug occurred, because
had the issue_pending() function been used to start the transfer,
things would naturally happen in the right order.

So, one solution to the bug would be to do exactly that - move the
channel enable to the issue pending function, which will have the
same effect as reversing the order of cookie assignment and channel
enable.

However, the risk is that because you have a no-op issue_pending(),
some of your drivers may have decided its not worth calling and omitted
it.

Using GPMI-NAND driver on iMX28 using 3.4-rc1?

[Russell King - ARM Linux]

On Tue, Apr 10, 2012 at 08:39:58PM +0800, Shawn Guo wrote:
> When mxs-dma driver was created, we chose to only support a single
> descriptor at the beginning, and mxs_dma_issue_pending() is an empty
> function right now .  This is something needs to be improved, but it
> should be orthogonal to the bug fix posted here.

You could view it as being the reason that the bug occurred, because
had the issue_pending() function been used to start the transfer,
things would naturally happen in the right order.

So, one solution to the bug would be to do exactly that - move the
channel enable to the issue pending function, which will have the
same effect as reversing the order of cookie assignment and channel
enable.

However, the risk is that because you have a no-op issue_pending(),
some of your drivers may have decided its not worth calling and omitted
it.