Reforming s3c2443 ac97 driver

Reforming s3c2443 ac97 driver

[JASWINDERSINGH BRAR]

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. 
--------------------------------

Re: Reforming s3c2443 ac97 driver

[Ben Dooks]

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:-
> 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.

None from here, although it isn't really my driver in the first place.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

Re: Reforming s3c2443 ac97 driver

[Mark Brown]

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.

Re: Reforming s3c2443 ac97 driver

[jassi brar]

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

Re: Reforming s3c2443 ac97 driver

[Mark Brown]

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.

Re: Reforming s3c2443 ac97 driver

[Liam Girdwood]

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

Re: Reforming s3c2443 ac97 driver

[jassi brar]

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.

Re: Reforming s3c2443 ac97 driver

[Mark Brown]

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.

Re: Reforming s3c2443 ac97 driver

[jassi brar]

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

Re: Reforming s3c2443 ac97 driver

[jassi brar]

On Fri, Jan 22, 2010 at 9:43 AM, SeungHyun Choi <sh428.choi@samsung.com> wrote:
>
> Dear. Jassi
>
> Thank you for all the information of AC97 reforming.
>
> I'm working for Android smart phone now as T/L with Samsung Handset division (S3C6410 --> Galaxy-spica, InstinctQ)
>
> Actually, we are using I2S interface and external codec chip  for audio because of various functions of audio like connecting BT or modem.. etc.
>
> Honestly  out of my mind about AC97 codec. But your works are look fine. I agree too.
thanks for agreeing.

>
> I've reformed i2c & pcm driver in linux 2.6.29 too since android doesn't have audio library and diffrent from other OS like WM or Linux
I keep updated(after backporting latest code from Mark's GIT) Samsung
linux-2.6.29/31 that you might want to try out.

> It was so difficult to handle buffer management between Platform and Kernel. (noise, distortion. ...)
>
> Next time, I'd like to share with you if there is a chance.
>
> Regards.
>
>
>
> ------- Original Message -------
> Sender : jassi brar<jassisinghbrar@gmail.com>
> Date : 2010-01-21 15:58 (GMT+09:00)
> Title : Re: [alsa-devel] Reforming s3c2443 ac97 driver
>
> 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.
>
>
>
>
>
> ________________________________
>
>
>
> 최 승 현 책임
>
> 삼성전자주식회사
>
> Embedded S/W Center
>
> System LSI사업부
>
> 반도체총괄
>
>
>
> 031-209-8330
>
> sh428.choi@samsung.com
>
>
>
> ________________________________
>
>
>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Reforming s3c2443 ac97 driver

[Ben Dooks]

[-- Attachment #1.1: Type: text/plain, Size: 786 bytes --]

On Fri, Jan 22, 2010 at 12:43:47AM +0000, SeungHyun Choi wrote:
> <HTML><HEAD>
> <META http-equiv=Content-Type content='text/html; charset=utf-8'>
> <title>Samsung Enterprise Portal mySingle</title>
> <style> P, td, li {font-family:Arial, arial; font-size:9pt; margin-top:5px;margin-bottom:5px;} body{font-family:Arial, arial; font-size:9pt;}</style>
> </HEAD><BODY><br><p>Dear. Jassi</p>
> <p>Thank you for all the information of AC97 reforming.</p>
> <p>I'm working for Android smart phone&nbsp;now as T/L with Samsung Handset 
> division (S3C6410 --&gt; Galaxy-spica, InstinctQ)</p>
> <p>Actually, we are using I2S interface and external codec chip &nbsp;for audio 

Please avoid HTML postings to public lists, we end up seeing this sort of
mess by default.

-- 
Ben

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel