On Wed, Jan 14, 2015 at 12:50:56PM +0000, Mark Brown wrote: > Trying to hook up a controller that doesn't natively support this format > to a device that uses it is definitely tricky, as well as describing the > physical hookup we also need to worry about how things look to userspace > - it's ideally going to want a single multi-channel audio stream. Trying to get the synchronisation correct for proper surround audio reproduction would also be interesting. I suspect that userspace would have to be taught specifically about a hardware setup like this - in order to ensure that the slave I2S blocks are ready before the master starts outputting the I2S clocks. I'm /not/ that thrilled with the whole idea; I'd much rather suggest that we should concentrate on sane setups, but we know that hardware engineers do create some silly setups "because they can". > I think from a binding point of view we need a way to say "this endpoint > on the link is constructed from these DAIs on the device side" and say > if this is TDM or multi-data, and what's driving the clocks. This seems to favour the "one DT port for I2S" model - possibly with multiple endpoints for each I2S channel (if desired). There's nothing in that model which would prevent having one end point for all four channels. To put that another way, we can remain flexible. Maybe we should document the binding indicating that for I2S, one port and one endpoint connected to one I2S block which supplies all I2S channels is the preferred model, but others are permitted but not necessarily guaranteed to work correctly. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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
