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