On 8/22/2017 9:07 AM, Mark Brown wrote: > 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. Ok, I will create the necessary clocks to allow this to work. This will likely impact a couple of the other patches in the series, but most should be applicable. What would be the best way to have some of the other patches in this series reviewed? Should I just drop this series and resubmit new individual patches for review. -- 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
