PROCESSOR-SDK-AM62X: Release 09.02.01.10

Part Number: PROCESSOR-SDK-AM62X

Tool/software:

Hello, TI:
    We currently have a requirement to use GPMC to connect to an LCD with an 8080 interface (8-Bits data), and control commands and data through an address line A20. The display driver is a self-written fb driver.


    I have a question to ask. If the fb video memory writes 1 byte of data to the GPMC, I want to use the BCDMA method to send the 1024 bytes of data in the video memory fb to the GPMC peripheral using the DMA_MEM_TO_DEV method, and the GPMC sends it to the LCD. This usage scenario should be achievable on the AM62x platform at present?


    Please ask TI experts to help reply. There is relatively little information on this aspect of AM62x.

  • Hi Louis,

    Firs of all, what you asked (DMA MEM_TO_DEV on GPMC) is not supported in the current Processor SDK. But let me understand your use case to see if it is possible to add the implementation.

    If the fb video memory writes 1 byte of data to the GPMC, I want to use the BCDMA method to send the 1024 bytes of data in the video memory fb to the GPMC peripheral using the DMA_MEM_TO_DEV method,

    Is the first 1 byte write a trigger to the DMA hardware to start transfers or notification to the GPMC that data are coming? It doesn't sound like a trigger, because Linux driver writes this 1 byte, the driver can start the DMA transfer too, it doesn't need a trigger.

    and the GPMC sends it to the LCD.

    This is handled by the FPGA on GPMC, not relevant to any kernel driver, right?

  • Hi Bin Li,

        1. Firs of all, what you asked (DMA MEM_TO_DEV on GPMC) is not supported in the current Processor SDK. But let me understand your use case to see if it is possible to add the implementation.

        This is just not supported by the current SDK, but we can implement it ourselves, right?

     The method of GPMC accessing NAND has been implemented in the SDK. Therefore, as long as GPMC can configure the CS memory range in the current SDK, the driver maps the memory, and writes data to the CS memory range, GPMC can send the data. Is there any problem with this implementation?

        2. Is the first 1 byte write a trigger to the DMA hardware to start transfers or notification to the GPMC that data are coming? It doesn't sound like a trigger, because Linux driver writes this 1 byte, the driver can start the DMA transfer too, it doesn't need a trigger.

        Our application is to send a piece of memory data from fb to GPMC via DMA, and then GPMC sends it to the LCD screen。It has nothing to do with the trigger method, right?

     Gpmc communicates with 8080 interface LCD, we have already implemented it on AM335x platform。

     3. This is handled by the FPGA on GPMC, not relevant to any kernel driver, right?

        What is FPGA? Is GPMC a hardware controller? As mentioned above, as long as your SDK supports GPMC configuration, we can write data to the GPMC memory space and GPMC can send it.

        

  • Hi Louis,

    I think Bin thought you will use FPGA connect to GPMC to generate timing for 8080 LCD.  If you just need GPMC send out timing like accessing SRAM/NOR, it is ready in current SDK. 

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1372049/am625-gpmc-dts-example-for-2-devices

    Hope did not interrupt the discussion. please continue...

  • Hi Tony,

        OK,Thanks. 

        There is still a problem: the LCD fb driver is a memory pool for LCD screen display data, 1024 x 600 bytes in size. I want to use the BCDMA method to send the memory pool data to GPMC through DMA, and GPMC sends the data to LCD. Is this method feasible in AM62x at present?

        My idea is to create its own LCD driver node in gpmc in dts and fill it with BCDMA resources. Call this DMA resource in the driver. After configuring DMA in the driver, DMA sends all data from the memory area in fb to the memory address of gpmc. The memory address of gpmc is unique, and the memory address of fb is 1 area block.

  • Hi, Louis

    I made a block diagram to help understand among us:

    #1. Does 8080 interface LCD keep on refresh from LCD controller like TFT? 

    #2. The 8080 LCD only map to one address on GPMC like a FIFO? the host/controller send 1024x600 byte in sequency to refresh the LCD display content?

    #3. Only trigger 8080 LCD display content update after CPU changed display content in frame buffer? in the rest of time, no data transaction between frame buffer and 8080 LCD?

    #4. Can directly access GPMC to implement that? 

    #5. if not, I think you are asking for a memory to memory(DDR to GPMC) DMA operation approach under Linux. If yes, please @bin for help.

    I captured the 8080 timing from AM335x TRM as below, seems need to control some gpio to compose the timing. if so, maybe DMA don't help here.

  • Hi, Tony:

    #1. Does 8080 interface LCD keep on refresh from LCD controller like TFT? ------ Yes, restart a new DMA transfer via interrupt.

    #2. The 8080 LCD only map to one address on GPMC like a FIFO? the host/controller send 1024x600 byte in sequency to refresh the LCD display content? ------ Yes.

    #3. Only trigger 8080 LCD display content update after CPU changed display content in frame buffer? in the rest of time, no data transaction between frame buffer and 8080 LCD? ------ Yes.

    #4. Can directly access GPMC to implement that?  ------ Yes, Will writing directly be less efficient?

    #5. if not, I think you are asking for a memory to memory(DDR to GPMC) DMA operation approach under Linux. If yes, please @bin for help. ------ Hi, bin: Could you please help me take a look, it should be possible?

    I captured the 8080 timing from AM335x TRM as below, seems need to control some gpio to compose the timing. if so, maybe DMA don't help here.  ------ GPMC is OK. In the past, we used AM335x's GPMC to connect to 8080 interface LCD screen, and transmitted data to 8080 interface screen through GPMC.

  • Hi Louis,

    Thanks for the details in the conversation with Tony, now I have a better picture of your use case.

    The kernel already has the driver to support GPMC access for AM62x. But the missing piece is DMA support.

        This is just not supported by the current SDK, but we can implement it ourselves, right?

    It is possible, just not trivial.

    For your reference, following are two different threads in which I implemented DMA DEV_TO_MEM support on GPMC for AM62x and AM62Ax. But your requirement is about the opposite direction - MEM_TO_DEV.

    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

    This use case is more complicated than yours, it uses DMA periodic transfer and hardware (GPIO) triggering DMA transfers, I believe you don't need either of them. So this thread is just FYI.

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1337943/am62a3-linux-dma-identifiers-for-gpmc-device-register-to-memory-transfer

    This use case is more relevant to yours, it is software initiated DMA transfer. The only difference is DEV_TO_MEM vs MEM_TO_DEV.