Triple implementation of WM8766 and quadruple WM8776!
Hello,
I'm trying do implement support for Philips PSC724 Ultimate Edge card, which is based on VT1722 + WM8776 + WM8766 chips. Found that the best file to base my work on is sound/pci/ice1712/se.c (as SE-200PCI card contains both WM8776 and WM8766 chips).
While doing this, found that there are three implementations of WM8766 codec control, two of them in the same driver(!):sound/pci/ice1712/se.csound/pci/ice1712/prodigy_hifi.csound/pci/oxygen/xonar_wm87x6.c (+sound/pci/oxygen/wm8766.h)
And WM8776 status is even worse, there are four implementations, again two being in the same driver:sound/pci/ice1712/se.csound/pci/ice1712/maya44.csound/pci/oxygen/xonar_wm87x6.c (+sound/pci/oxygen/wm8776.h) sound/soc/codecs/wm8776.c (this one being official and stand-alone module but it does not seem to be usable as a part of sound card driver)
My code would enlarge both of these lists and I don't like that. What to do?
Signature · 1 line
Ondrej Zary
Quoted 11 lines · Ondrej Zary
I'm trying do implement support for Philips PSC724 Ultimate Edge card, which is based on VT1722 + WM8776 + WM8766 chips. Found that the best file to base my work on is
sound/pci/ice1712/se.c(as SE-200PCI card contains both WM8776 and WM8766 chips).While doing this, found that there are three implementations of WM8766 codec control, two of them in the same driver(!):
sound/pci/ice1712/se.csound/pci/ice1712/prodigy_hifi.csound/pci/oxygen/xonar_wm87x6.c(+sound/pci/oxygen/wm8766.h)
Quoted 7 lines
And WM8776 status is even worse, there are four implementations, again two being in the same driver:
sound/pci/ice1712/se.csound/pci/ice1712/maya44.csound/pci/oxygen/xonar_wm87x6.c(+sound/pci/oxygen/wm8776.h)sound/soc/codecs/wm8776.c(this one being official and stand-alone module but it does not seem to be usable as a part of sound card driver)
The ALSA SoC framework differentiates between three kinds of drivers:
codec, platform (controllers like the VT1722), and machine (in your case, the wiring on the PSC724). When I wrote the oxygen driver, I didn't use ASoC because it didn't support multiple codecs per card at that time (now it does).
I'd suggest to use ASoC, except that ice1724 is not an ASoC platform driver, so you'd have to duplicate it.
All the non-ASoC drivers mix codec and machine drivers in the same file. In the long term, ice1712 and oxygen should be converted to use ASoC, but that would be a lot of effort if regressions are to be avoided.
I'd suggest to move the common parts of the three ice1712 drivers into separate files. You could make the interface of those files similar to ASoC codec drivers to make later porting easier.
Regards,
Clemens
Dne 13.3.2012 10:46, Clemens Ladisch napsal(a):
Quoted 20 lines
Quoted 18 lines · Ondrej Zary
I'm trying do implement support for Philips PSC724 Ultimate Edge card, which is based on VT1722 + WM8776 + WM8766 chips. Found that the best file to base my work on is
sound/pci/ice1712/se.c(as SE-200PCI card contains both WM8776 and WM8766 chips).While doing this, found that there are three implementations of WM8766 codec control, two of them in the same driver(!):
sound/pci/ice1712/se.csound/pci/ice1712/prodigy_hifi.csound/pci/oxygen/xonar_wm87x6.c(+sound/pci/oxygen/wm8766.h)And WM8776 status is even worse, there are four implementations, again two being in the same driver:
sound/pci/ice1712/se.csound/pci/ice1712/maya44.csound/pci/oxygen/xonar_wm87x6.c(+sound/pci/oxygen/wm8776.h)sound/soc/codecs/wm8776.c(this one being official and stand-alone module but it does not seem to be usable as a part of sound card driver)
.....
Quoted 4 lines
I'd suggest to move the common parts of the three ice1712 drivers into separate files. You could make the interface of those files similar to ASoC codec drivers to make later porting easier.
How about a solution similar to AKM codecs in i2c/other? Several ice1724 cards make use of those modules, easy to support and re-use. IMO cleaner approach than duplicating ICE1724 to the ASoC framework.
Pavel.
At Tue, 13 Mar 2012 10:53:09 +0100,
Quoted 24 lines · Pavel Hofman
Dne 13.3.2012 10:46, Clemens Ladisch napsal(a):
Quoted 20 lines
Quoted 18 lines · Ondrej Zary
I'm trying do implement support for Philips PSC724 Ultimate Edge card, which is based on VT1722 + WM8776 + WM8766 chips. Found that the best file to base my work on is
sound/pci/ice1712/se.c(as SE-200PCI card contains both WM8776 and WM8766 chips).While doing this, found that there are three implementations of WM8766 codec control, two of them in the same driver(!):
sound/pci/ice1712/se.csound/pci/ice1712/prodigy_hifi.csound/pci/oxygen/xonar_wm87x6.c(+sound/pci/oxygen/wm8766.h)And WM8776 status is even worse, there are four implementations, again two being in the same driver:
sound/pci/ice1712/se.csound/pci/ice1712/maya44.csound/pci/oxygen/xonar_wm87x6.c(+sound/pci/oxygen/wm8776.h)sound/soc/codecs/wm8776.c(this one being official and stand-alone module but it does not seem to be usable as a part of sound card driver).....
Quoted 1 line
Quoted 7 lines
Quoted 3 lines
I'd suggest to move the common parts of the three ice1712 drivers into separate files. You could make the interface of those files similar to ASoC codec drivers to make later porting easier.
How about a solution similar to AKM codecs in i2c/other? Several ice1724 cards make use of those modules, easy to support and re-use. IMO cleaner approach than duplicating ICE1724 to the ASoC framework.
ASoC would be rather a "cleaner" approach, but moving the common code into i2c/other would be a "safer" approach. It can be done without shifting the whole infrastructure of ice17xx and oxygen drivers, indeed.
thanks,
Takashi
Dne 13.3.2012 10:58, Takashi Iwai napsal(a):
Quoted 6 lines
Quoted 6 lines
.....
Quoted 4 lines
I'd suggest to move the common parts of the three ice1712 drivers into separate files. You could make the interface of those files similar to ASoC codec drivers to make later porting easier.
Quoted 8 lines
Quoted 3 lines
How about a solution similar to AKM codecs in i2c/other? Several ice1724 cards make use of those modules, easy to support and re-use. IMO cleaner approach than duplicating ICE1724 to the ASoC framework.
ASoC would be rather a "cleaner" approach, but moving the common code into i2c/other would be a "safer" approach. It can be done without shifting the whole infrastructure of ice17xx and oxygen drivers, indeed.
That is very true. I am afraid we do not have all the cards physically available to test a major overhaul of ice17xx.
Pavel.
Quoted 3 lines · Pavel Hofman
How about a solution similar to AKM codecs in i2c/other? Several ice1724 cards make use of those modules, easy to support and re-use. IMO cleaner approach than duplicating ICE1724 to the ASoC framework.
Those drivers should also be using ASoC - they're there only because they predate having a framework for this stuff. As Clemens said we shouldn't be duplicating the ICE1724 code, we should be moving it.