Re: Reforming s3c2443 ac97 driver

[jassi brar <jassisinghbrar@gmail.com>]

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:-
>> 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@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel