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@xxxxxxxxx>
---
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
--
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