Hello. Pedanekar, Hemant wrote:
Add support for Texas Instuments Communication Port Programming Interface 4.1 (CPPI 4.1) used on OMAP-L137/DA830.
At this moment, only the DMA controller and queue manager are supported. Support for the buffer manager is lacking but this chip doesn't have it anyway.
Index: linux-davinci/arch/arm/mach-davinci/cppi41.c =================================================================== --- /dev/null +++ linux-davinci/arch/arm/mach-davinci/cppi41.c @@ -0,0 +1,788 @@ +/*
[...]
+ +/* First 32 packet descriptors are reserved for unallocated memory regions. */ +static u32 next_desc_index[CPPI41_NUM_QUEUE_MGR] = { 1 << 5 }; +static u8 next_mem_rgn[CPPI41_NUM_QUEUE_MGR]; + +static struct { + size_t rgn_size; + void *virt_addr; + dma_addr_t phys_addr; + struct cppi41_queue_obj queue_obj; + u8 mem_rgn; +} dma_teardown[CPPI41_NUM_DMA_BLOCK]; + +/******************** CPPI 4.1 Functions (External Interface) *****************/ + +int __init cppi41_queue_mgr_init(u8 q_mgr, dma_addr_t rgn0_base, u16 rgn0_size) +{ + void __iomem *q_mgr_regs; + void *ptr; + + if (q_mgr >= cppi41_num_queue_mgr) + return -EINVAL; + + q_mgr_regs = cppi41_queue_mgr[q_mgr].q_mgr_rgn_base; + + __raw_writel(rgn0_base, q_mgr_regs + QMGR_LINKING_RAM_RGN0_BASE_REG); + DBG("Linking RAM region 0 base @ %p, value: %x\n", + q_mgr_regs + QMGR_LINKING_RAM_RGN0_BASE_REG, + __raw_readl(q_mgr_regs + QMGR_LINKING_RAM_RGN0_BASE_REG)); + + __raw_writel(rgn0_size, q_mgr_regs + QMGR_LINKING_RAM_RGN0_SIZE_REG); + DBG("Linking RAM region 0 size @ %p, value: %x\n", + q_mgr_regs + QMGR_LINKING_RAM_RGN0_SIZE_REG, + __raw_readl(q_mgr_regs + QMGR_LINKING_RAM_RGN0_SIZE_REG)); + + ptr = dma_alloc_coherent(NULL, 0x10000 - rgn0_size * 4, + &linking_ram[q_mgr].phys_addr, + GFP_KERNEL | GFP_DMA);
[HP] Consider if region 2 allocation is really required always.
In context of DA830 -- yes, always.
Of course, this will need total number of descriptors in system to be known beforehand.
Well, could add a function parameter...
+enum cppi41_rx_desc_type { + cppi41_rx_embed_desc, + cppi41_rx_host_desc, + cppi41_rx_mono_desc, +}; + +/** + * struct cppi41_rx_ch_cfg - Rx Channel Configuration + * + * Must be allocated and filled by the caller of cppi41_rx_ch_configure(). + * + * The same channel can be configured to receive different descripor type + * packets (not simaltaneously). When the Rx packets on a port need to be sent + * to the SR, the channels default descriptor type is set to Embedded and the + * Rx completion queue is set to the queue which CPU polls for input packets. + * When in SR bypass mode, the same channel's default descriptor type will be + * set to Host and the Rx completion queue set to one of the queues which host + * can get interrupted on (via the Queuing proxy/accumulator). In this example, + * the embedded mode configuration fetches free descriptor from the Free + * descriptor queue (as defined by struct cppi41_embed_pkt_cfg) and host + * mode configuration fetches free descriptors/buffers from the free descriptor/ + * buffer queue (as defined by struct cppi41_host_pkt_cfg). + * + * NOTE: There seems to be no separate configuration for teardown completion + * descriptor. The assumption is rxQueue tuple is used for this purpose as well. + */
[HP] Replace reference to SR with generic term ('embedded processor'?)
Embedded processor will be confusing, as DA830 itself is an embedded processor. :-)
What SR stands for BTW?
+ +/* + * CPPI 4.1 Miscellaneous APIs + */ + +/** + * cppi41_get_teardown_info - CPPI 4.1 teardown completion processing function + * + * @addr: physical address of teardown descriptor + * @info: pointer to the teardown information word + * + * This function is called to complete the teardown processing on a channel + * and provides teardown information from the teardown descriptor passed to it. + * It also recycles the teardown descriptor back to the teardown descriptor + * queue. + * + * Returns 0 if valid descriptor, -EINVAL otherwise. + */ +int cppi41_get_teardown_info(unsigned long addr, u32 *info);
[HP] A more specific name as this is not just a 'get' function?
Any idea? Note that it was called PAL_cppi4GetTdInfo() originally.
Thanks, Hemant
WBR, Sergei _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source