On Fri, 2008-02-01 at 13:14 +0100, Takashi Iwai wrote:

At Thu, 31 Jan 2008 15:33:14 -0800, Tobin Davis wrote:

...

This patch adds support for the OQO Model 2 Ultra Mobile PC.

Signed off by Tobin Davis tdavis@dsl-only.net

Thanks. I'll apply it after 1.0.16 release.

When's the next release window? My contact at IDT (Sigmatel) was hoping to get it in this release, he just didn't get back to me with the test results until yesterday.

Also, I had some very strange audio garbage with the tip on an HD Audio platform that normally works ok. I'm going to be tracking it down this morning, once I get to work (1 hour). I'm not sure if it is related to the AD1986a or the SCH (gcap patch). I do know that GCAP returns 2200 on this system, whereas a normal ICH returns 4401. The last bit may be significant (64bit vs 32bit stream). I need to reverify the SCH value, but this may be causing the issue. This is critical for a launch coming up.

On Fri, 2008-02-01 at 16:13 +0100, Takashi Iwai wrote:

Also, I had some very strange audio garbage with the tip on an HD Audio platform

...

that normally works ok. I'm going to be tracking it down this

morning, once I

...

get to work (1 hour). I'm not sure if it is related to the AD1986a

or the SCH

...

(gcap patch).

AD1986A has a known problem when you assign the single stream to multiple DACs. But, we should have fixed this already in 1.0.16rc2.

If that's the case, then it isn't fixed as of yesterday's snapshot. I have brought in an ALC268 test board to replace the AD1986a. I will know real soon if this is the issue.

...

I do know that GCAP returns 2200 on this system, whereas a normal ICH returns 4401. The last bit may be significant (64bit vs 32bit

stream). I

...

need to reverify the SCH value, but this may be causing the issue.

This is

...

critical for a launch coming up.

Hm, this bit hasn't been tested. OK, we need a fix for that. (But I think OQO has no more than 4GB RAM, no?)

This isn't for the OQO, this is for a new Intel platform. And it will market with 256M-1G memory. If that bit is only for 64bit memory addressing, then I'm not worried about it. Sorry my earlier mail was confusing. I was getting ready for work and wanted to toss a quick head's up.

At Fri, 01 Feb 2008 14:57:35 -0800, Tobin Davis wrote:

On Fri, 2008-02-01 at 16:13 +0100, Takashi Iwai wrote:

> Also, I had some very strange audio garbage with the tip on an HD Audio
platform
> that normally works ok.  I'm going to be tracking it down this morning,
once I
> get to work (1 hour).  I'm not sure if it is related to the AD1986a or the
SCH
> (gcap patch).

AD1986A has a known problem when you assign the single stream to
multiple DACs.  But, we should have fixed this already in 1.0.16rc2.

Ok, I can confirm on my test system that the HDA-GCAP and HDA-SCH patches are ok. I tested them on 1.0.15 with an AD1986a and they work fine. Same system with HG20080130 is aweful. I'm trying to revert the patch_analog patches one at a time to see which one is the problem.

Did you find out the problem? I vaguely remember that EAPD may play a bad role for headphones. This should be disabled except for the speaker output.

>  I do know that GCAP returns 2200 on this system, whereas a normal
> ICH returns 4401.  The last bit may be significant (64bit vs 32bit
stream).  I
> need to reverify the SCH value, but this may be causing the issue.  This
is
> critical for a launch coming up.

Hm, this bit hasn't been tested.  OK, we need a fix for that.

No need to worry about this bit I guess. It may only be relevant on a system that runs 64bit OSes, and I'd assume that bit doesn't exist for systems that can't.

The fix itself would be pretty easy. Check this bit and reset the dma consistent mask to 32bit if it's 32bit only.

Hm, this reminds me that we should call set_mask with 64bit as default. Needs more investigation...

Takashi

At Mon, 04 Feb 2008 08:38:10 -0800, Tobin Davis wrote:

On Mon, 2008-02-04 at 16:19 +0100, Takashi Iwai wrote:

At Fri, 01 Feb 2008 14:57:35 -0800,
Tobin Davis wrote:
> 
> On Fri, 2008-02-01 at 16:13 +0100, Takashi Iwai wrote:
> 
>     > Also, I had some very strange audio garbage with the tip on an HD Audio
>     platform
>     > that normally works ok.  I'm going to be tracking it down this morning,
>     once I
>     > get to work (1 hour).  I'm not sure if it is related to the AD1986a or the
>     SCH
>     > (gcap patch).
>    
>     AD1986A has a known problem when you assign the single stream to
>     multiple DACs.  But, we should have fixed this already in 1.0.16rc2.
> 
> Ok, I can confirm on my test system that the HDA-GCAP and HDA-SCH patches are
> ok.  I tested them on 1.0.15 with an AD1986a and they work fine.  Same system
> with HG20080130 is aweful.  I'm trying to revert the patch_analog patches one at
> a time to see which one is the problem.

Did you find out the problem?  I vaguely remember that EAPD may play a
bad role for headphones.  This should be disabled except for the
speaker output.

The problem I noticed only occurred on my SCH based system. It was solved with the snoop bit check/set. I'll double check to see if I have any issues on my laptop (Asus Z62F w/ ad1986a - model=laptop-eapd).

Oddly enough, the system worked fine with 1.0.15 and the two earlier patches (GCAP and SCH PCI IDS). Not sure what to make of that. I'll do more testing today.

OK, then let me know if you find out something.

>     >  I do know that GCAP returns 2200 on this system, whereas a normal
>     > ICH returns 4401.  The last bit may be significant (64bit vs 32bit
>     stream).  I
>     > need to reverify the SCH value, but this may be causing the issue.  This
>     is
>     > critical for a launch coming up.
>    
>     Hm, this bit hasn't been tested.  OK, we need a fix for that.
> 
> No need to worry about this bit I guess.  It may only be relevant on a system
> that runs 64bit OSes, and I'd assume that bit doesn't exist for systems that
> can't.

The fix itself would be pretty easy.  Check this bit and reset the dma
consistent mask to 32bit if it's 32bit only.

Hm, this reminds me that we should call set_mask with 64bit as
default.  Needs more investigation...

Is this dependent on system/OS? My thought was it was for supporting x86-64 architecture. That being the case, it should be added to the TODO list, but not critical for 1.0.16 release.

Well, what I mentioned above is about the DMA memory allocation. Currently, Linux kernel allocates PCI DMA memory in 32bit space unless you set the 64bit DMA mask properly. So, we don't use over 4GB address even if RAM is available.

Of course, we already support x86-64 :)

Actually, there are other potential issues that I noticed with regards to GCAP and our current usage. For example, bi-directional stream support and number of serial data out signals. Both are hardwired in the ICH family of chipsets, but for how long?

I don't care about these so seriously right now. The driver coding depends really on the hardware. And, the hardware implementation often ends up differently from what the spec says, especially in the first version. Let's see what comes up in future at first.

Takashi

Thanks, boss.

On Sun, 2008-02-03 at 20:32 +0100, Takashi Iwai wrote:

At Fri, 01 Feb 2008 16:13:47 +0100, I wrote:

...

At Fri, 01 Feb 2008 07:01:44 -0800, Tobin Davis wrote:

...

On Fri, 2008-02-01 at 13:14 +0100, Takashi Iwai wrote:

At Thu, 31 Jan 2008 15:33:14 -0800,
Tobin Davis wrote:
> 
> This patch adds support for the OQO Model 2 Ultra Mobile PC.
> 
> 
> Signed off by Tobin Davis <tdavis@dsl-only.net>

Thanks.  I'll apply it after 1.0.16 release.

When's the next release window? My contact at IDT (Sigmatel) was hoping to get it in this release, he just didn't get back to me with the test results until yesterday.

1.0.16 will be released in the next week. As Jaroslav already announced, we want to avoid patches except for bug fixes until the release.

On the second thought, it's easier to integrate this patch right now because it's very local and cannot break others. So, I applied OQO patch to HG tree to be merged to 1.0.16.

thanks,

Takashi