On Wed, Aug 16, 2017 at 12:39:42PM -0700, Lori Hikichi wrote: > By far the most common usage case for Cygnus is a configuration which > uses only the three i2s/tdm ports. In this case each port is assigned > a clock. Each clock has the same capabilities so there would never be > a reason change the static mapping. The usual reason would be to bring things into sync. > Now for the case when the "non-audio block" uses one of these clocks. > In this situation we will only need one i2s port because this > configuration of the chip is not audio intensive. When the system > is designed we know if this non-audio block will be in use, it is not > a runtime configurable thing. Again, a static mapping is fine. Is this limitation when the other block is in use a physical limitation or is it just a case of not seeing the use case. > At the time it did not seem necessary to make addition driver changes to > support a use case that will very likely never arise. As it turns out, > we are working on a new version of this audio block. The clocking > configuration for this new version is more complex and I am already in > the process of creating clock bindings for all this this. I am hopeful > that the driver for this new version will be applicable to Cygnus. If the clocking is more complex that seems like even more reason to not fix this in the binding, and possibly to do as I think I suggested earlier and use the common clock bindings to manage this rather than doing something custom and driver specific.
Attachment:
signature.asc
Description: PGP signature
