This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

  • TI Thinks Resolved

Linux/AM5728: GPMC EDMA causes kernel panic (kernel version 4.1.13)

Prodigy 180 points

Replies: 15

Views: 458

Part Number: AM5728

Tool/software: Linux

We have an FPGA that interfaces with our AM5728 over GPMC. The FPGA instructs the AM5728 that is has data ready via a GPIO interrupt. Our driver seems to be successfully setting up the DMA transaction triggered on the interrupt (I can see the printks outlined below). However, after issuing the DMA request, it looks like the kernel panics because of the L3 interconnect. and it can't finish the DMA transaction The following is the kernel trace that we're seeing:

t@am57xx-phycore-rdk:~# [  324.976807 ] MO MO MO got interrupt
[  324.980228 ] hs_gpmc_irq_handler: Going to start DMA transaction
[  324.986173 ] MO MO MO: Prepped slave single
[  324.990285 ] MO MO MO : submitted dma request
[  324.994576 ] MO MO MO: issued pending request
[  324.998902 ] ------------[ cut here  ]------------
[  325.003550 ] WARNING: CPU: 0 PID: 47 at /home/mbilloo/lt3/phytec_am57x/factory/build/arago-tmp-external-linaro-toolchain/work-shared/am57xx-phycore-rdk/kernel-source/dr)
[  325.023972 ] 44000000.ocp:L3 Custom Error: MASTER TC2_EDMA TARGET GPMC (Idle): Data Access in Supervisor mode during Functional access
[  325.036020 ] Modules linked in: ipv6 cryptodev(O) xhci_plat_hcd xhci_hcd usbcore evdev dwc3 udc_core rtc_palmas phy_omap_usb2 snd_soc_simple_card palmas_pwrbutton extco)
[  325.070937 ] CPU: 0 PID: 47 Comm: spi4 Tainted: G        W  O    4.1.13 #1
[  325.077752 ] Hardware name: Generic DRA74X (Flattened Device Tree)
[  325.083868 ] Backtrace:
[  325.086343 ] [<c0012f78>] (dump_backtrace) from [<c001319c>] (show_stack+0x18/0x1c)
[  325.093942 ]  r7:c030fc28 r6:00000093 r5:c08e7d4c r4:00000000
[  325.099665 ] [<c0013184>] (show_stack) from [<c06313bc>] (dump_stack+0x9c/0xdc)
[  325.106923 ] [<c0631320>] (dump_stack) from [<c0039a38>] (warn_slowpath_common+0x88/0xb8)
[  325.115046 ]  r5:00000009 r4:ed8d7aa0
[  325.118654 ] [<c00399b0>] (warn_slowpath_common) from [<c0039aa0>] (warn_slowpath_fmt+0x38/0x40)
[  325.127386 ]  r8:c07e4690 r7:00000000 r6:ee1b6190 r5:c07e4184 r4:c07e4228
[  325.134160 ] [<c0039a6c>] (warn_slowpath_fmt) from [<c030fc28>] (l3_interrupt_handler+0x248/0x34c)
[  325.143068 ]  r3:ee1b6000 r2:c07e4228
[  325.146670 ]  r4:80080003
[  325.149226 ] [<c030f9e0>] (l3_interrupt_handler) from [<c0079f54>] (handle_irq_event_percpu+0x80/0x13c)
[  325.158568 ]  r10:c0910235 r9:ee1b0600 r8:00000017 r7:00000000 r6:00000000 r5:ee1b0660
[  325.166469 ]  r4:ee1b6500
[  325.169025 ] [<c0079ed4>] (handle_irq_event_percpu) from [<c007a054>] (handle_irq_event+0x44/0x64)
[  325.177932 ]  r10:00000000 r9:fa0ba138 r8:ee008000 r7:00000000 r6:ee1b6500 r5:ee1b0660
[  325.185832 ]  r4:ee1b0600
[  325.188384 ] [<c007a010>] (handle_irq_event) from [<c007cd80>] (handle_fasteoi_irq+0xb8/0x17c)
[  325.196942 ]  r7:00000000 r6:c08cfabc r5:ee1b0660 r4:ee1b0600
[  325.202661 ] [<c007ccc8>] (handle_fasteoi_irq) from [<c00795b8>] (generic_handle_irq+0x34/0x44)
[  325.211306 ]  r7:00000000 r6:ed8d7d58 r5:00000017 r4:00000017
[  325.217025 ] [<c0079584>] (generic_handle_irq) from [<c0079890>] (__handle_domain_irq+0x64/0xbc)
[  325.225757 ]  r5:00000017 r4:c08c3d2c
[  325.229365 ] [<c007982c>] (__handle_domain_irq) from [<c00094ac>] (gic_handle_irq+0x2c/0x64)
[  325.237749 ]  r9:fa0ba138 r8:ee008000 r7:fa212000 r6:ed8d7c50 r5:c08ca948 r4:fa21200c
[  325.245570 ] [<c0009480>] (gic_handle_irq) from [<c0637640>] (__irq_svc+0x40/0x74)
[  325.253083 ] Exception stack(0xed8d7c50 to 0xed8d7c98)
[  325.258156 ] 7c40:                                     c063e184 00000000 c09142c0 00000000
[  325.266368 ] 7c60: 00000082 00000013 00000000 00000000 ee008000 fa0ba138 00000000 ed8d7cf4
[  325.274582 ] 7c80: c09142c0 ed8d7c98 c003cf18 c003cfb0 200d0113 ffffffff
[  325.281221 ]  r7:ed8d7c84 r6:ffffffff r5:200d0113 r4:c003cfb0
[  325.286941 ] [<c003cef8>] (__do_softirq) from [<c003d438>] (irq_exit+0xb8/0x120)
[  325.294278 ]  r10:00000000 r9:fa0ba138 r8:ee008000 r7:00000000 r6:00000000 r5:00000013
[  325.302181 ]  r4:c08c3d2c
[  325.304736 ] [<c003d380>] (irq_exit) from [<c0079894>] (__handle_domain_irq+0x68/0xbc)
[  325.312596 ]  r5:00000013 r4:c08c3d2c
[  325.316204 ] [<c007982c>] (__handle_domain_irq) from [<c00094ac>] (gic_handle_irq+0x2c/0x64)
[  325.324588 ]  r9:fa0ba138 r8:ed709e88 r7:fa212000 r6:ed8d7d58 r5:c08ca948 r4:fa21200c
[  325.332406 ] [<c0009480>] (gic_handle_irq) from [<c0637640>] (__irq_svc+0x40/0x74)
[  325.339919 ] Exception stack(0xed8d7d58 to 0xed8d7da0)
[  325.344990 ] 7d40:                                                       ed85cdfc 600d0013
[  325.353202 ] 7d60: ed85cdfc 000000bf 00000001 ed85cc00 ed709ebc ed85cdfc ed709e88 fa0ba138
[  325.361416 ] 7d80: 00000000 ed8d7dac ed8d7db0 ed8d7da0 c046534c c0636cd0 600d0013 ffffffff
[  325.369626 ]  r7:ed8d7d8c r6:ffffffff r5:600d0013 r4:c0636cd0
[  325.375350 ] [<c0636ca8>] (_raw_spin_unlock_irqrestore) from [<c046534c>] (spi_finalize_current_message+0x2c/0x184)
[  325.385747 ] [<c0465320>] (spi_finalize_current_message) from [<c046850c>] (omap2_mcspi_transfer_one_message+0x78c/0x12fc)
[  325.396748 ]  r10:00000000 r9:fa0ba138 r8:ed709e88 r7:ed8d0e00 r6:fa0ba130 r5:fa0ba13c
[  325.404648 ]  r4:00000001 r3:ed709ebc
[  325.408258 ] [<c0467d80>] (omap2_mcspi_transfer_one_message) from [<c0465a58>] (__spi_pump_messages+0x398/0x4cc)
[  325.418387 ]  r10:ed8d6030 r9:c09264d4 r8:ed8d6000 r7:00000001 r6:ed709ebc r5:ed85cc00
[  325.426289 ]  r4:ed85cdfc
[  325.428843 ] [<c04656c0>] (__spi_pump_messages) from [<c0465ba4>] (spi_pump_messages+0x18/0x1c)
[  325.437488 ]  r10:ed8d6030 r9:c09264d4 r8:ed8d6000 r7:ed85cdd4 r6:00000000 r5:c09264d4
[  325.445389 ]  r4:ed85cdec
[  325.447947 ] [<c0465b8c>] (spi_pump_messages) from [<c00536e0>] (kthread_worker_fn+0x58/0x174)
[  325.456512 ] [<c0053688>] (kthread_worker_fn) from [<c0053670>] (kthread+0xe4/0xfc)
[  325.464110 ]  r10:00000000 r9:00000000 r8:00000000 r7:c0053688 r6:ed85cdd4 r5:ee3a31c0
[  325.472014 ]  r4:00000000 r3:ee3b3700
[  325.475624 ] [<c005358c>] (kthread) from [<c000fa08>] (ret_from_fork+0x14/0x2c)
[  325.482873 ]  r7:00000000 r6:00000000 r5:c005358c r4:ee3a31c0
[  325.488587 ] ---[ end trace d1a93cdccdfd2ce9  ]---

  • In reply to Mohammed Billoo:

    Hi,

    Sorry, but did you set the status of GPMC to status="okay"? As I said I couldn't see where you enable the GPMC interface.

    Also do you need the gpmc,sync-write & gpmc,sync-read on the GPMC inteface? Can you test with asynchronous reads/writes?

    Best Regards,
    Yordan

     


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    Hi,

    Sorry about that. Yes, we do set it in the main DTS file:

    &gpmc {
            status = "okay";
    };
    
    
    We have tried asynchronous GPMC and that works fine, but we need to use the DMA for our synchronous (high-speed) GPMC transactions.

  • In reply to Mohammed Billoo:

    Can you try with the timings provided in Section 15.4.6.1.2.1 GPMC Configuration for Synchronous Burst Read Access from the TRM? or use the formulas provided in the section to calculate your timings for the clock needed in your case?

    Best Regards,
    Yordan

     


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    I applied the GPMC timing settings to the DTS as per the instructions in the TRM:

    gpmc,sync-clk-ps = <15152>; /* Minimum clock period for synchronous mode, in picoseconds */
    
    		gpmc,cs-on-ns = <0>; /* Assertion time */
    		/*gpmc,cs-rd-off-ns = <100> ; /* Read deassertion time */*/
    		gpmc,cs-rd-off-ns = <470> ; /* Read deassertion time */
    		gpmc,cs-wr-off-ns = <40>; /* Write deassertion time */
    		gpmc,burst-read; /* burst read */
    		gpmc,burst-length = <8>; /* Attached device page length */
    
    		/* ADV signal timings (in nanoseconds) corresponding to GPMC_CONFIG3: */
    		gpmc,adv-on-ns = <0>; /* Assertion time */
    		/*gpmc,adv-rd-off-ns = <20>; /* Read deassertion time */*/
    		gpmc,adv-rd-off-ns = <15>; /* Read deassertion time */
    		gpmc,adv-wr-off-ns = <20>; /* Write deassertion time */
    
    		/* WE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4: */
    		gpmc,we-on-ns = <20>; /* Assertion time */
    		gpmc,we-off-ns = <20>; /* Deassertion time */
    	
    		/* OE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4: */
    		/*gpmc,oe-on-ns = <20>; /* Assertion time */*/
    		/*gpmc,oe-off-ns = <100>; /* Deassertion time */*/
    		gpmc,oe-on-ns = <106>; /* Assertion time */
    		gpmc,oe-off-ns = <470>; /* Deassertion time */
    
    		/* Access time and cycle time timings (in nanoseconds) corresponding to GPMC_CONFIG5: */
    		/*gpmc,page-burst-access-ns = <20>; /* Multiple access word delay */*/
    		gpmc,page-burst-access-ns = <15>; /* Multiple access word delay */
    		/*gpmc,access-ns = <10>; /* Start-cycle to first data valid delay */*/
    		gpmc,access-ns = <23>; /* Start-cycle to first data valid delay */
    		/*gpmc,rd-cycle-ns = <20>; /* Total read cycle time */*/
    		gpmc,rd-cycle-ns = <470>; /* Total read cycle time */
    		gpmc,wr-cycle-ns = <10>; /* Total write cycle time */
    
    		gpmc,device-width = <2>; /* Total width of device(s) connected to a GPMC
    		chip-select in bytes. The GPMC supports 8-bit
    		and 16-bit devices and so this property must be
    		1 or 2. */
    
    		gpmc,sync-read; /* Enables synchronous read. Defaults to asynchronous
    		is this is not set. */
    		gpmc,sync-write; /* Enables synchronous writes. Defaults to asynchronous
    		is this is not set. */

    However, when I boot the kernel, the clock rate that is seen by the GPMC driver is 266 MHz (printk in gpmc_get_fclk_period):

    [    4.995171] MO MO MO: rate = 3759l

    However, according to the AM5728 TRM, the default L3_clk (and in turn the GPMC clk) should be 166 MHz. The driver is "seeing" a clock rate that is twice the default. We haven't touched the clock rate of the L3 in the DTS.
  • In reply to Mohammed Billoo:

    Hi,

    See the Datasheet about this, Table 5-9. Maximum Supported Frequency:
    GPMC_FCLK max value is 266MHz.

    www.ti.com/.../am5728.pdf

    So the reading is correct.

    Best Regards,
    Yordan

     


     Please make sure you read the forum guidelines first.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.