On Tue, Dec 31, 2013 at 01:36:10PM +0100, Jean-Francois Moine wrote:
Mark Brown broonie@kernel.org wrote:
It would have been useful to have provided that feedback at the time rather than waiting until after it had been merged - it was in review for long enough. It would also be good to articulate the issues with
Sorry, I spent a lot of time on DPCM, and I was not yet ready to propose something when you accepted Kuninori's patch.
It'd still have been worthwhile to say that you weren't sure it'd work even if you didn't have an alternative; you could perhaps have worked on it together.
These are Linux-internal concepts which shouldn't appear in a DT binding or at the very least need definition. One thing to consider here is that these things are all about the internals of a SoC and you'd therefore expect that they would be defined separately from the card so as to avoid having to replicate information in every card using a given SoC.
Do you mean that, as DPCM cannot be in the DT, there should be a specific driver for the Cubox audio card (Marvell Armada 510 + NXP HDMI transmitter)?
I'm not saying it can't be in the DT, I'm saying that this doesn't look like the right way to do things. For example we could have a way of specifying parts of the card separately so the SoC can be referenced as a whole by the card, or we could have the internals behind the DAI hidden from the DT entirely so the DT just links the DAIs together and the SoC internals come from the implementation of the DAI devices.
If you can't figure something out a more specific binding is fine, but if you're trying to do a generic binding for everything then these things need to be considered.