[alsa-devel] [PATCH] sst: Intel SST audio driver

[Mark Brown]

On Mon, Oct 18, 2010 at 08:14:16AM +0200, Takashi Iwai wrote:
> Mark Brown wrote:

> > I do have some qualms about staging but given Greg's active policing of
> > it and work to push things into the actual trees the warnings about its
> > quality and general mainlineness are much more meaningful than those for
> > experimental.  There's also the tainting of kernels, which is really
> > useful.

> But who of the end user would care about it?  It's distributor and
> developer who care.

End users I'm not so worried about in the immediate instance, it's
mostly developers and in the embedded space there's way more of them
than end users.  A lot of the time end users don't get sufficent access
to the hardware to worry about kernels (though in this case that's less
likely to be the case).

> And, is the code quality is in question, which is supposed to be
> fixable there?  Your argument against this driver doesn't sound like
> fixable.

What makes you think these problems are unfixable?  It should be fairly
straightforward to pull out the CODEC and board parts of the driver and
factor them out - as I said last night the ASoC CPU side support is a
very thin wrapper around vanilla ALSA.  The code and board sections of
the code look fairly basic and straightforward to redo within the ASoC
APIs.  I don't think this is an unreasonably difficult thing to do and
it's certainly nowhere near starting from scratch.

> So then why you do you think keeping that stuff in staging tree is OK
> while sound tree is not?  It's a question to be or not to be.
> End-users never hesitate using the staging if it works.  They don't
> notice the difference; they don't notice kernel taint either.

Like I say, I have some qualms about staging but they're pretty minor.
The idea of accepting embedded drivers which don't use ASoC seems like a
massive step back compared to where what we've got right now, and is
going down the path of accepting drivers that don't even sit within
ALSA.

Currently with Linux we're able to say that if a CPU is supported and a
CODEC is supported then we can use the two together.  That's great, and
it's good for all concerned.  If we're going to start accepting vendor
specific audio stacks we'll no longer be in a position to say that.  We
will be back to having to talk about specific combinations of devices
working together.

> The staging driver is also in upstream; distribution enables it almost
> always, no matter how the quality of each driver is.  For developers,
> the distinction is clear, of course.  But for the rest, it's not.

The biggest issues here surround developers.

> So, if you really don't want this style of implementation, you'll have
> to take an action for getting rid of the driver from staging tree.
> Otherwise others will submit the similar drivers, and they'll land
> there, too.  Then we can keep the stuff in sound or other git tree
> in another branch until the things gets sorted out.

One of the nice things about staging (indeed the key thing from my point
of view) is that Greg does from time to time remove drivers from staging
which look like they're not making any progress towards leaving staging.
In contrast drivers in the main tree generally sit there indefinitely
with minimal impetus to improve them.

> > I'm sorry I don't really understand what you're saying here.  The
> > encoder offload stuff is all totally orthogonal to the issue of using
> > the ASoC APIs.  On the CPU side the ASoC API is mostly a thin wrapper
> > around the standard ALSA API so anything that works in ALSA should slot
> > fairly readily into ASoC.  What I'd expect to see happen is that the
> > CODEC and board stuff would get pulled out and everything else would
> > stay pretty much as-is, including the DSP.

> > CPUs like OMAP (which are obviously already in the ASoC framework) also
> > support this sort of stuff, the issues with mainline for them have been
> > around the API to the DSP, though it looks like the TI stuff in staging
> > is getting sorted out now.

> Well, what I don't understand in your argument is why we must stop it
> being deployed.

Because it's not using the relevant framework at all, it's gone and
reinvented the wheel without a pressing reason to do so and this will
be very likely to create problems if the part is at all successful.  It
will also set a really bad precedent for other vendors which is even
more worrying than the specific driver.

Throughout the kernel we regularly have to push back on embedded vendors
(not just CPU vendors) who produce drivers outside the standard
frameworks and get them converted to the standard frameworks so that
they can be deployed without having to go into driver specific APIs all
the time.  Due to the fact that everything gets merged into one mainline
tree Linux has much higher standards all round with this sort of thing
than most other OSs but it takes work to enforce that.

This does include a bunch of the recently posted Intel drivers,
including this one, but there's nothing particularly unusual here.

>                  Because it doesn't match with the current design of
> the framework?  If so, a straight question must come next: can't the
> framework itself be extended to suit with such hardware?

As I wrote several times I can see no problem supporting this hardware
with current ASoC.  I'm not sure how I can be any clearer on this point.

> > I'm saying I see nothing about this hardware which should prevent it
> > working with ASoC right now.  As I have said in terms of the overall
> > structure of the device it's not really doing anything that hasn't been
> > done elsewhere.  There's stuff we'd have to bodge in the short term, but
> > only fairly small bits that can be handled fairly straightforwardly.

> OK, then we should fix this first.

This is all driver specific stuff, there's nothing that needs doing
here immediately outside of the driver that I can spot right now.