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.