Thread (21 messages) 21 messages, 3 authors, 2013-08-07

[PATCH v6 2/8] ASoC: atmel: machine driver for at91sam9x5-wm8731 boards

From: Stephen Warren <hidden>
Date: 2013-07-30 21:29:23
Also in: alsa-devel, lkml

On 07/30/2013 02:45 PM, Mark Brown wrote:
On Tue, Jul 30, 2013 at 11:45:12AM -0600, Stephen Warren wrote:
quoted
On 07/30/2013 04:32 AM, Richard Genoud wrote:
quoted
quoted
+wm8731 pins: +cf
Documentation/devicetree/bindings/sound/wm8731.txt
quoted
In the Tegra bindings, I deliberately put the list of CODEC pins
into the audio complex binding rather than the CODEC binding.
That's because
You really shouldn't do this, it's not accomplishing much.
What it accomplishes is not polluting the CODEC's binding with a set
of strings that must always be supported since DT is an ABI. The
strings are isolated into the specific audio complex binding, which
might possibly become deprecated and replaced with something better
and more generic.
quoted
I'm not sure that in the long-term we want to use strings to
identify the CODEC pins, rather than using integers. By putting
the list orf CODEC pins in the audio complex binding rather than
the CODEC binding, I didn't lumber the CODEC binding with a list
of strings that it had to support forever.
How would you create the numbers - you can't use the pin numbers
since BGA type packages have alphanumeric ball identifiers?
The numbering would be arbitrary, except perhaps for packages that had
simple numeric pin IDs in which case those could be used. There would
be a file in <dt-bindings/audio/...> that defined it, which DTs would
include to create the properties, and CODEC/... drivers would include
and use whenever it needed to identify the pins, e.g. in some kind of
.of_xlate() function.
Even with numerical pin numbering ou'd need to specify some defines
for this not to be totally awful at which point you may as well
have the strings documented since you'd end up writing a table in
the binding document that's basically a mapping of pin names to
numbers,
quoted
One reason that strings are problematic is because they can't be
mixed with integers/phandles in the same property, so if we ever
end up with more generic audio bindings where the routing table
is expressed more like:
quoted
audio-routes = <&component_a $a_pin &component_b $b_pin>;
quoted
... in order to allow completely arbitrary and fully name-spaced
routing specification[1], then $a_pin and $b_pin need to be
integers not strings.
The above is going to be legibility challenged without defines at
which point the strings end up appearing in the binding document
anyway.
Yes, you'd certainly have to use defines not raw integers. The strings
wouldn't appear in the binding doc so much as the numbers.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help