[alsa-devel] 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