On Mon, 18 Feb 2019 at 20:23, Arnd Bergmann [off-list ref] wrote:

On Mon, Feb 18, 2019 at 11:52 AM Baolin Wang [off-list ref] wrote:

quoted

On Mon, 18 Feb 2019 at 18:31, Arnd Bergmann [off-list ref] wrote:

quoted

On Tue, Feb 12, 2019 at 9:25 AM Baolin Wang [off-list ref] wrote:

quoted

On Fri, 1 Feb 2019 at 19:53, Baolin Wang [off-list ref] wrote:

quoted

On Thu, 31 Jan 2019 at 00:52, Arnd Bergmann [off-list ref] wrote:

quoted

On Tue, Jan 22, 2019 at 2:21 PM Baolin Wang [off-list ref] wrote:

quoted

 Client:
 DMA clients connected to the Spreadtrum DMA controller must use the format
-described in the dma.txt file, using a two-cell specifier for each channel.
-The two cells in order are:
+described in the dma.txt file, using a three-cell specifier for each channel.
+The three cells in order are:
 1. A phandle pointing to the DMA controller.
 2. The channel id.
+3. The hardware slave id which is used for clients to trigger DMA engine
+automatically.

I notice that this is an incompatible binding change. Is that necessary?
If the current code works, I'd suggest allowing both #dma-cells=<2>
and <3>, and then implementing both in the driver.

Yes, this is necessary.

Yes, current code can work, but the problem is that the DMA clients
must add one property (something like "sprd,slave-id") to specify the
slave id. So considering this, we want to change the dma-cells to 2,
including dma channel and dma slave id, which can avoid introducing
some similar properties for DMA clients.

Now there are no DMA clients in mainline for Spreadtrum platform, and
we want to upstream our first DMA clients: SPI controller. So no other
drivers need to change when we changing dma cells. Thanks.

Do you have any other concerns about this patch set? If not, I think
Vinod can apply this patch set. Thanks.

Sorry for the late reply. Yes, this makes sense since there are no
existing users then. For the DT changes going through the dmaengine
tree

Acked-by: Arnd Bergmann <arnd@arndb.de>

Thanks for your reviewing.

quoted

One more question, to make sure we don't need to edit it again:
Why do you need both a 'channel id' and a 'slave id' here? Is this
a strict hardware requirement for your DMA engine? In many
other designs, only a DMA request line number needs to
be described, and I think this would correspond to what you
call the 'hardware slave id' in your documentation.

I try to explain why we need the slave id.

For our DMA engine driver, we have software request mode and hardware
request mode. For software request mode, the DMA engine driver need
trigger DMA to start transfer manually. But for hardware request mode,
we just set one unique slave id corresponding to the slave hardware to
the DMA engine, then the slave hardware can trigger DMA automatically.
And the slave id is not always same with the channel id according to
the SoC design, so we add one cell to specify the slave id.

I did understand the need for a slave-id, I was instead wondering about
the channel-id number. On many SoCs, all channels are equal, and you
just have to pick one of those with the right capabilities for a particular
slave.

Yes, all channels are equal. We just set a unique slave id for the
channel for a particular slave. For example, the SPI slave can use
channel 10 for tx transfer by setting slave id 11, or it also can use
channel 9 for tx transfer by setting same slave id 11.

-- 
Baolin Wang
Best Regards

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel