20K1 PCI bars, and mode switching info.

20K1 PCI bars, and mode switching info.

[James Courtier-Dutton]

This info should help the current snd-sbxfi driver to actually work with
the "Vista compatible" cards that it currently does not work with.
I believe the true UAA to 20K1 mode switch code is missing from the
current alsa snd-sbxfi driver.


PCI BARs

UAA mode, or Vista Compatibility mode.
	BAR0:	16K for UAA
		
  14h	BAR1:	2M for 20k1 (low 32 bit)
  18h		2M for 20k1 (high 32 bit)
  1Ch	BAR2:	Between 2 and 256M for 20k1 (low 32 bit)
  20h		Between 2 and 256M for 20k1 (high 32 bit)
  24h	BAR3:	32 bit I/O for 20K1

20K1 Mode
	BAR0:	32 bit I/O for 20K1
		
  14h	BAR1:	2M for 20k1 (low 32 bit)
  18h		2M for 20k1 (high 32 bit)
  1Ch	BAR2:	Between 2 and 256M for 20k1 (low 32 bit)
  20h		Between 2 and 256M for 20k1 (high 32 bit)
  24h		

"UAA/20K1 mode" and "config space selection" work independently of each
other.

1) Configuration space selection:

This allows the driver to talk to both the UAA and 20K1 configuration
space whichever mode (UAA or 20K1) the card is in.
Location: PCI Register 0xA0 for "20K1 Configuration Space Flag" register.

Value: 0x12345678 to select 20K1 without BAR0 exposed;
Value: 0x87654321 to select 20K1 with BAR0 exposed;
       (should disable immediately after using.)
Value: 0x00000000 to select UAA.

2) UAA/20K1 MODE CHANGE (controls who the bus master is):
The "Mode Change" register is located in the UAA configuration space at
location offset 0x3FFC. This location stores 4 values in a ring.
To switch from 20K1 mode to UAA mode write each DW value: CTLA, CTLZ,
CTLL, CTLA.
To switch from UAA mode to 20K1 mode write each DW value: CTLX, CTL-,
CTLF, CTLi
To read the current mode, the 4 value ring may be in any position, so
one might read for example:
CTLL, CTLA, CTLA, CTLZ

At power on, the card is in UAA mode.
In UAA mode, the UAA chip is the bus master.
In 20K1 mode, the 20K1 chip is the bus master.
Under either UAA mode or 20K1 mode, the driver can read and write the
configuration space of both UAA chip and 20K1 chip.

Re: 20K1 PCI bars, and mode switching info.

[James Courtier-Dutton]

James Courtier-Dutton wrote:
> To switch from UAA mode to 20K1 mode write each DW value: CTLX, CTL-,
> CTLF, CTLi
Here is the pseudo code:

WriteMemory((bar0 + 0x00003ffc),0x43544c58);  // CTLX
WriteMemory((bar0 + 0x00003ffc),0x43544c2d);  // CTL-
WriteMemory((bar0 + 0x00003ffc),0x43544c46);  // CTLF
WriteMemory((bar0 + 0x00003ffc),0x43544c69);  // CTLi

Re: 20K1 PCI bars, and mode switching info.

[Vedran Miletić]

Takashi added UAA mode to hda-intel driver with patch_creative.c,
IIRC. Why would this be necessary?

2008/10/19 James Courtier-Dutton <James@superbug.co.uk>:
> This info should help the current snd-sbxfi driver to actually work with
> the "Vista compatible" cards that it currently does not work with.
> I believe the true UAA to 20K1 mode switch code is missing from the
> current alsa snd-sbxfi driver.
>

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

Re: 20K1 PCI bars, and mode switching info.

[James Courtier-Dutton]

Vedran Miletić wrote:
> Takashi added UAA mode to hda-intel driver with patch_creative.c,
> IIRC. Why would this be necessary?
> 

In time xfi mode will have far more features than the UAA mode.
E.g. hardware mixing of over 64 channels at the same time.
The UAA mode has no hardware mixing and handles only a few channels.



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

Re: 20K1 PCI bars, and mode switching info.

[Takashi Iwai]

At Sun, 19 Oct 2008 20:18:27 +0100,
James Courtier-Dutton wrote:
> 
> Vedran Miletić wrote:
> > Takashi added UAA mode to hda-intel driver with patch_creative.c,
> > IIRC. Why would this be necessary?
> > 
> 
> In time xfi mode will have far more features than the UAA mode.
> E.g. hardware mixing of over 64 channels at the same time.
> The UAA mode has no hardware mixing and handles only a few channels.

At this moment, X-Fi driver doesn't support it, so there is no merit 
for supporting UAA by sbxfi.  In future, yes.


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

Re: 20K1 PCI bars, and mode switching info.

[Takashi Iwai]

At Sun, 19 Oct 2008 20:17:06 +0200,
=?UTF-8?Q?Vedran_Mileti=C4=87?= wrote:
> 
> Takashi added UAA mode to hda-intel driver with patch_creative.c,
> IIRC. Why would this be necessary?

The support via patch_ca0110.c is disabled as default due to conflict
of PCI IDs.  I don't know also whether the HD-audio mode really worked
in every model.  More test reports needed.


Takashi

> 2008/10/19 James Courtier-Dutton <James@superbug.co.uk>:
> > This info should help the current snd-sbxfi driver to actually work with
> > the "Vista compatible" cards that it currently does not work with.
> > I believe the true UAA to 20K1 mode switch code is missing from the
> > current alsa snd-sbxfi driver.
> >
> 
> -- 
> Vedran Miletić
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 20K1 PCI bars, and mode switching info.

[Takashi Iwai]

At Sun, 19 Oct 2008 17:07:08 +0100,
James Courtier-Dutton wrote:
> 
> This info should help the current snd-sbxfi driver to actually work with
> the "Vista compatible" cards that it currently does not work with.
> I believe the true UAA to 20K1 mode switch code is missing from the
> current alsa snd-sbxfi driver.

The code to switch to 20k1 mode is already there.
The sbxfi driver uses ioport for the access, and it looks like in BAR5
for UAA boards.  This could be the problem...


Takashi

> 
> 
> PCI BARs
> 
> UAA mode, or Vista Compatibility mode.
> 	BAR0:	16K for UAA
> 		
>   14h	BAR1:	2M for 20k1 (low 32 bit)
>   18h		2M for 20k1 (high 32 bit)
>   1Ch	BAR2:	Between 2 and 256M for 20k1 (low 32 bit)
>   20h		Between 2 and 256M for 20k1 (high 32 bit)
>   24h	BAR3:	32 bit I/O for 20K1
> 
> 20K1 Mode
> 	BAR0:	32 bit I/O for 20K1
> 		
>   14h	BAR1:	2M for 20k1 (low 32 bit)
>   18h		2M for 20k1 (high 32 bit)
>   1Ch	BAR2:	Between 2 and 256M for 20k1 (low 32 bit)
>   20h		Between 2 and 256M for 20k1 (high 32 bit)
>   24h		
> 
> "UAA/20K1 mode" and "config space selection" work independently of each
> other.
> 
> 1) Configuration space selection:
> 
> This allows the driver to talk to both the UAA and 20K1 configuration
> space whichever mode (UAA or 20K1) the card is in.
> Location: PCI Register 0xA0 for "20K1 Configuration Space Flag" register.
> 
> Value: 0x12345678 to select 20K1 without BAR0 exposed;
> Value: 0x87654321 to select 20K1 with BAR0 exposed;
>        (should disable immediately after using.)
> Value: 0x00000000 to select UAA.
> 
> 2) UAA/20K1 MODE CHANGE (controls who the bus master is):
> The "Mode Change" register is located in the UAA configuration space at
> location offset 0x3FFC. This location stores 4 values in a ring.
> To switch from 20K1 mode to UAA mode write each DW value: CTLA, CTLZ,
> CTLL, CTLA.
> To switch from UAA mode to 20K1 mode write each DW value: CTLX, CTL-,
> CTLF, CTLi
> To read the current mode, the 4 value ring may be in any position, so
> one might read for example:
> CTLL, CTLA, CTLA, CTLZ
> 
> At power on, the card is in UAA mode.
> In UAA mode, the UAA chip is the bus master.
> In 20K1 mode, the 20K1 chip is the bus master.
> Under either UAA mode or 20K1 mode, the driver can read and write the
> configuration space of both UAA chip and 20K1 chip.
> 
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: 20K1 PCI bars, and mode switching info.

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Sun, 19 Oct 2008 17:07:08 +0100,
> James Courtier-Dutton wrote:
>> This info should help the current snd-sbxfi driver to actually work with
>> the "Vista compatible" cards that it currently does not work with.
>> I believe the true UAA to 20K1 mode switch code is missing from the
>> current alsa snd-sbxfi driver.
> 
> The code to switch to 20k1 mode is already there.
> The sbxfi driver uses ioport for the access, and it looks like in BAR5
> for UAA boards.  This could be the problem...
> 

Well I cannot find it. I can only find:
static void sbxfi_switch_xfi_mode(struct sbxfi *chip)
and that does not do the job.

You need to do this:

>> 2) UAA/20K1 MODE CHANGE (controls who the bus master is):
>> The "Mode Change" register is located in the UAA configuration space at
>> location offset 0x3FFC. This location stores 4 values in a ring.
>> To switch from 20K1 mode to UAA mode write each DW value: CTLA, CTLZ,
>> CTLL, CTLA.
>> To switch from UAA mode to 20K1 mode write each DW value: CTLX, CTL-,
>> CTLF, CTLi
>> To read the current mode, the 4 value ring may be in any position, so
>> one might read for example:
>> CTLL, CTLA, CTLA, CTLZ
>>
>> At power on, the card is in UAA mode.
>> In UAA mode, the UAA chip is the bus master.
>> In 20K1 mode, the 20K1 chip is the bus master.
>> Under either UAA mode or 20K1 mode, the driver can read and write the
>> configuration space of both UAA chip and 20K1 chip.
>>

Re: 20K1 PCI bars, and mode switching info.

[Takashi Iwai]

At Mon, 20 Oct 2008 19:34:39 +0100,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> > At Sun, 19 Oct 2008 17:07:08 +0100,
> > James Courtier-Dutton wrote:
> >> This info should help the current snd-sbxfi driver to actually work with
> >> the "Vista compatible" cards that it currently does not work with.
> >> I believe the true UAA to 20K1 mode switch code is missing from the
> >> current alsa snd-sbxfi driver.
> > 
> > The code to switch to 20k1 mode is already there.
> > The sbxfi driver uses ioport for the access, and it looks like in BAR5
> > for UAA boards.  This could be the problem...
> > 
> 
> Well I cannot find it. I can only find:
> static void sbxfi_switch_xfi_mode(struct sbxfi *chip)
> and that does not do the job.

Well, this is supposed to be (1), switching to 20k1 mode.

> 
> You need to do this:
> 
> >> 2) UAA/20K1 MODE CHANGE (controls who the bus master is):
> >> The "Mode Change" register is located in the UAA configuration space at
> >> location offset 0x3FFC. This location stores 4 values in a ring.
> >> To switch from 20K1 mode to UAA mode write each DW value: CTLA, CTLZ,
> >> CTLL, CTLA.
> >> To switch from UAA mode to 20K1 mode write each DW value: CTLX, CTL-,
> >> CTLF, CTLi
> >> To read the current mode, the 4 value ring may be in any position, so
> >> one might read for example:
> >> CTLL, CTLA, CTLA, CTLZ

Hm, but procedure this isn't in OSS driver, too.
Doesn't OSS driver work with UAA boards?

> >> At power on, the card is in UAA mode.
> >> In UAA mode, the UAA chip is the bus master.
> >> In 20K1 mode, the 20K1 chip is the bus master.
> >> Under either UAA mode or 20K1 mode, the driver can read and write the
> >> configuration space of both UAA chip and 20K1 chip.

Doesn't it mean that 20k1 chip gets the bus master automatically
when switch into 20k1 mode from UAA mode?

Anyway ,20k1 mode switching is a mess.  This may screw up also the
internal room-keeping of struct pci.  Maybe we can't do it without
switching but just master mode switch?


thanks,

Takashi

Re: 20K1 PCI bars, and mode switching info.

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Mon, 20 Oct 2008 19:34:39 +0100,
> James Courtier-Dutton wrote:
>> Takashi Iwai wrote:
>>> At Sun, 19 Oct 2008 17:07:08 +0100,
>>> James Courtier-Dutton wrote:
>>>> This info should help the current snd-sbxfi driver to actually work with
>>>> the "Vista compatible" cards that it currently does not work with.
>>>> I believe the true UAA to 20K1 mode switch code is missing from the
>>>> current alsa snd-sbxfi driver.
>>> The code to switch to 20k1 mode is already there.
>>> The sbxfi driver uses ioport for the access, and it looks like in BAR5
>>> for UAA boards.  This could be the problem...
>>>
>> Well I cannot find it. I can only find:
>> static void sbxfi_switch_xfi_mode(struct sbxfi *chip)
>> and that does not do the job.
> 
> Well, this is supposed to be (1), switching to 20k1 mode.
(1) is a config space switch, nothing else. It leaves the UAA chip in
control of the bus master.
> 
>> You need to do this:
>>
>>>> 2) UAA/20K1 MODE CHANGE (controls who the bus master is):
>>>> The "Mode Change" register is located in the UAA configuration space at
>>>> location offset 0x3FFC. This location stores 4 values in a ring.
>>>> To switch from 20K1 mode to UAA mode write each DW value: CTLA, CTLZ,
>>>> CTLL, CTLA.
>>>> To switch from UAA mode to 20K1 mode write each DW value: CTLX, CTL-,
>>>> CTLF, CTLi
>>>> To read the current mode, the 4 value ring may be in any position, so
>>>> one might read for example:
>>>> CTLL, CTLA, CTLA, CTLZ
> 
> Hm, but procedure this isn't in OSS driver, too.
> Doesn't OSS driver work with UAA boards?
I do not know. I do not have access to any of the X-Fi hardware at the
moment. I am just reading the datasheets and commenting. There is also
sample code that I received with the datesheeets.

Here is some pseudo code to explain the CTLX etc. values.

WriteMemory((bar0 + 0x00003ffc),0x43544c58);  // CTLX
WriteMemory((bar0 + 0x00003ffc),0x43544c2d);  // CTL-
WriteMemory((bar0 + 0x00003ffc),0x43544c46);  // CTLF
WriteMemory((bar0 + 0x00003ffc),0x43544c69);  // CTLi


> 
>>>> At power on, the card is in UAA mode.
>>>> In UAA mode, the UAA chip is the bus master.
>>>> In 20K1 mode, the 20K1 chip is the bus master.
>>>> Under either UAA mode or 20K1 mode, the driver can read and write the
>>>> configuration space of both UAA chip and 20K1 chip.
> 
> Doesn't it mean that 20k1 chip gets the bus master automatically
> when switch into 20k1 mode from UAA mode?
(1) is a config space switch and PCI IDs switch, nothing else. It leaves
the chip in UAA mode. (2) is the real mode change.

> 
> Anyway ,20k1 mode switching is a mess.  This may screw up also the
> internal room-keeping of struct pci.  Maybe we can't do it without
> switching but just master mode switch?
I agree that it is messy. I did not design the hardware. Maybe we need
to make a suggestion on LKML so that we can make a call that updates the
global kernel struct pci once we make the config space switch. I do not
think we need to switch back from 20K1 to UAA mode. We already have
hotplug for cardbus pccards, maybe we could use some of those calls.

Kind regards

James

Re: 20K1 PCI bars, and mode switching info.

[Takashi Iwai]

At Tue, 21 Oct 2008 20:39:28 +0100,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> > At Mon, 20 Oct 2008 19:34:39 +0100,
> > James Courtier-Dutton wrote:
> >> Takashi Iwai wrote:
> >>> At Sun, 19 Oct 2008 17:07:08 +0100,
> >>> James Courtier-Dutton wrote:
> >>>> This info should help the current snd-sbxfi driver to actually work with
> >>>> the "Vista compatible" cards that it currently does not work with.
> >>>> I believe the true UAA to 20K1 mode switch code is missing from the
> >>>> current alsa snd-sbxfi driver.
> >>> The code to switch to 20k1 mode is already there.
> >>> The sbxfi driver uses ioport for the access, and it looks like in BAR5
> >>> for UAA boards.  This could be the problem...
> >>>
> >> Well I cannot find it. I can only find:
> >> static void sbxfi_switch_xfi_mode(struct sbxfi *chip)
> >> and that does not do the job.
> > 
> > Well, this is supposed to be (1), switching to 20k1 mode.
> (1) is a config space switch, nothing else. It leaves the UAA chip in
> control of the bus master.

OK.

> >> You need to do this:
> >>
> >>>> 2) UAA/20K1 MODE CHANGE (controls who the bus master is):
> >>>> The "Mode Change" register is located in the UAA configuration space at
> >>>> location offset 0x3FFC. This location stores 4 values in a ring.
> >>>> To switch from 20K1 mode to UAA mode write each DW value: CTLA, CTLZ,
> >>>> CTLL, CTLA.
> >>>> To switch from UAA mode to 20K1 mode write each DW value: CTLX, CTL-,
> >>>> CTLF, CTLi
> >>>> To read the current mode, the 4 value ring may be in any position, so
> >>>> one might read for example:
> >>>> CTLL, CTLA, CTLA, CTLZ
> > 
> > Hm, but procedure this isn't in OSS driver, too.
> > Doesn't OSS driver work with UAA boards?
> I do not know. I do not have access to any of the X-Fi hardware at the
> moment. I am just reading the datasheets and commenting. There is also
> sample code that I received with the datesheeets.
> 
> Here is some pseudo code to explain the CTLX etc. values.
> 
> WriteMemory((bar0 + 0x00003ffc),0x43544c58);  // CTLX
> WriteMemory((bar0 + 0x00003ffc),0x43544c2d);  // CTL-
> WriteMemory((bar0 + 0x00003ffc),0x43544c46);  // CTLF
> WriteMemory((bar0 + 0x00003ffc),0x43544c69);  // CTLi

This code snippet is found in OSS driver, but it's commented out
and mentioned that this causes hang up or so.
Thus I imagined that the master switching happening as well, too.

> >>>> At power on, the card is in UAA mode.
> >>>> In UAA mode, the UAA chip is the bus master.
> >>>> In 20K1 mode, the 20K1 chip is the bus master.
> >>>> Under either UAA mode or 20K1 mode, the driver can read and write the
> >>>> configuration space of both UAA chip and 20K1 chip.
> > 
> > Doesn't it mean that 20k1 chip gets the bus master automatically
> > when switch into 20k1 mode from UAA mode?
> (1) is a config space switch and PCI IDs switch, nothing else. It leaves
> the chip in UAA mode. (2) is the real mode change.

Looks like so.

> > Anyway ,20k1 mode switching is a mess.  This may screw up also the
> > internal room-keeping of struct pci.  Maybe we can't do it without
> > switching but just master mode switch?
> I agree that it is messy. I did not design the hardware. Maybe we need
> to make a suggestion on LKML so that we can make a call that updates the
> global kernel struct pci once we make the config space switch. I do not
> think we need to switch back from 20K1 to UAA mode. We already have
> hotplug for cardbus pccards, maybe we could use some of those calls.

Yeah, but we need a real hardware for testing before further actions.
Discussing without hardware tests is like refactoring a vaporware.


thanks,

Takashi