Re: [PATCH v4 10/15] dmaengine: ti: New driver for K3 UDMA - split#2: probe/remove, xlate and filter_fn

Peter Ujfalusi
2019-11-11T09:15:09Z

On 11/11/2019 7.33, Vinod Koul wrote:
> On 01-11-19, 10:41, Peter Ujfalusi wrote:
>
>> +static bool udma_dma_filter_fn(struct dma_chan *chan, void *param)
>> +{
>> + struct psil_endpoint_config *ep_config;
>> + struct udma_chan *uc;
>> + struct udma_dev *ud;
>> + u32 *args;
>> +
>> + if (chan->device->dev->driver != &udma_driver.driver)
>> + return false;
>> +
>> + uc = to_udma_chan(chan);
>> + ud = uc->ud;
>> + args = param;
>> + uc->remote_thread_id = args[0];
>> +
>> + if (uc->remote_thread_id & K3_PSIL_DST_THREAD_ID_OFFSET)
>> + uc->dir = DMA_MEM_TO_DEV;
>> + else
>> + uc->dir = DMA_DEV_TO_MEM;
>
> Can you explain this a bit?

The UDMAP in K3 works between two PSI-L endpoint. The source and
destination needs to be paired to allow data flow.
Source thread IDs are in range of 0x0000 - 0x7fff, while destination
thread IDs are 0x8000 - 0xffff.

If the remote thread ID have the bit 31 set (0x8000) then the transfer
is MEM_TO_DEV and I need to pick one unused tchan for it. If the remote
is the source then it can be handled by rchan.

dmas = <&main_udmap 0xc400>, <&main_udmap 0x4400>;
dma-names = "tx", "rx";

0xc400 is a destination thread ID, so it is MEM_TO_DEV
0x4400 is a source thread ID, so it is DEV_TO_MEM

Even in MEM_TO_MEM case I need to pair two UDMAP channels:
UDMAP source threads are starting at offset 0x1000, UDMAP destination
threads are 0x9000+

Changing direction runtime is hardly possible as it would involve
tearing down the channel, removing interrupts, destroying rings,
removing the PSI-L pairing and redoing everything.

>> +static int udma_remove(struct platform_device *pdev)
>> +{
>> + struct udma_dev *ud = platform_get_drvdata(pdev);
>> +
>> + of_dma_controller_free(pdev->dev.of_node);
>> + dma_async_device_unregister(&ud->ddev);
>> +
>> + /* Make sure that we did proper cleanup */
>> + cancel_work_sync(&ud->purge_work);
>> + udma_purge_desc_work(&ud->purge_work);
>
> kill the vchan tasklets at it too please

Oh, I have missed that, I'll add it.

- Péter