On Wed, Mar 07, 2012 at 08:48:09PM +0530, Nitin PAI wrote:
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
I dont think that needs to be absolutely done as a part of kernel layer.
In general it really does - things get sensitive about their clocks and algorithms get sensitive about their inputs. You can often get something together that isn't joined together but usually there's a stack of simplifying assumptions in there which can break easily enough. Besides, you still need something there which exposes whatever physical interfaces userspace needs to use to program things. If userspace can just randomly interact with hardware that's a bit of a failure.
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.
This is the point. Why write a card driver? For example audio over MOST or for HDMI audio?
If the same driver works on all systems then you can just write the driver and it'll work for everyone. Nothing at the CODEC level is going to make this more or less easy, you're actually saying you've got some hardware for which you can write a generic machine driver. If that's the case you should just do that, there's some examples of this already like the fsi-hdmi driver.
Or when I have some utility in userspace to test the functionality. Wont it be better to atleast enumerate the driver and show the capabilities it supports?
You can add debugfs information to dump the capabilities and whatnot if that's useful to you...
This can help in many phases of design like emulation, bringup (doing loopback between 2 interfaces at SOC level)?
If you're doing stuff like this you're probably more than capable of tweaking things to suit your needs, and probably be prepared to accept a level of brokenness while you're at it. For example, if you've not got clocks then you won't transfer data and userspace tends to get upset with you. You'd still need to do things like set up the clocking even for the SoC loopback case, everything is going to need to agree on where the clocks come from and how they flow.
Cant we have support for all this, if not codec, somewhere else?
Honestly it just sounds like you want to write some machine drivers for your systems.