On Mon, Jul 28, 2014 at 08:54:13AM -0400, jonsmirl@gmail.com wrote:
On Mon, Jul 28, 2014 at 7:20 AM, Mark Brown broonie@kernel.org wrote:
On Mon, Jul 28, 2014 at 08:24:39AM +0200, Lars-Peter Clausen wrote:
Cc ASoC maintainers.
Jon, you should really know to CC maintainers.
Are the all CC'd now? I thought the ALSA list was sufficient.
No, you should always CC maintainers - never assume anything sent only to a mailing list is going to be seen or read, certainly not with any degree of promptness.
on-chip codec - it is ADC/DAC with FIFIO directly attached. There is no separate bus. on-chip codec supports things like mic1, mic2, line in, line out, hp out. Most boards populate only a subset of the jacks. Right now the device driver makes a dummy codec and internally creates a card and links everything together.
http://git.elopez.com.ar/linux/src/abc050fbbaa5302b76ac585954cd207961fc9159/...
Then someone came along and wanted to add a MAX9768. We're stuck because the way the driver is built it doesn't support the external MAX9768 codec driver. MAX9768 is just an amp with I2C control of volume.
This doesn't seem hard - just extend the binding for the device/card to allow auxiliary devices to be specified (the matching code supports that).
So how should the device tree look for no external amp? Right now there is just a device node and the driver makes a card/dummy-codec internally.
Your CODEC shouldn't be a completely dummy one, at a minimum it has some external pins which need to be described and documented.
How should the device tree look when there is an external amp? Maybe this amp should just be a chip of the device node?
Just the same as any other card - allow a phandle to be provided to the amplifier.
How should the various jack populations be handled in the device tree?
Assuming "jack populations" are DAPM links just do it the same way as anything else and use snd_soc_of_parse_audio_routing().