On Sun, Oct 17, 2010 at 01:14:56PM +0200, Takashi Iwai wrote:
Mark Brown wrote:
I'm really concerned about this idea. Allowing embedded vendors to push drivers into mainline which don't work with the standard frameworks for what they're doing sets a bad precedent which makes it much harder to push back on other vendors who also want to push their own stacks.
We've had (and still have) many pre-ASoC drivers, but the _maintenance_ cost of them were relatively small from the global sound-tree POV. As long as the driver is self-contained, there is no big hustle for maintenance.
You're only seeing what goes on upstream. Outside of upstream you'll usually find a lot of people doing a lot of redundant work to get their boards working, code that never finds its way upstream and quite often gets done fairly reptitvely. It's no hassle upstream because nobody ever bothers upstreaming anything much after the original driver but for system integrators trying to use the driver on their platform which differs from the vendor reference and distributors trying to support multiple machines it's a different kettle of fish.
Of course, the further _development_ is a totally different question. If the development diverges to too many different h/w components, a certain framework would be certainly needed. This is how ASoC was introduced and developed by Liam and you.
This is pretty much a given in the embedded marketplace if a CPU is at all successful - apart from anything else the embedded audio state of the art is on much quicker cycles than most components so the components which are leading edge today may not make quite so much sense in a year. The hardware is all constructed with standard interfaces between the parts (though there are no standards at all for the control of the devices) so these sorts of changes are very straightforward for the hardware guys to do, meaning that the software stack needs to be similarly modularised.
So, what I'm trying to say is:
- we can accept the present solution in a certain level, rather then just refusing it
I think this is the wrong approach. I think this says to embedded CPU vendors that they can go off and reinvent the wheel with their own embedded audio stacks. If all the CPU vendors already in mainline were to have gone down this route we'd have sixteen different ways to add support for a new board right now, with lots of redundancy in the CODEC side between them and each with a different set of features and limitations in how you can customise for your board (especially if you want to get code upstream). That wouldn't be terribly pleasant, it'd put Linux's audio support right back where all the other embedded OSs are.
Please bear in mind that we've already seen similar stacks from other vendors (Marvell and TI being the main ones I've been aware of) getting replaced as part of mainlining, and a couple of others I'm aware of but NDAed with doing the same thing. If you're saying you'll accept this approach and bypass the existing embedded audio stack then the pressure on vendors to do the right thing and move over to the Linux embedded audio stack is greatly reduced.
- it can be taken into the main sound tree as an EXPERIMENTAL one, instead of keeping it in staging tree forever
I definitely think EXPERIMENTAL is too weak a pushback - I can't see that stopping anyone going out there and saying they have standard audio drivers in mainline which is the check box people are looking for. Even distributors routinely enable EXPERIMENTAL.
Like I say, this is not just a concern for this driver it's also a big worry with other CPU vendors and with future Intel chips.
These don't mean that the current driver will be necessarily regarded as the standard. We might need to end up developing the new better standard framework for similar devices. It doesn't conflict with merging the merge action.
We already have an existing framework for embedded audio devices. We may want to extend or improve it but I don't see a pressing need to develop a new one. Whenever we end up with two different ways of doing the same thing it's not great, it just makes for confusion and redundancy.