• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 655 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM62A3: Linux DMA Identifiers for GPMC Device Register to Memory Transfer

Craig Boardman
Prodigy 40 points
Part Number: AM62A3

Hi There,

I'm looking to write a linux driver that uses DMA to read from a memory-mapped register on the GPMC bus, into a memory buffer.

I can't seem to find any example code that sets up the device tree to specify the `dmas` to transfer DMA_DEV_TO_MEM from a GPMC device. I've examined `drivers/dma/ti/k3-psil-am62a.c`, but don't find anything related to GPMC in the `am62a_src_ep_map`.

Examining https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62ax/psil_cfg.html, I found:

pktdma_rx 0x9000 to 0x9017

But can't find enough documentation around this to determine whether this is the correct avenue to go.

Below is an example of the node I'm trying to setup in my device tree, that will utilize this DMA action:

Fullscreen
1
2
3
4
5
6
7
8
9
10
my_device_data: my-device-data@20110000 {
compatible = "my-device";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x4c000000 0x1c00000>;
memory-region = <&my_device_region>;
dmas = <&main_pktdma ? ?>;
dma-names = "rx";
status = "okay";
};
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Any help you can provide to direct me to the documentation/information I can't find would be appreciated.

Thanks in advance,

Craig.

  • 0
    TI__Guru**** 156311 points

    Hi Craig,

    The DMA driver in the current kernel for AM62Ax devices requires the interface to have PDMA module to use DMA_DEV_TO_MEM or DMA_MEM_TO_DEV transfer mode. But GPMC doesn't have PDMA.

    You potentially could use DMA_MEM_TO_MEM on AM62Ax GPMC. Can you please describe your data transfer scenario on GPMC then I will know if it is possible to use DMA on your GPMC usecase?

    Craig Boardman said:
    I've examined `drivers/dma/ti/k3-psil-am62a.c`, but don't find anything related to GPMC in the `am62a_src_ep_map`.

    GPMC doesn't have PDMA module, so the psil driver is irrelevant.

  • 0 in reply to Bin Liu
    Prodigy 40 points

    Ok, that would explain why I didn't find anything relating to it, thanks for the clarification.

    My data transfer scenario is that I have a 64-bit register on the GPMC device that I read N times to fill a sample buffer in memory. I would like to set up a transfer that kicks off the read process, and on completion notify user-space of the data. A new process would then be started, filling a free memory buffer.

    Thanks,

     Craig.

  • 0 in reply to Craig Boardman
    TI__Guru**** 156311 points

    Hi Craig,

    So the 64-bit GPMC register acts as a FIFO, DMA keeps reading it N times to get 8N bytes data to a buffer in DDR, correct?

    What triggers the DMA transfer, software (kernel driver) or hardware event from GPMC?

  • 0 in reply to Bin Liu
    Prodigy 40 points

    Essentially. The register is read say 1024 times to fill a buffer, which is then processed by the user application. This is some custom hardware, and a polling technique is used in a synchronized fashion. The DMA is triggered when a separate user space event is received via an ioctl command. The app polls whether the DMA buffer is ready at various synchronization points, and when a new buffer is available, it uses it, an starts the next transfer.

  • 0 in reply to Craig Boardman
    TI__Guru**** 156311 points

    Hi Craig,

    As I explained early, the kernel DMA driver in the Processor SDK doesn't support this usecase. However, I recently implemented the solution for a customer, which is very similar to your use case. The only difference in that use case is that the GPMC/FPGA drives a GPIO to directly trigger DMA transfer when GPMC data are ready, CPU only gets DMA completion interrupt when DMA transfer is complete.

    Please review the following e2e thread which covers all the details of the implementation. Be aware this thread is very long!

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1200987/am625-rerouting-interrupt-to-dma-event-and-dma_dev_to_mem-channel-selection

  • 0 in reply to Bin Liu
    Prodigy 40 points

    Thanks Bin, I'll read up on that (very long) thread :)

  • 0 in reply to Bin Liu
    Prodigy 40 points

    Hi Bin,

    I finally got back to making this work for my product. After examining the thread you provided, I'd like to go through how I would set this up, and hopefully have you confirm I'm on the correct track. Basically I have a shell driver that attempts to transfer data from a register on a device attached to the GPMC bus. The dma transfer is triggered by an ioctl command the indicates how many times the register should be read (say 1000), into a memory buffer. Below are some snippets form the device tree, driver dma initialization code, and ioctl command to start the transfer. 

    Node in device tree:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    my_dma_driver {
    compatible = "my_dma_driver";
    #address-cells = <1>;
    #size-cells = <1>;
    /* Register to read on the GPMC bus */
    reg = <0x0 0x5000DE80 0x0 8>;
    /* Buffer declared as coherent memory */
    memory-region = <&my_dma_coherent_buffer_region>;
    dmas = <&main_bcdma 1 0 0>;
    dma-names = "rx";
    status = "okay";
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Code in invoked from probe to initialize DMA:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    static int init_dma(struct my_dma_data* priv) {
    struct dma_slave_config dma_config;
    struct dma_chan *dma_chan;
    int ret;
    /* Declare the reserved memory of for the dma operation to be the
    * coherent memory allocated by the dma operations for this device
    * driver */
    ret = dma_declare_coherent_memory(
    priv->dev,
    (phys_addr_t)priv->dma_phys_start,
    (dma_addr_t)priv->dma_phys_start,
    priv->dma_phys_size);
    if (ret != 0) {
    dev_err(priv->dev, "dma_declare_coherent_memory error (%d)", ret);
    return ret;
    }
    /* Request the rx dma channel to be used by the driver */
    dma_chan = dma_request_chan(priv->dev, "rx");
    if (IS_ERR_OR_NULL(dma_chan)) {
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Code to start the DMA (invoked from an ioctl):

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    static int dma_start(dma_data* priv, unsigned long user_param) {
    struct device *dev;
    struct dma_par par;
    struct dma_async_tx_descriptor *tx;
    dma_cookie_t cookie;
    int ret;
    dev = priv->dev;
    ret = copy_from_user((void *)&par,
    (const void __user *)user_param,
    sizeof(par));
    if (ret != 0) {
    dev_err(dev, "dma_start: copy_from_user failure");
    return -1;
    }
    /* Prepare DMA transaction */
    tx = dmaengine_prep_slave_single(priv->dma_chan,
    (dma_addr_t)par.dst, par.len,
    DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
    if (IS_ERR_OR_NULL(tx)) {
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The intention would then be to apply the patch you provided in the referenced thread that allows the bcdma to work in this situation:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
    index ff3dc91f826c..f06899367ebd 100644
    --- a/drivers/dma/ti/k3-udma.c
    +++ b/drivers/dma/ti/k3-udma.c
    @@ -952,9 +952,14 @@ static int udma_start(struct udma_chan *uc)
    udma_rchanrt_write(uc, UDMA_CHAN_RT_CTL_REG,
    UDMA_CHAN_RT_CTL_EN);
    - /* Enable remote */
    - udma_rchanrt_write(uc, UDMA_CHAN_RT_PEER_RT_EN_REG,
    + if (!uc->config.tr_trigger_type)
    + /* Enable remote */
    + udma_rchanrt_write(uc, UDMA_CHAN_RT_PEER_RT_EN_REG,
    UDMA_PEER_RT_EN_ENABLE);
    + else
    + udma_tchanrt_write(uc, UDMA_CHAN_RT_CTL_REG,
    + UDMA_CHAN_RT_CTL_EN);
    +
    break;
    case DMA_MEM_TO_DEV:
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Craig Boardman
    TI__Guru**** 156311 points

    Hi Craig,

    Nice to see you are making progress.

    Craig Boardman said:
    Code to start the DMA (invoked from an ioctl):

    In your use case, is the GPMC data are ready when application invokes the ioctl to run dma_start() function, so when dma_async_issue_pending() is called, the DMA channel should start moving data right away?

  • 0 in reply to Bin Liu
    Prodigy 40 points

    Yes, that's the way it is intended to operate.

    I am having a number of issues getting this working. I haven't yet been able to get through the `dmaengine_prep_slave_single` call. It makes it into `udma_prep_slave_sg_triggered_tr` which then causes the system to freeze in the `udma_alloc_tr_desc`. I'm currently trying to track down how it's dying there... I'm not even getting panic info out of the system at that point.

  • 0 in reply to Craig Boardman
    TI__Guru**** 156311 points

    Ok, your use case is much simpler than the previous one which you referred to.

    Please give me a few days to review your code. I am currently debugging another customer issue.

  • 0 in reply to Craig Boardman
    TI__Guru**** 156311 points

    Hi Craig,

    Sorry for my late response.

    Craig Boardman said:
    The intention would then be to apply the patch you provided in the referenced thread that allows the bcdma to work in this situation:

    It seems you are taking the patch I posted on October 20 in the referred E2E thread, the patch filename is "udma-dev-to-mem-sw-trigger-1020.diff". This patch requires software trigger by writing to a register bit. This patch is not right for you.

    Please use the patch I posted on October 19, which filename is "udma-dev-to-mem-1019.diff", this patch automatically starts the DMA transfer as soon as dma_async_issue_pending() is called in your application driver.

    I also attached the same kernel patch below. Please let me know if this patch works for you.

    3386.udma-dev-to-mem-1019.diff
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    diff --git a/arch/arm64/boot/dts/ti/k3-am625-sk.dts b/arch/arm64/boot/dts/ti/k3-am625-sk.dts
    index b1737978103b..5a7b614b7b4c 100644
    --- a/arch/arm64/boot/dts/ti/k3-am625-sk.dts
    +++ b/arch/arm64/boot/dts/ti/k3-am625-sk.dts
    @@ -13,6 +13,12 @@ / {
    compatible = "ti,am625-sk", "ti,am625";
    model = "Texas Instruments AM625 SK";
    + dma_test {
    + compatible = "ti,dma_test";
    + dmas = <&main_bcdma 1 0 0>;
    + dma-names = "rx";
    + };
    +
    opp-table {
    /* Add 1.4GHz OPP for am625-sk board. Requires VDD_CORE to be at 0.85V */
    opp-1400000000 {
    diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
    index ff3dc91f826c..6f8af321bb3d 100644
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Bin Liu
    Prodigy 40 points

    Thanks Bin, I'll try applying this patch, and see how it goes.

    One point that may have been missed is that I was getting a kernel crash when the dmaengine_prep_slave_single eventually invoked udma_alloc_tr_desc . I'm not sure what was causing this. One thought was maybe that the dma_declare_coherent_memory allocation was interfering with the dma allocation of the TR's.

  • 0 in reply to Craig Boardman
    TI__Guru**** 156311 points

    Hi Craig,

    Craig Boardman said:
    One point that may have been missed is that I was getting a kernel crash when the dmaengine_prep_slave_single eventually invoked udma_alloc_tr_desc .

    If the crash still happens with patch udma-dev-to-mem-1019.diff, please post the console log.

    FYI, attached below is the kernel driver I used to test my UDMA driver.

    8244.dmatest.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    /*
    * DMA DEV_TO_MEM testing
    *
    * on am335x-boneblack.dts:
    *
    * / {
    * + dma_test {
    * + compatible = "ti,dma_test";
    * + dmas = <&edma 12 0>;
    * + dma-names = "rx";
    * + };
    * }
    */
    #include <linux/dma-mapping.h>
    #include <linux/dmaengine.h>
    #include <linux/miscdevice.h>
    #include <linux/platform_device.h>
    #include <linux/fs.h>
    #include <linux/of.h>
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Bin Liu
    Prodigy 40 points

    Hi Bin,

    I finally got some time to try this out. I applied the patch, and incorporated your driver with a few changes to read from the device register. As far as I can tell, everything worked perfectly. Next step for me is to incorporate the changes into the actual driver. I'll update you when I get that sorted.

    Thanks a lot for the help you have provided.

  • 0 in reply to Craig Boardman
    TI__Guru**** 156311 points

    HI Craig,

    This is great progress. Thanks for the update.