[alsa-devel] Reforming s3c2443 ac97 driver
Hi, Right now the S3C2443's AC97_ver2.0 controller driver isn't flexible enough to handle newer SoCs. In order to prepare ground for supporting 64xx and S5Pxxxx the extant driver needs to be reformed, and that is what i am planning to do next.
I plan to do the following:- 1) User platform_driver structure to detect and manage AC97 controller platform devices. 2) Remove hardcoded parameters(DMA, IO address, IRQ etc) and pass via platform resources. 3) Initialize platform specific stuff by callback pointers to platform code(cfg_gpio)
Objections, suggestions welcome.
------------------------------- Jaswinder Singh Brar Senior Engineer Linux OS Team Application Processor Development System LSI Division SAMSUNG Electronics Co., Ltd. --------------------------------
On Fri, Jan 08, 2010 at 05:28:51AM +0000, JASWINDERSINGH BRAR wrote:
Hi, Right now the S3C2443's AC97_ver2.0 controller driver isn't flexible enough to handle newer SoCs. In order to prepare ground for supporting 64xx and S5Pxxxx the extant driver needs to be reformed, and that is what i am planning to do next.
I plan to do the following:-
- User platform_driver structure to detect and manage AC97 controller
platform devices. 2) Remove hardcoded parameters(DMA, IO address, IRQ etc) and pass via platform resources. 3) Initialize platform specific stuff by callback pointers to platform code(cfg_gpio)
Objections, suggestions welcome.
None from here, although it isn't really my driver in the first place.
On 8 Jan 2010, at 05:28, JASWINDERSINGH BRAR jassi.brar@samsung.com wrote:
Hi, Right now the S3C2443's AC97_ver2.0 controller driver isn't flexible enough to handle newer SoCs. In order to prepare ground for supporting 64xx and S5Pxxxx the extant driver needs to be reformed, and that is what i am planning to do next.
I plan to do the following:-
- User platform_driver structure to detect and manage AC97 controller
platform devices. 2) Remove hardcoded parameters(DMA, IO address, IRQ etc) and pass via platform resources. 3) Initialize platform specific stuff by callback pointers to platform code(cfg_gpio)
Objections, suggestions welcome.
This sounds like a good approach - please go ahead.
On Fri, Jan 8, 2010 at 6:48 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On 8 Jan 2010, at 05:28, JASWINDERSINGH BRAR jassi.brar@samsung.com wrote:
Hi, Right now the S3C2443's AC97_ver2.0 controller driver isn't flexible enough to handle newer SoCs. In order to prepare ground for supporting 64xx and S5Pxxxx the extant driver needs to be reformed, and that is what i am planning to do next.
I plan to do the following:-
- User platform_driver structure to detect and manage AC97 controller
platform devices. 2) Remove hardcoded parameters(DMA, IO address, IRQ etc) and pass via platform resources. 3) Initialize platform specific stuff by callback pointers to platform code(cfg_gpio)
Objections, suggestions welcome.
This sounds like a good approach - please go ahead.
There has been a slight change though.
Both parts(platform_device interface and ALSA AC97 interface) of s3c2443-ac97.c needed so much reforming that I found rewriting the driver again a better option. The new driver is called 's3c-ac97.c' ... hoping the AC97 controller doesn't change in SoCs released after you read this mail :)
The s3c2443-ac97.c is used by SMDK2443 and LN2440SBC machines. My new driver is at least as good as old one for SMDK2443(both detect controller fine but none produce any sound.. might be some h/w issue on the only board I have got). I have no access to LN2440SBC but there is no reason for it to complain. Besides, the new AC97 controller driver(plus a machine driver for SMDKs with WM9713 attached to AC97 port) has been tested on all SoCs that I could get my hands on(6410, C100, C110 and V210).
Trying to avoid one outright rejected series of patches, I wanted to confirm if my approach is acceptable.
On Thu, Jan 21, 2010 at 03:58:46PM +0900, jassi brar wrote:
Both parts(platform_device interface and ALSA AC97 interface) of s3c2443-ac97.c needed so much reforming that I found rewriting the driver again a better option. The new driver is called 's3c-ac97.c' ... hoping the AC97 controller doesn't change in SoCs released after you read this mail :)
That sounds fine, though it will requier slightly more cross tree coordination with there being changes in both arch/arm and sound/soc. Please go ahead.
On Thu, 2010-01-21 at 15:58 +0900, jassi brar wrote:
The s3c2443-ac97.c is used by SMDK2443 and LN2440SBC machines. My new driver is at least as good as old one for SMDK2443(both detect controller fine but none produce any sound.. might be some h/w issue on the only board I have got).
It does sound like the AC97 link is up and running. What codec is used here ?
I have no access to LN2440SBC but there is no reason for it to complain. Besides, the new AC97 controller driver(plus a machine driver for SMDKs with WM9713 attached to AC97 port) has been tested on all SoCs that I could get my hands on(6410, C100, C110 and V210).
It would be good if you could also confirm that AC97 warm reset, AC97 cold reset and VRA (rates other than 48kHz) all work with the new driver. Fwiw, it does sound like AC97 warm reset works since the WM9713 probes (it's default state requires warm reset to wake up the link).
Liam
On Thu, Jan 21, 2010 at 7:37 PM, Liam Girdwood lrg@slimlogic.co.uk wrote:
On Thu, 2010-01-21 at 15:58 +0900, jassi brar wrote:
The s3c2443-ac97.c is used by SMDK2443 and LN2440SBC machines. My new driver is at least as good as old one for SMDK2443(both detect controller fine but none produce any sound.. might be some h/w issue on the only board I have got).
It does sound like the AC97 link is up and running. What codec is used here ?
Yes, link is fine. Irqs happen too and no xruns. Just I can't hear anything.
I have no access to LN2440SBC but there is no reason for it to complain. Besides, the new AC97 controller driver(plus a machine driver for SMDKs with WM9713 attached to AC97 port) has been tested on all SoCs that I could get my hands on(6410, C100, C110 and V210).
It would be good if you could also confirm that AC97 warm reset, AC97 cold reset and VRA (rates other than 48kHz) all work with the new driver. Fwiw, it does sound like AC97 warm reset works since the WM9713 probes (it's default state requires warm reset to wake up the link).
New driver does cold and warm reset only in callback hooks. Link is enabled in ac97 read/write-reg when the status is not ACTIVE. VRA works too.
On Thu, Jan 21, 2010 at 08:22:19PM +0900, jassi brar wrote:
On Thu, Jan 21, 2010 at 7:37 PM, Liam Girdwood lrg@slimlogic.co.uk wrote:
It does sound like the AC97 link is up and running. What codec is used here ?
Yes, link is fine. Irqs happen too and no xruns. Just I can't hear anything.
That sounds like something really simple like a mute that's on by default in the CODEC. I'd certainly be comfortable that the controller is working, anyway.
On Thu, Jan 21, 2010 at 8:30 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Jan 21, 2010 at 08:22:19PM +0900, jassi brar wrote:
On Thu, Jan 21, 2010 at 7:37 PM, Liam Girdwood lrg@slimlogic.co.uk wrote:
It does sound like the AC97 link is up and running. What codec is used here ?
Yes, link is fine. Irqs happen too and no xruns. Just I can't hear anything.
That sounds like something really simple like a mute that's on by default in the CODEC. I'd certainly be comfortable that the controller is working, anyway.
I did give it a quick try without luck. Will dig deeper tomorrow.
participants (5)
-
Ben Dooks -
jassi brar -
JASWINDERSINGH BRAR -
Liam Girdwood -
Mark Brown