On Fri, 9 Jan 2015 11:45:29 +0000 Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Fri, Jan 09, 2015 at 12:30:36PM +0100, Jean-Francois Moine wrote: > > In my original version, the audio-ports are a bitmap of the pins, the > > bit 0 being the WS used for I2S. A fully wired tda998x would have been > > as: > > > > audio-ports = <0x03>, <0x04>, <0x09>, <0x11>; > > audio-port-names = "i2s", "spdif", "i2s", "i2s"; > > > > With the new version, it would simply become: > > > > audio-inputs = "i2s", "spdif", "i2s", "i2s"; > > How do you know which i2s inputs to enable? > > Does it make sense for the audio inputs to be mixed like that? > > You will need to enable one i2s for front L+R, and increasingly others > for the additional channels. > > I think we need to understand exactly how the 998x map I2S inputs to the > HDMI channels to avoid making a mistake with the binding; remember, the > binding isn't something that can be easily "bug fixed" at a later date > as anything we come up with now has to be supported long term by the > kernel. The DT describes the hardware configuration. A fully wired tda998x could be a chip with the audio pins connected to: - a kirkwood-like audio device with one I2S and one S/PDIF output, - two other audio devices with one I2S each. The relation between an audio device and the associated pin is done by the definition of the sound card. With S/PDIF, only one stereo channel may be sent, but with I2S, up to 4 stereo channels may be sent. These channels are extracted by the devices connected on the HDMI bus. There is no mixing. An example could be the playing of a multi-language movie: each audio channel carries one language. From the computer view, the playing application sends each language to one sound card. So, this means that the tda998x driver should check that S/PDIF and I2S are not active at the same time, and it should also do a pin OR/AND on I2S start/stop. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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
