Yes, this patch had only the machine specific controls and dai link. It also creates the audio platform devices soc-audio platform and codec
device.
It doesn't do anything else
This is preceisely the problem. As I said the machine driver should only be instantiating the machine driver. Actual physical devices should be being instnantiated using the relevant buses.
Please look at how other platforms are doing this; you should be following the same process.
Thanks, I will add the soc-audio only and move the others to core. So now this machine driver will only add machine controls and dai link along with soc-audio device. Would that suffice
What exactly is the msic CODEC? Given the references to non-specific "vendor" registers it doesn't sound like a particular CODEC driver.
Since Medfield platform is not declared yet we can't reveal the name of the codec vendor. The Moorestown codecs which we will add will not be nameless as this one and we will add as vendorversion.c format as in current codec drivers. I will replace this msic driver name once the platform is publically declared.
So you're saying this is a driver for a specific device that you're releasing under a code name? That's not what the code looks like. None of this seems terribly clever for mainline; there's too many things about these drivers don't look like what you'd expect embedded audio drivers for Linux to look like from a 1000 foot level.
This is codec from TI and I will remove the msic name now. It will now be ti-sn95031.c Does this address your concern on this issue?
~Vinod