On 05/16/2012 03:16 PM, Jassi Brar wrote: > On 17 May 2012 01:12, Arnd Bergmann <arnd@xxxxxxxx> wrote: ... >> More importantly, you make it very hard to add devices in a board file >> to a dma controller that already has descriptions for some channels, >> because you cannot easily extend the chan-map unless you rewrite all of it. >> > I am not sure I understand the point. Ah yes, Arnd has a good point. If the DMA request routing information is in each client node, then it's trivial to add DMA clients to board files; you just put the board-specific nodes and properties in the board file, and there's no possibility of conflicts; you aren't having to add to or override any existing property in the base SoC file. (As background, most ARM device trees are separated out into 1 file defining all the SoC devices e.g. soc.dtsi, and a separate file for each board e.g. board.dts, which includes the SoC file.) Now, the DMA node for an on-SoC DMAC would be in soc.dtsi. Typically, the DMAC is connected to many on-SoC devices, and hence soc.dtsi would need to specify the routing information for all those devices to avoid duplicating it in every board.dts. Now, if you have some DMA requests that go off-SoC, the board.dts file might want to add to the routing table to indicate what clients connect to those DMA requests. However, there's no way in the device tree compiler right now to add to a property; you can only completely replace it. That would entail duplicating the entire routing information from soc.dtsi into each board.dts that wanted to add to it - a bad situation. Splitting the routing information into chunks in the client nodes avoids this issue entirely. -- 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
