On 13.04.2016 16:30, Rob Herring wrote:
On Mon, Apr 11, 2016 at 01:45:12PM +0200, Petr Kulhavy wrote:
Add devicetree binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MultiChannel Buffered Serial Port (McBSP)
The optional register range "dat" is not implemented at the moment. The current driver supports only DMA into RX/TX registers but no FIFO. Once the FIFO is implemented in the driver the "dat" range will be used.
Signed-off-by: Petr Kulhavy petr@barix.com
v1: initial v2: add missing TC channel in dmas properties (for compatibility with the new EDMA3 binding) remove "-audio" postfix from the compatible string remove "channel-combine" property
.../devicetree/bindings/sound/davinci-mcbsp.txt | 51 ++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/davinci-mcbsp.txt
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt b/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt new file mode 100644 index 000000000000..de45865c3863 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt @@ -0,0 +1,51 @@ +Texas Instruments DaVinci McBSP module +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This binding describes the "Multi-channel Buffered Serial Port" (McBSP) +audio interface found in some TI DaVinci processors like the OMAP-L138 or AM180x.
+Required properties: +~~~~~~~~~~~~~~~~~~~~ +- compatible : "ti,da850-mcbsp"
You list several SoCs above, but only one compatible string here. A specific compatible string per SoC please.
Hi Rob,
thank you for your feedback. I can test only on the AM1808 platform, however as far as I understand the OMAP L138 and AM1808 use the same McBSP hardware. The TI guys can give more insight here... Isn't it then redundant to define more compatible strings? Sorry for my ignorance, I just don't know the policy of defining the compatible strings.
+- reg : physical base address and length of the controller memory mapped
region(s).
+- reg-names : Should contain:
* "mpu" for the main registers (required). For compatibility with
existing software, it is recommended this is the first entry.
s/recommended/required/
Recommended is correct, but I think it make sense to drop the sentence. If the reg-names are provided then the probe() finds the resource regardless of the index. If not provided it expects it at index 0. But since we declare that the reg-names is mandatory this sentence is just confusing and should be removed.
Petr