On Thursday 06 November 2014 10:11:58 Linus Walleij wrote:
> >> + saa0@dmac0 {
> >> + signal = "saa0";
> >> + bus-interface-ahb1;
> >> + };
> >
> > The main value-add this gives you is a name of the signal, but nobody else
> > does this, and it seems this is only an artifact of the way the driver today
> > matches devices that come from platform data.
> >
> > If you want it just for migration purposes, we can probably put the names
> > in the platform, but the bus-interface-* should IMHO be expressed in the
> > dma specifier, the same way we do for the designware part.
>
> The main requirement is telling which master to use for each
> channel, really, I can do without the naming (though it is very helpful
> for debugging).
>
> I don't know how to provide a specifier for eligible bus interfaces
> in some elegant way with the DMA specifier, I could of course use
> two cells containing a plain number, specifying 0 for any interface,
> 1 for ahb1 and 2 for ahb2 like that:
>
> #define BUS_AHB_ANY 0
> #define BUS_AHB1 1
> #define BUS_AHB2 2
>
> uart1: uart@101fb000 {
> compatible = "arm,pl011", "arm,primecell";
> (...)
> dmas = <&dmac1 22 BUS_AHB1>,
> <&dmac1 23 BUS_AHB1>;
> dma-names = "rx", "tx";
> };
>
> The problem is that this is just so wrong: the bus master arbitration
> is a property of the DMA controller, not the consuming device. The DMA
> controller side is where the lines to the external buses are connected,
> and it is performing the work on behalf of the device.
>
> This way the knowledge is put in the totally wrong place. People get
> the impression that this is a property of the consumer...
>
> When it comes to the actual DMA signal line that is more natural to
> have in the specifier.
Not sure about that, the approach you describe there sounds entirely
reasonable to me. The DMA specifier is not just a feature of the consumer
(the DMA slave) but of the connection between the consumer and the
controller (slave and master). This connection consists of the combination
of a request line and a bus master that is able to access the fifo
register, so it makes sense to list both here.
As far as I understand, the controller has to pick two master numbers
here: one for the memory side and one for the fifo side. The memory
side is a property of the dma engine, and that should always be the
same one, while the fifo side depends on the slave that is connected.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
