On 04/17/2018 01:43 PM, Radhey Shyam Pandey wrote: > Hi Vinod, > >> -----Original Message----- >> From: Vinod Koul [mailto:vinod.koul@xxxxxxxxx] >> Sent: Wednesday, April 11, 2018 2:39 PM >> To: Radhey Shyam Pandey <radheys@xxxxxxxxxx> >> Cc: dan.j.williams@xxxxxxxxx; michal.simek@xxxxxxxxxx; Appana Durga >> Kedareswara Rao <appanad@xxxxxxxxxx>; Radhey Shyam Pandey >> <radheys@xxxxxxxxxx>; lars@xxxxxxxxxx; dmaengine@xxxxxxxxxxxxxxx; >> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx >> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control >> words to netdev dma client >> >> On Mon, Apr 02, 2018 at 04:09:02PM +0530, Radhey Shyam Pandey wrote: >> >>> + >>> + if (chan->xdev->has_axieth_connected) { >>> + seg = list_first_entry(&desc->segments, >>> + struct xilinx_axidma_tx_segment, >> node); >>> + if (cb.callback_param) { >>> + app_w = (u32 *) cb.callback_param; >> >> why are you interpreting callback_param? This is plainly wrong. >> we do not know what is the interpretation of callback_param and it is >> internal to submitter. > In design, if AXI DMA is connected to AXI Ethernet IP there are certain > AXI4-Stream Status fields (RX) that we need to pass to ethernet driver > along with data buffer. An example includes: checksum fields, packet > length etc. To pass these control words there is a structure defined > between dmaengine and client. Before calling the client callback > stream control words are copied to dma client callback_param struct > (only if axieth is connected). > > I understand it's not an ideal way and we shouldn't be interpreting > callback_param but couldn't find any better alternative of passing > custom information from dmaengine to client driver and still be > aligned to the framework. > >> >> What exactly is the problem you are trying to solve? > As mentioned above we need to pass AXI4-stream words(custom > data) from dmaengine driver to dma client driver(ethernet) for > each DMA descriptor. Current solution populates callback_param > struct (only if axieth is connected). Please let me know if there is > an alternate solution. The standard interfaces need to work in a way that a client using them does not have to know to which DMA controller it is connected. In a similar way the DMA controller shouldn't have any client specific logic for the generic interfaces. Otherwise there is no point of having a generic interface. There are two options. Either you extend the generic interfaces so it can cover your usecase in a generic way. E.g. the ability to attach meta data to transfer. Or you can implement a interface that is specific to your DMA controller and any client using this interface knows it is talking to your DMA controller. -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
