Add peripheral-ID and DMA-channel defs, eliminate magic numbers from device-tree file

[mikehaben]

While learning to modify device-tree files for the SAMA5D27, I've had confusion and mistakes caused by the use of unexplained "magic numbers" for peripheral IDs and DMA channels. To remedy it, I propose adding definitions for these numbers in two AT91 header-files, and modifying the Atmel DTS/DTSI files to use these definitions in "clocks", "interrupts" and "dmas" items.
This pull-request includes only SAMA5D2.dtsi - if and when there is agreement on the idea being worthwhile and the implementation correct, I'll make the corresponding modifications to the other Atmel device-tree files.

[noglitch]

@mikehaben, sorry but I don't share your point of view and will not merge this change neither in our vendor tree nor in Mainline.
I'm convince that reading the product datasheet and writing the corresponding number in DT is much less prone to errors than re-defining a whole series of defines. These numbers are the ones identified as "interrupt", "IRQ line" or "peripheral identifier" in DT binding documentation for the peripheral (Documentation/devicetree/bindings/).

[mikehaben]

OK, you're the maintainer, but you work for Microchip, you probably know the SAMA5 inside-out. I can only suggest that it would be helpful for those like me, less-familiar with the SAMA5 product line, at least to have some comment in the DTS/DTSI files that the "magic" numbers correspond to peripheral-ID and DMA-channel, and that their definitions can be found on pages 203-206 and 770-773 of the (>3000-page!) SAMA5D2-series datasheet. Documentation is a fine thing, but self-documenting code is better.

[RobertCNelson]

@mikehaben i'd still post it to: https://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[alexandrebelloni]

It won't apply as-is because the clock binding changed. I also doubt the usefulness of hiding the peripheral ids behind a macr as the lookup in the datasheet is really simple and this is only used in the dtsi that is already provided for the end user.

[mikehaben]

@alexandrebelloni : my intention was to use these definitions not only in the base-level DTSI files, but also in the top-level DTS files for the various evaluation-kit boards, so that someone creating a new device-tree for custom a PCB would have a clear indication of what these numbers referred to, without having to master the entire SAMA5D2 datasheet and device-tree document set. It is generally considered poor practice to use magic numbers in C code, and it seems to me that the reasons behind that opinion apply equally to device-tree files.