On Wed, Mar 07, 2012 at 07:45:24PM +0530, Nitin PAI wrote:
Don't top post, and please don't do things like reordering content.
The usecase for the DSP was specifically for automotive where there is no power requirements and the audio functionality is always on. The programming of the codecs usually from the userspace. However ALSA is used for ease of using the alsalib for its various functions (applications standpoint).
Even with automotive there's *some* power limits and obviously the power control also includes things like syncing startup of the algorithms with the data path
The CPU side drivers have no dependency on the CODEC drivers, these are integrated by the machine. The SoC vendor can easily ship drivers which will work with any CODEC which works well on Linux.
The problem with just writing the machine driver and shipping it is, without any codec driver the cards wont be enumerated. Having a thin codec driver to enumerate the cards and ship it will help. (from debug and development standpoint).
Well, yes. Unless someone writes a card driver the CPU driver won't do anything useful but then without the card driver you've no idea how the system is actually wired up and the chances of it doing anything useful are close to zero. There's no getting out of the machine driver.
Another option is to just embed all the data structures in a single driver which binds to them all and selects the right data structure based on the probe information, that might be useful.
Are you suggesting to have this in the machine driver? I didnt understand this, please clarify.
No, obviously CODEC drivers should be handling by CODECs...