Geoffrey Wossum <[email protected]> wrote:
> For anyone that's interested, there's patches to add ALSA System-on-Chip sound
> platform drivers for the AVR32 being discussed on the alsa-devel mailing list
> right now.
Hmm. For something that depends on a metric shitload of middle layers,
it is surprisingly large...
I have to admit I don't understand the current sound situation at all.
With this driver, we now have:
* An OSS driver for the AP7000 Audio Bitstream DAC
* A "regular" ALSA driver for the AC97C (not based on ASoC)
* Two different "generic" AC97 layers: one in sound/pci/ac97 and one
in sound/soc/ac97 (the AC97C driver uses the former)
* An i2s driver for the AT73C213 chip using the SSC controller and SPI
* Another SSC driver based on the ASoC layer
* Some sort of "AT32 PCM" layer which apparently can only be used
with the SSC controller
* The above two being essentially identical to similar drivers for
AT91
Can someone please help me out here? In particular, what is ASoC and
why should I want to use it?
Haavard
On Thursday 05 June 2008 09:22:06 am Haavard Skinnemoen wrote:
> Geoffrey Wossum <[email protected]> wrote:
> > For anyone that's interested, there's patches to add ALSA System-on-Chip
> > sound platform drivers for the AVR32 being discussed on the alsa-devel
> > mailing list right now.
>
> Hmm. For something that depends on a metric shitload of middle layers,
> it is surprisingly large...
Partly because the code attempts to handle every contingency an application
might throw at (different sample rates, formats, clocking options, etc.).
Partly because it also has some concern for power management.
> I have to admit I don't understand the current sound situation at all.
> With this driver, we now have:
To paraphrase Andy Tanenbaum, the great thing about standards is there's so
many to choose from.
> * An OSS driver for the AP7000 Audio Bitstream DAC
OSS <shudder>
> * A "regular" ALSA driver for the AC97C (not based on ASoC)
I don't have an AC97 CODEC.
> * An i2s driver for the AT73C213 chip using the SSC controller and SPI
Strongly coupled to the AT73C213, not the chip I'm using, although it did
provide a good example of working code. This is where I figured out I needed
to use big endian.
> * Some sort of "AT32 PCM" layer which apparently can only be used
> with the SSC controller
This IS sort of confusing. It's really more of a generic SSC / PDC driver
than a "PCM layer". Its existence is largely an artifact of it being in the
AT91 ASoC platform code, which I "ported" to get the AT32 platform code. Its
existence in the AT91 platform driver is an artifact of the AT91 driver being
based on the PXA platform driver. In other words, I'm not really the one to
explain the design rationale behind it.
> * The above two being essentially identical to similar drivers for
> AT91
Yes, I didn't particularly like making the AT32 code almost exactly like the
AT91 code, and most of the differences are due to changes in some kernel APIs
rather than the peripherals really being different (BTW, the changes in the
AT32 are an improvement!). But I needed an AT32 layer quickly, and I don't
have any AT91 hardware, so I couldn't really go mucking about in the AT91
code since I wouldn't be able to test it. I don't feel especially bad,
though, since at91_mci.c and atmel-mci.c commit essentially the same sin.
> Can someone please help me out here? In particular, what is ASoC and
> why should I want to use it?
Number 1 reason (for me): The only driver for my CODEC (WM8510) was an ASoC
driver. Using sound system other than ASoC would require porting / rewriting
this driver. Since an AT91 ASoC platform driver already existed, and would
be virtually the same as the AT32 platform driver, this was the best choice
for getting sound quickly. So this essentially boils down to code reuse.
And if we switch CODEC's for some reason, it's less work.
Another highly compelling reason: power consumption. Only powers up parts of
the audio pathway that are currently needed.
For more reasons: http://alsa-project.org/main/index.php/ASoC
Legal notice: I received no compensation for this endosement :)
---
Geoffrey
On Thu, Jun 05, 2008 at 04:22:06PM +0200, Haavard Skinnemoen wrote:
> I have to admit I don't understand the current sound situation at all.
> With this driver, we now have:
> * A "regular" ALSA driver for the AC97C (not based on ASoC)
> * Two different "generic" AC97 layers: one in sound/pci/ac97 and one
> in sound/soc/ac97 (the AC97C driver uses the former)
There is AC97 support in ASoC but there's no sound/soc/ac97? Briefly,
the generic ALSA AC97 support is focused on handling standard AC97 parts
without additional features while the ASoC layer requires more per-board
setup but supports codecs with large extensions to the AC97 standard
such as the additional of secondary I2S interfaces that can't readily be
accomodated in the vanilla AC97 driver.
For systems using only AC97 codecs with only small non-standard features
the vanilla AC97 driver provides a turnkey solution with no machine
specific code at all. It should be possible to implement it in terms of
ASoC but nobody has tried yet and it's not 100% clear that it's worth
the code churn.
> * An OSS driver for the AP7000 Audio Bitstream DAC
> * An i2s driver for the AT73C213 chip using the SSC controller and SPI
These drivers will be working in the way people were doing embedded
audio prior to ASoC. Support for each system was provided by a
monolithic driver which implemented support for the codec, the audio
controller on the SoC and any other components on the board. This
resulted in a lot of redundancy since multiple systems using the same
components would find it hard to share code for them and the
abstractions providing the reuse that did exist often ended up getting
done multiple times.
ASoC improves code reuse here by separating out the support for codecs
and SoC CPUs from the machine drivers, providing a layer for gluing them
together and fitting them into the ALSA core. An ASoC machine driver
can be little more than the equivalent of "I have a codec of this type
connected to this I2S interface on my CPU and clocked in this way" but
it can support more complex scenarios.
It also provides a generic power management infrastructure for these
systems, allowing unused parts of the audio subsystem to be put into low
power states when they are not being used as part of an active audio
path.
> * Another SSC driver based on the ASoC layer
> * Some sort of "AT32 PCM" layer which apparently can only be used
> with the SSC controller
> * The above two being essentially identical to similar drivers for
> AT91
These drivers provide the CPU side support for the system within ASoC.
I suspect from what you are saying that the two Atmel ASoC platform
driver sets could be implemented with a common core with some per-CPU
glue to plug them together but I've never looked at either platform in
sufficient detail.
The PCM layer in these drivers represents the DMA controller part of the
SoC hardware - the DMA control is split out in ASoC because most SoCs
have generic DMA engines which are shared between multiple audio
interface controllers (eg, I2S and AC97) so there's no point in
repeating the code to glue them into ALSA DMA.
> Can someone please help me out here? In particular, what is ASoC and
> why should I want to use it?
Hopefully I answered that above. There's a more detailed overview in
Documentation/sound/alsa/soc/overview.txt:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/sound/alsa/soc/overview.txt;h=1e4c6d3655f2089c875ff381759ebd5528fe2ad3;hb=HEAD
Geoffrey Wossum <[email protected]> wrote:
> On Thursday 05 June 2008 09:22:06 am Haavard Skinnemoen wrote:
> > Geoffrey Wossum <[email protected]> wrote:
> > > For anyone that's interested, there's patches to add ALSA System-on-Chip
> > > sound platform drivers for the AVR32 being discussed on the alsa-devel
> > > mailing list right now.
> >
> > Hmm. For something that depends on a metric shitload of middle layers,
> > it is surprisingly large...
>
> Partly because the code attempts to handle every contingency an application
> might throw at (different sample rates, formats, clocking options, etc.).
> Partly because it also has some concern for power management.
But if the low-level driver has to handle all that, what are all the
middle layers for?
> > I have to admit I don't understand the current sound situation at all.
> > With this driver, we now have:
>
> To paraphrase Andy Tanenbaum, the great thing about standards is there's so
> many to choose from.
Heh.
> > * An OSS driver for the AP7000 Audio Bitstream DAC
> OSS <shudder>
Well, I did try to implement it as an ALSA driver, but a) it didn't
work, b) it was impossible to debug, and c) it ended up at about 10x
the size of the OSS driver. So I figured it wasn't really worth the
trouble.
> > * A "regular" ALSA driver for the AC97C (not based on ASoC)
> I don't have an AC97 CODEC.
>
>
> > * An i2s driver for the AT73C213 chip using the SSC controller and SPI
> Strongly coupled to the AT73C213, not the chip I'm using, although it did
> provide a good example of working code. This is where I figured out I needed
> to use big endian.
Right, splitting out the i2s-related bits would have been a good thing.
> > * Some sort of "AT32 PCM" layer which apparently can only be used
> > with the SSC controller
> This IS sort of confusing. It's really more of a generic SSC / PDC driver
> than a "PCM layer". Its existence is largely an artifact of it being in the
> AT91 ASoC platform code, which I "ported" to get the AT32 platform code. Its
> existence in the AT91 platform driver is an artifact of the AT91 driver being
> based on the PXA platform driver. In other words, I'm not really the one to
> explain the design rationale behind it.
>
>
> > * The above two being essentially identical to similar drivers for
> > AT91
> Yes, I didn't particularly like making the AT32 code almost exactly like the
> AT91 code, and most of the differences are due to changes in some kernel APIs
> rather than the peripherals really being different (BTW, the changes in the
> AT32 are an improvement!).
Hmm...I take it you're talking about the SSC driver? That is supposed
to be usable on AT91 as well, so perhaps the right thing to do is
porting the AT91 driver over to use it.
I see you've added a few SSC-related constants...those should probably
go into include/linux/atmel-ssc.h.
> But I needed an AT32 layer quickly, and I don't
> have any AT91 hardware, so I couldn't really go mucking about in the AT91
> code since I wouldn't be able to test it. I don't feel especially bad,
> though, since at91_mci.c and atmel-mci.c commit essentially the same sin.
Yeah, I guess you're right. I do have a long-term goal merging those
two drivers, but it will be a bit difficult because the DMA interface
is quite different.
> > Can someone please help me out here? In particular, what is ASoC and
> > why should I want to use it?
>
> Number 1 reason (for me): The only driver for my CODEC (WM8510) was an ASoC
> driver. Using sound system other than ASoC would require porting / rewriting
> this driver. Since an AT91 ASoC platform driver already existed, and would
> be virtually the same as the AT32 platform driver, this was the best choice
> for getting sound quickly. So this essentially boils down to code reuse.
> And if we switch CODEC's for some reason, it's less work.
That's certainly a good reason, though I don't understand why reusing
code isn't important on non-SoC platforms.
> Another highly compelling reason: power consumption. Only powers up parts of
> the audio pathway that are currently needed.
Another good reason, but again I don't understand why power management
isn't important on PCs.
> For more reasons: http://alsa-project.org/main/index.php/ASoC
The reasons are all good, but yet again, I don't understand why those
design goals aren't appropriate for ALSA as a whole.
Haavard
Mark Brown <[email protected]> wrote:
> On Thu, Jun 05, 2008 at 04:22:06PM +0200, Haavard Skinnemoen wrote:
>
> > I have to admit I don't understand the current sound situation at all.
> > With this driver, we now have:
> > * A "regular" ALSA driver for the AC97C (not based on ASoC)
> > * Two different "generic" AC97 layers: one in sound/pci/ac97 and one
> > in sound/soc/ac97 (the AC97C driver uses the former)
>
> There is AC97 support in ASoC but there's no sound/soc/ac97?
Whoops, that should have been sound/soc/codecs/ac97.c.
> Briefly,
> the generic ALSA AC97 support is focused on handling standard AC97 parts
> without additional features while the ASoC layer requires more per-board
> setup but supports codecs with large extensions to the AC97 standard
> such as the additional of secondary I2S interfaces that can't readily be
> accomodated in the vanilla AC97 driver.
Ok, but why write a whole new driver instead of extending the existing
one to support the missing features?
> For systems using only AC97 codecs with only small non-standard features
> the vanilla AC97 driver provides a turnkey solution with no machine
> specific code at all. It should be possible to implement it in terms of
> ASoC but nobody has tried yet and it's not 100% clear that it's worth
> the code churn.
Sounds like it could be solved by a thin adapter layer on top of a more
flexible AC97 driver.
> > * An OSS driver for the AP7000 Audio Bitstream DAC
> > * An i2s driver for the AT73C213 chip using the SSC controller and SPI
>
> These drivers will be working in the way people were doing embedded
> audio prior to ASoC. Support for each system was provided by a
> monolithic driver which implemented support for the codec, the audio
> controller on the SoC and any other components on the board. This
> resulted in a lot of redundancy since multiple systems using the same
> components would find it hard to share code for them and the
> abstractions providing the reuse that did exist often ended up getting
> done multiple times.
Right, so ALSA really did need a common codec abstraction.
> ASoC improves code reuse here by separating out the support for codecs
> and SoC CPUs from the machine drivers, providing a layer for gluing them
> together and fitting them into the ALSA core. An ASoC machine driver
> can be little more than the equivalent of "I have a codec of this type
> connected to this I2S interface on my CPU and clocked in this way" but
> it can support more complex scenarios.
But why is it only useful on SoCs?
> It also provides a generic power management infrastructure for these
> systems, allowing unused parts of the audio subsystem to be put into low
> power states when they are not being used as part of an active audio
> path.
Again, that sounds very useful in general, not only for SoCs. Power
consumption is perhaps _more_ important on embedded systems than PCs,
but I very much doubt that anyone would complain if their laptop
battery lasted a few minutes longer ;-)
> > * Another SSC driver based on the ASoC layer
> > * Some sort of "AT32 PCM" layer which apparently can only be used
> > with the SSC controller
> > * The above two being essentially identical to similar drivers for
> > AT91
>
> These drivers provide the CPU side support for the system within ASoC.
> I suspect from what you are saying that the two Atmel ASoC platform
> driver sets could be implemented with a common core with some per-CPU
> glue to plug them together but I've never looked at either platform in
> sufficient detail.
The SSC hardware is essentially identical on the two platforms, and
there's also a common driver of sorts in drivers/misc/atmel-ssc.c. So
it shouldn't be too hard to have them share the same i2s driver.
This is why I think grouping drivers based on platform, bus type or
whatever is just wrong. It prevents using the same drivers on identical
hardware that just happens to be integrated on a different type of chip
or wired up to a different kind of bus.
Now, I'm not sure what kind of changes that were necessary to make the
at91 driver work on avr32, but if it was only about changing it to use
the atmel-ssc driver, maybe we should just replace the existing at91
driver with the new at32 driver?
> The PCM layer in these drivers represents the DMA controller part of the
> SoC hardware - the DMA control is split out in ASoC because most SoCs
> have generic DMA engines which are shared between multiple audio
> interface controllers (eg, I2S and AC97) so there's no point in
> repeating the code to glue them into ALSA DMA.
Ok, so why not call it "DMA" or something instead of "PCM"?
Btw, there are chips that use a different kind of DMA interface to the
SSC, so I think the split makes sense. I just think the name "at32-pcm"
is confusing. "atmel-ssc-pdc" would have been much better.
> > Can someone please help me out here? In particular, what is ASoC and
> > why should I want to use it?
>
> Hopefully I answered that above. There's a more detailed overview in
> Documentation/sound/alsa/soc/overview.txt:
Yes, thanks a lot for explaining. I think the design goals of the ASoC
layer makes sense, it's just that I don't see anything inherently
SoC-specific about them.
Haavard
At Thu, 5 Jun 2008 18:24:09 +0200,
Haavard Skinnemoen wrote:
>
> > Number 1 reason (for me): The only driver for my CODEC (WM8510) was an ASoC
> > driver. Using sound system other than ASoC would require porting / rewriting
> > this driver. Since an AT91 ASoC platform driver already existed, and would
> > be virtually the same as the AT32 platform driver, this was the best choice
> > for getting sound quickly. So this essentially boils down to code reuse.
> > And if we switch CODEC's for some reason, it's less work.
>
> That's certainly a good reason, though I don't understand why reusing
> code isn't important on non-SoC platforms.
Of course, important. And it's actually done in a different way...
> > Another highly compelling reason: power consumption. Only powers up parts of
> > the audio pathway that are currently needed.
>
> Another good reason, but again I don't understand why power management
> isn't important on PCs.
Of course, important. And it's actually done in a different way...
> > For more reasons: http://alsa-project.org/main/index.php/ASoC
>
> The reasons are all good, but yet again, I don't understand why those
> design goals aren't appropriate for ALSA as a whole.
Mostly because of the difference of the target hardware design. From
the very beginning, ASoC is designed specifically for mobile devices
while ALSA is designed as a more generic abstraction.
Ideally, more fusion would be possible, but practically it's not
always worth. I don't think you want to merge codes between ext3 and
reiserfs although both have similar "design goals" :)
Takashi
Takashi Iwai <[email protected]> wrote:
> Of course, important. And it's actually done in a different way...
[...]
> Of course, important. And it's actually done in a different way...
But why?
> Ideally, more fusion would be possible, but practically it's not
> always worth. I don't think you want to merge codes between ext3 and
> reiserfs although both have similar "design goals" :)
Still, both plug into the same VFS layer...
Reiser4 tried to invent its own plugin system. IIRC that didn't fly
particularly well.
Haavard
On Thursday 05 June 2008 11:24:09 am Haavard Skinnemoen wrote:
> Geoffrey Wossum <[email protected]> wrote:
> > On Thursday 05 June 2008 09:22:06 am Haavard Skinnemoen wrote:
> > > Geoffrey Wossum <[email protected]> wrote:
> > To paraphrase Andy Tanenbaum, the great thing about standards is there's
> > so many to choose from.
>
> Heh.
I quote that a lot. Along with Philip K. Dicks's "Sometimes an appropriate
response to reality is to go insane."
> Hmm...I take it you're talking about the SSC driver? That is supposed
> to be usable on AT91 as well, so perhaps the right thing to do is
> porting the AT91 driver over to use it.
Yes, the SSC code. It'd be cool if it abstracted out even more, but I
understand the difficulties in making that happen.
> I see you've added a few SSC-related constants...those should probably
> go into include/linux/atmel-ssc.h.
I wasn't sure if having these in atmel-ssc.h fit with ya'lls plans for it, but
if it does, great.
> > But I needed an AT32 layer quickly, and I don't
> > have any AT91 hardware, so I couldn't really go mucking about in the AT91
> > code since I wouldn't be able to test it. I don't feel especially bad,
> > though, since at91_mci.c and atmel-mci.c commit essentially the same sin.
>
> Yeah, I guess you're right. I do have a long-term goal merging those
> two drivers, but it will be a bit difficult because the DMA interface
> is quite different.
The PDC interface is closer (if not exactly the same). One issue is the SSC
interface, which you have said could be used on the AT91. After that, the
main differences are that the DMA buffer has to be allocated differently, and
the mmap() implementation is different.
> That's certainly a good reason, though I don't understand why reusing
> code isn't important on non-SoC platforms.
Please don't take my answer as authoritative, but I think it's because on a
typical PC the exact CODEC being used tends to be hidden from you. And you
normally don't use I2S or PCM directly. A PC sound card is more of a black
box.
> Another good reason, but again I don't understand why power management
> isn't important on PCs.
It is important, and becoming more important all the time. I think the main
reasons this isn't a priority on a PC right now are:
- I think PC sound cards tend to be black boxes regarding power consumption,
especially those white box cards you can get at Fry's and similar places.
- A few extra mA aren't as important when you're plugged in, or you have a
laptop, which has a honkin' big battery compared to a PDA type device
- A few extra mA are dwarfed by other things in a PC, like the processor. My
Intel T7200 burns 34 W at full tilt. The AT32AP7000 is going to be something
like, what, 250 mW? Even throttled all the way down my T7200 is going to be
13 W. Turning off all or part of the CODEC and saving 15 - 30 mW is a lot
bigger deal on the AVR32 than it would be on my laptop.
- As you say, there is more code due to the power management, which requires
modifying a lot of working drivers, for little benefit in the forseeable
future.
---
Geoffrey
At Thu, 5 Jun 2008 19:06:57 +0200,
Haavard Skinnemoen wrote:
>
> Takashi Iwai <[email protected]> wrote:
> > Of course, important. And it's actually done in a different way...
> [...]
> > Of course, important. And it's actually done in a different way...
>
> But why?
>
> > Ideally, more fusion would be possible, but practically it's not
> > always worth. I don't think you want to merge codes between ext3 and
> > reiserfs although both have similar "design goals" :)
>
> Still, both plug into the same VFS layer...
Read as ALSA is VFS layer and ASoC is ext3 while another sound driver
is reiserfs (or vice versa). Both have journals. Then would you ask
why ext3 doesn't reuse the journal codes of reiserfs? Or, do you
suggest to add journal codes into VFS layer?
Of course, the situation is different than fs. The fact is that both
ASoC and other drivers have been developed in a parallel way although
both use ALSA as backends.
ASoC is a higher and easier abstraction layer specific for the mobile
devices and it has the features like power-saving in its middle
layer. The ASoC drivers are top layers over ASoC over ALSA.
Meanwhile, other ALSA drivers directly communicate with ALSA layer.
Some of them have similar features like ASoC, but it doesn't use ASoC
code because it was implemented before ASoC and differently from
ASoC.
> Reiser4 tried to invent its own plugin system. IIRC that didn't fly
> particularly well.
ASoC is just a middle layer. Not comparable with plugins.
Takashi
Geoffrey Wossum <[email protected]> wrote:
> On Thursday 05 June 2008 11:24:09 am Haavard Skinnemoen wrote:
> > Geoffrey Wossum <[email protected]> wrote:
> > > On Thursday 05 June 2008 09:22:06 am Haavard Skinnemoen wrote:
> > > > Geoffrey Wossum <[email protected]> wrote:
>
> > > To paraphrase Andy Tanenbaum, the great thing about standards is there's
> > > so many to choose from.
> >
> > Heh.
>
> I quote that a lot. Along with Philip K. Dicks's "Sometimes an appropriate
> response to reality is to go insane."
That's a good one too.
> > Hmm...I take it you're talking about the SSC driver? That is supposed
> > to be usable on AT91 as well, so perhaps the right thing to do is
> > porting the AT91 driver over to use it.
>
> Yes, the SSC code. It'd be cool if it abstracted out even more, but I
> understand the difficulties in making that happen.
Ok. Since the SSC module is a multi-purpose module, the SSC driver was
designed to be as thin and flexible as possible. So we just added some
platform_driver glue and a request/free interface and left everything
else up to the higher-level driver.
I suppose we could add a few more helper functions. Suggestions are
welcome.
> > I see you've added a few SSC-related constants...those should probably
> > go into include/linux/atmel-ssc.h.
>
> I wasn't sure if having these in atmel-ssc.h fit with ya'lls plans for it, but
> if it does, great.
I think the constants look very useful in general, so it makes sense to
put them in atmel-ssc.h. Doing i2s is pretty much all the plans we have
for it at the moment, but if someone comes up with a different use case,
that would be cool too.
> > > But I needed an AT32 layer quickly, and I don't
> > > have any AT91 hardware, so I couldn't really go mucking about in the AT91
> > > code since I wouldn't be able to test it. I don't feel especially bad,
> > > though, since at91_mci.c and atmel-mci.c commit essentially the same sin.
> >
> > Yeah, I guess you're right. I do have a long-term goal merging those
> > two drivers, but it will be a bit difficult because the DMA interface
> > is quite different.
>
> The PDC interface is closer (if not exactly the same).
The MMC controller on AP7000 isn't hooked up to the PDC, it's hooked up
to a more complex DMA controller. I'm working on extending the DMA
subsystem to handle peripheral DMA, but I had to delay that work for
some time now. Hopefully I'll get back to working on it very soon.
> One issue is the SSC
> interface, which you have said could be used on the AT91. After that, the
> main differences are that the DMA buffer has to be allocated differently, and
> the mmap() implementation is different.
Oh. That's a bit surprising to me...can you elaborate on the
differences?
> > That's certainly a good reason, though I don't understand why reusing
> > code isn't important on non-SoC platforms.
>
> Please don't take my answer as authoritative, but I think it's because on a
> typical PC the exact CODEC being used tends to be hidden from you. And you
> normally don't use I2S or PCM directly. A PC sound card is more of a black
> box.
But I would have thought that if you have a PC sound card with an
on-board i2s bus and a standard codec, you could create a board driver
by simply hooking the different parts together, possibly with a custom
i2s bus driver?
That will still make it look like a black box to the user (just load
the card driver, and it will take care of everything), but you can
share code between the PC platform and various embedded platforms.
> > Another good reason, but again I don't understand why power management
> > isn't important on PCs.
>
> It is important, and becoming more important all the time. I think the main
> reasons this isn't a priority on a PC right now are:
> - I think PC sound cards tend to be black boxes regarding power consumption,
> especially those white box cards you can get at Fry's and similar places.
Right...so it's a matter of documentation. I suspect those white box
cards still use cheap, standard hardware under the hood, though maybe
that fact is pretty well hidden.
> - A few extra mA aren't as important when you're plugged in, or you have a
> laptop, which has a honkin' big battery compared to a PDA type device
> - A few extra mA are dwarfed by other things in a PC, like the processor. My
> Intel T7200 burns 34 W at full tilt. The AT32AP7000 is going to be something
> like, what, 250 mW? Even throttled all the way down my T7200 is going to be
> 13 W. Turning off all or part of the CODEC and saving 15 - 30 mW is a lot
> bigger deal on the AVR32 than it would be on my laptop.
True, but if you combine it with better power management in other
subsystems as well, the end result may be worthwhile. In any case, it
certainly doesn't _hurt_ to have better power management on PC sound
cards.
> - As you say, there is more code due to the power management, which requires
> modifying a lot of working drivers, for little benefit in the forseeable
> future.
Don't get me wrong -- I didn't intend to NAK the driver, and I
certainly appreciate that you took the effort to implement proper power
management. I just felt a bit confused about the whole ASoC thing. I
think I see why it is useful now, though I still don't really
understand why it's limited to SoC devices.
What really bothers me about the ASoC layer is that it is a framework
designed for embedded systems only. One of the great things about Linux
on embedded systems is that you get to use a lot of code that has been
thoroughly tested on commodity PC hardware. When you introduce
frameworks specifically for embedded systems, you throw that advantage
away. For example, a particular AC97 codec chip may be used with a
different driver depending on whether it's soldered on a PC motherboard
or some embedded board. That feels wrong to me.
Haavard
On Thu, Jun 05, 2008 at 06:40:37PM +0200, Haavard Skinnemoen wrote:
> Mark Brown <[email protected]> wrote:
> > For systems using only AC97 codecs with only small non-standard features
> > the vanilla AC97 driver provides a turnkey solution with no machine
> > specific code at all. It should be possible to implement it in terms of
> > ASoC but nobody has tried yet and it's not 100% clear that it's worth
> > the code churn.
> Sounds like it could be solved by a thin adapter layer on top of a more
> flexible AC97 driver.
That's pretty much exactly what sound/soc/codecs/ac97.c is doing - it
provides a codec driver which lets a machine connect a SoC AC97
controller driver to the generic ALSA AC97 layer, it doesn't actually
have any code of its own.
It can't completely replace the generic AC97 layer at the minute but the
major issue with that currently is the more general one of providing a
machine driver for a standard AC97 subsystem and then working out when
to use it rather than a system-specific one.
> > ASoC improves code reuse here by separating out the support for codecs
> > and SoC CPUs from the machine drivers, providing a layer for gluing them
> > together and fitting them into the ALSA core. An ASoC machine driver
> > can be little more than the equivalent of "I have a codec of this type
> > connected to this I2S interface on my CPU and clocked in this way" but
> > it can support more complex scenarios.
> But why is it only useful on SoCs?
It's more a case of the way people want to program things than anything
else - if someone were to write the relevant drivers for things other
than SoC systems then ASoC would quite happily glue everything together,
the core really doesn't care about what the drivers are actually
controlling.
What's more of an issue for doing this is that the programming model
that ASoC offers really only fits well with decomposed systems where you
have discrete components offering meaningful control. That is the rule
in embedded systems but is much less often the case in other
environments and the further you get from that the more you'd have to
shoehorn things to fit into the ASoC model. If the ASoC model is a good
fit then people may want to use it but it won't be helpful for everyone.
That said, there are also problems due to the current code predating the
device model that prevent you having more than one ASoC card in your
system. There is a new version of ASoC in the asoc-v2-dev branch of
git://opensource.wolfsonmicro.com/linux-2.6-asoc which addresses this
but it's quite invasive so it's not a trivial merge. This is all at the
implementation detail level rather than the core concepts level, though,
and should get resolved in the forseeable future.
> > It also provides a generic power management infrastructure for these
> > systems, allowing unused parts of the audio subsystem to be put into low
> > power states when they are not being used as part of an active audio
> > path.
> Again, that sounds very useful in general, not only for SoCs. Power
> consumption is perhaps _more_ important on embedded systems than PCs,
> but I very much doubt that anyone would complain if their laptop
> battery lasted a few minutes longer ;-)
In practice the savings you get from this are very small - at worst
you're looking at things like powering up a high-power amplifier and
playing an audio signal through it when it's not actually connected.
These might consume hundreds of miliwatts (at worst) but you can achieve
an awful lot of the saving DAPM makes by simply muting the relevant
output. More typically you're looking at savings in the order of single
or double digit miliwatts.
> This is why I think grouping drivers based on platform, bus type or
> whatever is just wrong. It prevents using the same drivers on identical
> hardware that just happens to be integrated on a different type of chip
> or wired up to a different kind of bus.
That's just the convention that's been adopted by people writing
platform support - it's not an ASoC requirement.
> Now, I'm not sure what kind of changes that were necessary to make the
> at91 driver work on avr32, but if it was only about changing it to use
> the atmel-ssc driver, maybe we should just replace the existing at91
> driver with the new at32 driver?
If literally the same driver can be used then you probably want to have
a directory (eg, 'atmel') which is shared between the two platforms.
> > The PCM layer in these drivers represents the DMA controller part of the
> > SoC hardware - the DMA control is split out in ASoC because most SoCs
> Ok, so why not call it "DMA" or something instead of "PCM"?
You can do if you like - the ASoC core actually calls this type of
driver a platform driver (the idea is that it should handle anything
that applies over multiple controllers, but in practice that's usually
just DMA).
> Yes, thanks a lot for explaining. I think the design goals of the ASoC
> layer makes sense, it's just that I don't see anything inherently
> SoC-specific about them.
The subsystem is there and can be used if it makes sense for a given
driver but as outlined above it's not going to work well for everyone.
On Fri, Jun 06, 2008 at 11:29:15AM +0200, Haavard Skinnemoen wrote:
> But I would have thought that if you have a PC sound card with an
> on-board i2s bus and a standard codec, you could create a board driver
> by simply hooking the different parts together, possibly with a custom
> i2s bus driver?
If the card has been built in that way then yes, you could do that.
> Geoffrey Wossum <[email protected]> wrote:
> > - I think PC sound cards tend to be black boxes regarding power consumption,
> > especially those white box cards you can get at Fry's and similar places.
> Right...so it's a matter of documentation. I suspect those white box
> cards still use cheap, standard hardware under the hood, though maybe
> that fact is pretty well hidden.
There may just not be the control exposed - there's quite a lot of parts
intended for simple applications which may only offer a few bits of
control for things like mute done via setting levels on pins.
> away. For example, a particular AC97 codec chip may be used with a
> different driver depending on whether it's soldered on a PC motherboard
> or some embedded board. That feels wrong to me.
That should really only be required if you're using features which go
substantially outside the AC97 spec (modulo perhaps needing to make
ac97.c glue more stuff together).
On Friday 06 June 2008 04:29:15 am Haavard Skinnemoen wrote:
> Geoffrey Wossum <[email protected]> wrote:
> > On Thursday 05 June 2008 11:24:09 am Haavard Skinnemoen wrote:
> > > Geoffrey Wossum <[email protected]> wrote:
> > > > On Thursday 05 June 2008 09:22:06 am Haavard Skinnemoen wrote:
> > > > > Geoffrey Wossum <[email protected]> wrote:
> Ok. Since the SSC module is a multi-purpose module, the SSC driver was
> designed to be as thin and flexible as possible. So we just added some
> platform_driver glue and a request/free interface and left everything
> else up to the higher-level driver.
>
> I suppose we could add a few more helper functions. Suggestions are
> welcome.
It's hard to try to add all the possible permutations of functionality.
Probably just getting register bit field constants defined would help out
tremendously.
> > One issue is the SSC
> > interface, which you have said could be used on the AT91. After that,
> > the main differences are that the DMA buffer has to be allocated
> > differently, and the mmap() implementation is different.
>
> Oh. That's a bit surprising to me...can you elaborate on the
> differences?
Well, I used a coherent DMA buffer on the AVR32. I was trying to rule out
caching effects for the issues I was having at first. Eventually it should
be switched back to a writecombined DMA buffer. I assume this will require
adding some dma_sync_*() calls, which strangely seem to be missing from
at91-pcm.c.
The mmap() would still look different, though. The AT91 uses
dma_mmap_writecombine(), which only exists on the ARM. Glancing at that
routine, it seems to jump through a lot of hoops. I've never worked on an
ARM with an MMU, so I don't really know why it's necessary. But the AVR32
just requires a call to remap_pfn_range().
---
Geoffrey