On Mon, Jul 18, 2011 at 1:21 PM, Raju, Sundaram <sundaram@xxxxxx> wrote: >> >> Maybe a new api to pass fixed-format variable-length encoded message >> to the DMAC drivers? >> Which could be interpreted by DMAC drivers to extract all the needed xfer >> parameters from the 'header' section and instructions to program the xfers >> in the DMAC from the variable length body of the 'message' buffer. >> It might sound complicated but we can have helpers to make the job easy. >> Btw, the regular single/sg-list xfers could also be expressed by this method. > > Do you expect this variable length body of the message to be DMAC > independent? I don't think so. In that case how is this different from what > we have here already? Yes, this whould be DMAC independent. > If it can be DMAC independent, can you illustrate more on how this can > be done? But the point to note is, if this can be made DMAC independent > then the control command we have also can be made DMAC independent > by generalizing the configuration structure passed to it. The 'header' I suggest, would in fact be a structure body, only an extra pointer would point to the 'instructions' to convey actual location and sizes of mico-xfers. I don't think it is possible to have general definition of such transfers fully within a structure. If I understand what you ask. I have just posted an RFC. I kept the terms same so that it is easier to understand. Please have a look. You are CC'ed too. Thanks, Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
