On Fri, Jan 8, 2010 at 6:48 PM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On 8 Jan 2010, at 05:28, JASWINDERSINGH BRAR <jassi.brar@xxxxxxxxxxx> > 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:- >> 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. > > 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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
