Hello everyone!
I've just sent v3 of part 1 and 2 of RFC series:
https://patchwork.kernel.org/patch/2836123/
https://patchwork.kernel.org/patch/2836124/
2013/7/17 Gerhard Sittig <g...@denx.de>:
> OK, so the need for explicit start in software or external
> request by the peripheral remains, but the condition for the
> choice is different. It might become a flag attached to the DMA
> channel, that gets setup in the prep routines (memory and slave
> access each use their own prep calls) and gets evaluated in
> execute.
I made a flag "will_access_peripheral" be set up in the device control callback.
> non-MDDRC channels can get used for memory
> transfers as well, which your description of the the former use
> suggests, when slave support was absent.
I tested v3 on MPC5125 with SCLPC driver (transfers between dev and
mem work fine)
and dmatest module (all 64 DMA channels can perform mem-to-mem transfers).
>> > + mchan = dma_chan_to_mpc_dma_chan(chan);
>> > + switch (cmd) {
>> > + case DMA_TERMINATE_ALL:
>> > + /* disable channel requests */
>> > + mdma = dma_chan_to_mpc_dma(chan);
>> > + out_8(&mdma->regs->dmacerq, chan->chan_id);
>> > + list_splice_tail_init(&mchan->prepared, &mchan->free);
>> > + list_splice_tail_init(&mchan->queued, &mchan->free);
>> > + list_splice_tail_init(&mchan->active, &mchan->free);
>>
>> This probably need locking.
>
> Ah, yes. It needs to grab the same lock as all the other list
> manipulations in the driver's source.
Fixed that too.
Best regards,
Alexander.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
