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: 412

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

  • Hi,

    Which Processor SDK Linux is this? Can you share your dts node for the GPMC interface?

    Best Regards,
    Yordan

     


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    Hi, This is based on the Phytec 15.1-rc4 RDK. Here are the relevant snippets pertinent to the edma and gpmc nodes:

    edma: edma-controller@43300000 {
        compatible = "ti,edma3";
        reg = <0x43300000 0x801c>;
        interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>,
                 <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>,
                 <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
        #dma-cells = <1>;
        ti,hwmods = "tpcc", "tptc0", "tptc1";
        dma-requests = <64>;
    };

    edma_xbar: dma-router@4a002c78 {
        compatible = "ti,dra7-dma-crossbar";
        reg = <0x4a002c78 0x7c>;
        #dma-cells = <1>;
        dma-requests = <204>;
        ti,dma-safe-map = <0>;
        dma-masters = <&edma>;
    };

    gpmc: gpmc@50000000 {
        compatible = "ti,am3352-gpmc";
        ti,hwmods = "gpmc";
        reg = <0x50000000 0x2000>;      /* device IO registers */
        interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
        dmas = <&edma_xbar 4>;
        dma-names = "rxtx";
        gpmc,num-cs = <8>;
        gpmc,num-waitpins = <2>;
        #address-cells = <2>;
        #size-cells = <1>;
        gpio-controller;
        #gpio-cells = <2>;
        interrupt-controller;
        #interrupt-cells = <2>;
        status = "disabled";
    };

    fpga_pins_default: fpga_pins_default {
        pinctrl-single,pins = <
                    0x000 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad0.gpmc_ad0 MODE0 | INPUT | PULLUP */
                    0x004 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad1.gpmc_ad1 MODE0 | INPUT | PULLUP */
                    0x008 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad2.gpmc_ad2 MODE0 | INPUT | PULLUP */
                    0x00C (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad3.gpmc_ad3 MODE0 | INPUT | PULLUP */
                    0x010 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad4.gpmc_ad4 MODE0 | INPUT | PULLUP */
                    0x014 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad5.gpmc_ad5 MODE0 | INPUT | PULLUP */
                    0x018 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad6.gpmc_ad6 MODE0 | INPUT | PULLUP */
                    0x01C (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad7.gpmc_ad7 MODE0 | INPUT | PULLUP */
                    0x020 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad8.gpmc_ad8 MODE0 | INPUT | PULLUP */
                    0x024 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad9.gpmc_ad9 MODE0 | INPUT | PULLUP */
                    0x028 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad10.gpmc_ad10 MODE0 | INPUT | PULLUP */
                    0x02C (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad11.gpmc_ad11 MODE0 | INPUT | PULLUP */
                    0x030 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad12.gpmc_ad12 MODE0 | INPUT | PULLUP */
                    0x034 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad13.gpmc_ad13 MODE0 | INPUT | PULLUP */
                    0x038 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad14.gpmc_ad14 MODE0 | INPUT | PULLUP */
                    0x03C (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_ad15.gpmc_ad15 MODE0 | INPUT | PULLUP */

                    0x0BC (PIN_OUTPUT | MUX_MODE0)            /* gpmc_cs3.gpmc_cs3 MODE0 | OUTPUT */

                    0x0C0 (PIN_INPUT | MUX_MODE0)           /* gpmc_clk.gpmc_clk MODE0 | INPUT */
                    0x0C4 (PIN_OUTPUT | MUX_MODE0)          /* gpmc_advn_ale.gpmc_advn_ale MODE0 | OUTPUT */
                    0x0C8 (PIN_OUTPUT | MUX_MODE0)            /* gpmc_oen_ren.gpmc_oen_ren MODE0 | OUTPUT */
                    0x0CC (PIN_OUTPUT | MUX_MODE0)           /* gpmc_wen.gpmc_wen MODE0 | OUTPUT */
                    0x0D0 (PIN_OUTPUT | MUX_MODE0)          /* gpmc_ben0_cle.gpmc_ben0_cle MODE0 | OUTPUT */
                    0x0D4 (PIN_OUTPUT | MUX_MODE0)            /* gpmc_ben1_cle.gpmc_ben1_cle MODE0 | OUTPUT */
                    0x0D8 (PIN_INPUT_PULLUP | MUX_MODE0)    /* gpmc_wait0.gpmc_wait0 MODE0 | INPUT | PULLUP */
            0x5C  (PIN_INPUT_PULLUP | MUX_MODE14)    /* gpio1_29 */
        >;
    };


    &gpmc {
        pinctrl-names="default";
        pinctrl-0 = <&fpga_pins_default>;
        ranges = <3 0 0x3000000 0x0100000>; /* fpga */

        hs_gpmc: fpga@3,0 {
            reg = <3 0 0x100000>;

            #address-cells = <1>;
            #size-cells = <1>;
            interrupt-parent = <&gpio1>;
            interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
            compatible = "lgs,hs-fpga";

            bank-width = <2>;

            gpmc,sync-clk-ps = <0>; /* 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-wr-off-ns = <40>; /* Write deassertion time */

            /* 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-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 */

            /* Access time and cycle time timings (in nanoseconds) corresponding to GPMC_CONFIG5: */
            gpmc,page-burst-access-ns = <20>; /* Multiple access word delay */
            gpmc,access-ns = <10>; /* Start-cycle to first data valid delay */
            gpmc,rd-cycle-ns = <20>; /* 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 = <1>; /* Enables synchronous read. Defaults to asynchronous
            is this is not set. */
            gpmc,sync-write = <1>; /* Enables synchronous writes. Defaults to asynchronous
            is this is not set. */
            gpmc,data-mux-bus = <1>;
        };
    };

  • In reply to Mohammed Billoo:

    Hi,

    Ok, I am not familiar with this Phytec 15.1-rc4 RDK as TI does not support it.

    However I looked at your dts configuration. On first inspection the dts nodes seem ok comparing it with the examples provided in Documentation folder in the Processor SDK Linux.

    Please verify that the EDMA events you set in your gpmc node dmas = <&edma_xbar 4>; is not used for anything else.

    Also are you using the MCSPI interface? If not, can you try to remove it from the dts file (comment it out, don't just set its status to disable) and disable the driver from the kernel config? It seems that it messes up with the gpmc operation somehow:
    [ 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)

    Best Regards,
    Yordan

     


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    Unfortunately, we can't disable the McSPI interface as that is another interface we use to communicate with the FPGA and ultimately trigger the DMA transaction. Is there anything that you can suggest we try?

  • In reply to Mohammed Billoo:

    Which SPI interface are you using (I suppose SPI4)? What is its dts configuration?

    Are you using the SPI & GPMC at the same time to access the FPGA?

    What comes to my mind is to try and remap the GPMC dma using the edam_xbar. You could do that by writing CTRL_CORE_DMA_EDMA_DREQ_2_3[23:16]DMA_EDMA_DREQ_3_IRQ_3 a number different from 0x4 or by setting different value in dmas = <&edma_xbar N> , N= free dma request (not used in your system).

    Best Regards,
    Yordan

     


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    The specific error was resolved by selecting the appropriate in our "child" driver dts specification (we needed to specificy edma_xbar 4 as the dma device and "rxtx" as the name. However, when specifying this and using dma_request_slave_channel(&pdev->dev, "rxtx"), we're not getting any GPMC transactions.

  • In reply to Mohammed Billoo:

    Hi,

    The specific error was resolved by selecting the appropriate in our "child" driver dts specification (we needed to specificy edma_xbar 4 as the dma device and "rxtx" as the name


    Can you share the modifications done? I can't figure out what code changes were made by this explanation.

    Best Regards,
    Yordan

     


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    Attached is the updated node for our custom gpmc device that prevented the kernel panic, but it also seems that the GPMC transaction isn't being triggered as well.

    hs_gpmc: fpga@3,0 {
            reg = <3 0 0x100000>;

            #address-cells = <1>;
            #size-cells = <1>;
            interrupt-parent = <&gpio1>;
            interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
            dmas = <&edma_xbar 4>;
            dma-names = "rxtx";
            compatible = "lgs,hs-fpga";

            bank-width = <2>;

            gpmc,sync-clk-ps = <0>; /* 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-wr-off-ns = <40>; /* Write deassertion time */

            /* 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-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 */

            /* Access time and cycle time timings (in nanoseconds) corresponding to GPMC_CONFIG5: */
            gpmc,page-burst-access-ns = <20>; /* Multiple access word delay */
            gpmc,access-ns = <10>; /* Start-cycle to first data valid delay */
            gpmc,rd-cycle-ns = <20>; /* 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 = <1>; /* Enables synchronous read. Defaults to asynchronous
            is this is not set. */
            gpmc,sync-write = <1>; /* Enables synchronous writes. Defaults to asynchronous
            is this is not set. */
            gpmc,data-mux-bus = <1>;
        };

  • In reply to Mohammed Billoo:

    Hi,

    Try keeping the dma_xbar setup in "&gpmc" part of the node. I think that adding it to "hs_gpmc: fpga@3,0" disables the GPMC dma and that is why it cannot issue data transactions.

    Also as I see you have:
    gpmc: gpmc@50000000 {
    ...............
    status="disabled"
    }

    And then you don't have the status="okay" in &gpmc

    Best Regards,
    Yordan

     


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    Hi,

    Thanks for getting back to me. Unfortunately, even if I remove the dma_xbar entries in the "hs_gpmc" dts node, I still don't see any transactions.

    Here is where I set the source address in the DMA engine:

    memset(&data->cfg, 0, sizeof(data->cfg));
    data->cfg.direction = DMA_DEV_TO_MEM;
    data->cfg.src_addr = HS_GPMC_FPGA_DMA_START_ADDRESS;
    data->cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
    data->cfg.src_maxburst = 2
    dmaengine_slave_config(data->chan, &data->cfg);

    where HS_GPMC_FPGA_DMA_START_ADDRESS is hard-coded 0x3000000 (set from the DTS)

    Here is where I set up the underlying eDMA driver for a single transaction and issue the request:

    tx_sync_desc = dmaengine_prep_slave_single(data->chan, data->dma_start, HS_GPMC_FPGA_LEN, DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
    tx_sync_desc->callback = hs_gpmc_fpga_dma_callback;
    tx_sync_desc->callback_param = data;
    
    dma_cookie = dmaengine_submit(tx_sync_desc);
    dma_async_issue_pending(data->chan);

    I can see that the appropriate call gets made in the underlying edma driver to kick off the DMA (here are some printks from my driver and the eDMA driver):

    [  223.977816] hs_gpmc_irq_handler: Going to start DMA transaction
    [  223.983763] MO MO MO: edma_prep_slave_sg dir 2 flags 1
    [  223.988923] MO MO MO: edma_prep_slave_sg dev to mem src addr: 0x3000000 width = 4
    [  223.996437] MO MO MO: Prepped slave single
    [  224.000548] MO MO MO : submitted dma request
    [  224.004833] MO MO MO: going to execute edma
    [  224.009035] MO MO MO: going to restore irq
    [  224.013145] MO MO MO: issued pending request
    [  224.017440] MO MO MO: returning from irq handler

    but the GPMC transaction never happens and my DMA callback is never called.

    Thanks

    Mohammed

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.