you can get the same output with
hexdump -v /proc/bus/pci/BUS/DEVICE
where BUS/DEVICE is the CB controller. eg. 00/09.0
about the bits:
- at 81h, from D0 to 90: this is part of the system control register. the bit
that changed is "Memory read burst enable upstream"
- at c9h, from 04 to 06: this is an undocumented test register. TI just says
reserved, EnE says test register, for the bit that changed it adds the
comment TLTEnable (default to 1). no idea what it is. it _could_ have
something to do with the cardbus latency timer...you can try to play a bit
with the latency setting after resume when this bit is set. try writing to
offset 1Bh, put in at least 40h
to change the bits under linux, use setpci (also good for reading)
about the memory read burst upstream: 2.6 kernels enable it for most of
the TI chips and since 2.6.5 also for some TI clones from EnE (incl. EnE1410).
rgds
-daniel
Thank you very much for an exhaustive breakdown of this issue! Your
assistance has been truly helpful!
I am aware that this burst stuff should be enabled on the 2.6 kernel,
however I am still getting bad results.
The 06 to 04 may be the critical element as even when I have everything
properly running in Win32, when I alter this number the distortion returns
(it is almost like an azimuth on old analogue tape decks that one would
adjust using screwdriver in order to successfully load a program into a
Commodore64 or the legendary Sinclair ZX Spectrum :-).
If I do figure out the problem in Linux and find out that a particular
register is the issue, how can I make my linux box adjust this register at
boot-time (a simple hack-like script in a form of a service comes to mind
but I was hoping to perhaps see a more universal solution if possible)?
Best wishes,
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
> -----Original Message-----
> From: Daniel Ritz [mailto:[email protected]]
> Sent: Friday, April 09, 2004 9:48 PM
> To: Ivica Ico Bukvic
> Cc: linux-kernel
> Subject: RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion
> -- First good news
>
> you can get the same output with
> hexdump -v /proc/bus/pci/BUS/DEVICE
> where BUS/DEVICE is the CB controller. eg. 00/09.0
>
> about the bits:
> - at 81h, from D0 to 90: this is part of the system control register. the
> bit
> that changed is "Memory read burst enable upstream"
> - at c9h, from 04 to 06: this is an undocumented test register. TI just
> says
> reserved, EnE says test register, for the bit that changed it adds the
> comment TLTEnable (default to 1). no idea what it is. it _could_ have
> something to do with the cardbus latency timer...you can try to play a
> bit
> with the latency setting after resume when this bit is set. try writing
> to
> offset 1Bh, put in at least 40h
>
> to change the bits under linux, use setpci (also good for reading)
>
> about the memory read burst upstream: 2.6 kernels enable it for most of
> the TI chips and since 2.6.5 also for some TI clones from EnE (incl.
> EnE1410).
>
> rgds
> -daniel
(Note: I've dropped one of the mailing lists from the CC line because
they appear to have zero interest in my messages.)
On Fri, Apr 09, 2004 at 11:30:31PM -0400, Ivica Ico Bukvic wrote:
> I am aware that this burst stuff should be enabled on the 2.6 kernel,
> however I am still getting bad results.
Are you saying that you have tried the 2.6.5 kernel?
> The 06 to 04 may be the critical element as even when I have everything
> properly running in Win32, when I alter this number the distortion returns
$ setpci -s a.0 0xc9.b
will display the value of this register under Linux, and:
$ setpci -s a.0 0xc9.b=value
will set it to the desired value. However, check that a.0 is the
cardbus bridge first by using:
$ lspci
> If I do figure out the problem in Linux and find out that a particular
> register is the issue, how can I make my linux box adjust this register at
> boot-time (a simple hack-like script in a form of a service comes to mind
> but I was hoping to perhaps see a more universal solution if possible)?
The correct solution is to put a quirk into the kernels yenta driver,
but we'd need the results from your testing first.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
hi all,
> > The 06 to 04 may be the critical element as even when I have
> > everything properly running in Win32, when I alter this number the
> > distortion returns
>
> $ setpci -s a.0 0xc9.b
>
> will display the value of this register under Linux, and:
>
> $ setpci -s a.0 0xc9.b=value
i tried to read these registers on my cardbus bridge but on my system
the registers are zero (00) ...
i tried to set these registers to the values ico had on his machines,
but it seems that i'm not able to set them ... if i read the registers
after setting them, they are still zero ...
is it possible to find out what this register is actually representing?
cheers...
Tim mailto:[email protected]
ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
Jack Kerouac
On Sunday 11 April 2004 18:08, Tim Blechmann wrote:
> hi all,
>
> > > The 06 to 04 may be the critical element as even when I have
> > > everything properly running in Win32, when I alter this number the
> > > distortion returns
> >
> > $ setpci -s a.0 0xc9.b
> >
> > will display the value of this register under Linux, and:
> >
> > $ setpci -s a.0 0xc9.b=value
> i tried to read these registers on my cardbus bridge but on my system
> the registers are zero (00) ...
> i tried to set these registers to the values ico had on his machines,
> but it seems that i'm not able to set them ... if i read the registers
> after setting them, they are still zero ...
that register is specific to TI/EnE bridges. if i remember correctly, you
have a o2micro 6933, right?
Hi all! Great news! I managed to fix the issue in Linux. As I suspected it
was the same problem like in Windows after suspend as the distortion was
similar.
Many thanks to all for all your help! Without you I would be still stuck on
this one tearing my hair out :-).
Conclusion:
===========
Hdsp after adjusting the controller settings works absolutely flawlessly.
Yay!
-----------------------------------------------------
Things that are require attention in order for this fix to work (ENE CB1410
cardbus controller):
1) CRITICAL: Yenta_socket driver needs to be mended to adjust the proper
registers for the ENE CB1410 cardbus as follows*:
a) register 0xc9 on mine was 0x06 (like in Windows after resume) and should
be 0x04 (like in Windows before resume)
b) register 0x81 was 0x90 (again like Windows after resume) and after
connecting the cardbus it was 0xb0, yet in both cases should be 0xd0** (like
in Windows before resume)
*NOTE: It is possible that this kind of behavior might be in part due to the
buggy BIOS of this notebook. Arima is currently working with me in trying to
resolve this possibly utilizing updated BIOS. Nonetheless, IMHO it would be
nice to have this added to the yenta_socket as Arima's successfulness at
fixing it is yet to be ascertained and this one truly seems like a
low-impact fix for the driver.
**I've noted that when I use:
setpci -s a.0 0x81.b
after changing the value to 0xd0 (with setpci -s a.0 0x81.b=d0) it would
tell me that it was equal to f0, yet the "hexdump -v /proc/bus/pci/00/0a.0"
would tell me it was d0 after all (see the log below).
----------
2) PREFERRED: hdsp driver needs to adjust the cardbus controller latency
upon connection and/or resume from standby to ff (even though it will likely
play on the lower latencies as well, this way it will be less likely to
produce xruns and since official RME's driver for Windows does this, Linux
IMHO likely ought to keep-up with their driver and offer same
functionality/behavior for easier troubleshooting).
The register in question is 0x0d (mine was by default in Windows at 0x20
before connection and at 0xff after connection, while in Linux it was at
0xa8 both before and after connecting the cardbus which suggests that the
driver did not properly ramp-up its value to 0xff).
3) FOR FURTHER INVESTIGATION: Does linux hdsp driver force the f0 value upon
the 0x81 register or is it that in Linux one simply cannot select d0 value
for whatever reason (specifying it would revert the value to f0, yet that
did not directly affect the sound and judging from the suggestions of others
that this is a switch for enabling memory burst read stuff perhaps it only
takes two values and each of them possibly populate a range in which case it
should be ok either way). I need to check this a bit more just to see if the
f0 really does mess it up or not.
-----------------------------------------------------
Here's the relevant log of the activity (I am way to tired to convert the
following into a meaningful prose so I am including the console log with
some annotations in parentheses):
<BEGIN>
[root@localhost 00]# hexdump
-v /proc/bus/pci/00/0a.0
0000000 1524 1410 0007 0210 0000 0607 a808 0002
0000010 f000 ffe7 00a0 0200 0200 b005 e000 ffe7
0000020 e000 ffe7 0000 2000 f000 203f 5000 0000
0000030 50fc 0000 5400 0000 54fc 0000 010b 05c0
0000040 161f 2032 0001 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000080 9021 4044 0000 0000 0000 0000 1002 0100
0000090 82c0 6044 0000 0000 0000 0000 0000 0000
00000a0 0001 fe01 0000 00c0 0000 0000 001f 0000
00000b0 0000 0000 0000 0000 0000 0000 0000 0000
00000c0 1000 0000 0080 0080 0600 1008 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
00000f0 0000 0000 0000 0000 0000 0000 0000 0000
0000100
(compare this with a screenshot in Windows -- please note that the value
pairs are reversed for whatever reason (endianness?); the Win32 screenshot
can be found here:
http://meowing.ccm.uc.edu/~ico/eMachines/SE-before_suspend.jpg ; please note
that the numbers are almost identical)
[root@localhost Documents]# setpci -s a.0 0xc9.b
06
(this ought to be 04)
[root@localhost Documents]# setpci -s a.0 0x81.b
90
(this ought to be d0)
[root@localhost Documents]# hdsploader
hdsploader - firmware loader for RME Hammerfall
DSP cards
Looking for HDSP + Multiface or Digiface cards :
Card 0 : VIA 8235 at 0x1000, irq 10
Card 1 : RME Hammerfall DSP at 0x20000000, irq
11
Upload firmware for card hw:1
Firmware uploaded for card hw:1
[root@localhost Documents]# hexdump
-v /proc/bus/pci/00/0a.0
0000000 1524 1410 0007 0210 0000 0607 a808 0002
0000010 f000 ffe7 00a0 0200 0200 b005 e000 ffe7
0000020 e000 ffe7 0000 2000 f000 203f 5000 0000
0000030 50fc 0000 5400 0000 54fc 0000 010b 0500
0000040 161f 2032 0001 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000080 b021 4044 0000 0000 0000 0000 1002 0100
0000090 82c0 6044 0000 0000 0000 0000 0000 0000
00000a0 0001 fe01 0000 00c0 0801 0000 001f 0000
00000b0 0000 0000 0000 0000 0000 0000 0000 0000
00000c0 1000 0000 0080 0080 0600 1008 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
00000f0 0000 0000 0000 0000 0000 0000 0000 0000
0000100
(hmmm, register 0x81 just became 0xb0 after reconnect but both values are
wrong)
[root@localhost Documents]# setpci -s a.0
0xc9.b=04
(ok, here goes nothing :-)
[root@localhost Documents]# setpci -s a.0 0xc9.b
04
(so far so good)
[root@localhost Documents]# setpci -s a.0
0x81.b=D0
[root@localhost Documents]# setpci -s a.0 0x81.b
f0
(oops? Let's try that again:)
[root@localhost Documents]# setpci -s a.0
0x81.b=D0
[root@localhost Documents]# setpci -s a.0 0x81.b
f0
(hmmm, let's see the hexdump)
[root@localhost Documents]# hexdump
-v /proc/bus/pci/00/0a.0
0000000 1524 1410 0007 0210 0000 0607 a808 0002
0000010 f000 ffe7 00a0 0200 0200 b005 e000 ffe7
0000020 e000 ffe7 0000 2000 f000 203f 5000 0000
0000030 50fc 0000 5400 0000 54fc 0000 010b 0500
0000040 161f 2032 0001 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000080 d021 4044 0000 0000 0000 0000 1002 0100
0000090 82c0 6044 0000 0000 0000 0000 0000 0000
00000a0 0001 fe01 0000 00c0 0801 0000 001f 0000
00000b0 0000 0000 0000 0000 0000 0000 0000 0000
00000c0 1000 0000 0080 0080 0400 1008 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
00000f0 0000 0000 0000 0000 0000 0000 0000 0000
0000100
(well it says here it is 0xd0 so I guess I'll take hexdump's word for it)
[root@localhost Documents]# hdspconf
HDSPConf 1.4 - Copyright (C) 2003 Thomas
Charbonnel <[email protected]>
This program comes WITH ABSOLUTELY NO WARRANTY
HDSPConf is free software, see the file copying
for details
Looking for HDSP cards :
Card 0 : VIA 8235 at 0x1000, irq 10
Card 1 : RME Hammerfall DSP + Multiface at
0x20000000, irq 11
Multiface found !
1 Hammerfall DSP card found.
[root@localhost Documents]# hexdump
-v /proc/bus/pci/00/0a.0
0000000 1524 1410 0007 0210 0000 0607 a808 0002
0000010 f000 ffe7 00a0 0200 0200 b005 e000 ffe7
0000020 e000 ffe7 0000 2000 f000 203f 5000 0000
0000030 50fc 0000 5400 0000 54fc 0000 010b 0500
0000040 161f 2032 0001 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000080 f021 4044 0000 0000 0000 0000 1002 0100
0000090 82c0 6044 0000 0000 0000 0000 0000 0000
00000a0 0001 fe01 0000 00c0 0801 0000 001f 0000
00000b0 0000 0000 0000 0000 0000 0000 0000 0000
00000c0 1000 0000 0080 0080 0400 1008 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
00000f0 0000 0000 0000 0000 0000 0000 0000 0000
0000100
(dang it! 0xf0 even in hexdump now, let's try it again:)
[root@localhost Documents]# setpci -s a.0
0x81.b=d0
[root@localhost Documents]# setpci -s a.0 0x81.b
f0
(DOH!)
[root@localhost Documents]# hexdump
-v /proc/bus/pci/00/0a.0
0000000 1524 1410 0007 0210 0000 0607 a808 0002
0000010 f000 ffe7 00a0 0200 0200 b005 e000 ffe7
0000020 e000 ffe7 0000 2000 f000 203f 5000 0000
0000030 50fc 0000 5400 0000 54fc 0000 010b 0500
0000040 161f 2032 0001 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000080 d021 4044 0000 0000 0000 0000 1002 0100
0000090 82c0 6044 0000 0000 0000 0000 0000 0000
00000a0 0001 fe01 0000 00c0 0801 0000 001f 0000
00000b0 0000 0000 0000 0000 0000 0000 0000 0000
00000c0 1000 0000 0080 0080 0400 1008 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
00000f0 0000 0000 0000 0000 0000 0000 0000 0000
0000100
(at least hexdump is happy)
[root@localhost Documents]# hdspmixer
HDSPMixer 1.6 - Copyright (C) 2003 Thomas
Charbonnel <[email protected]>
This program comes with ABSOLUTELY NO WARRANTY
HDSPMixer is free software, see the file COPYING
for details
Looking for HDSP cards :
Card 0 : VIA 8235 at 0x1000, irq 10
Card 1 : RME Hammerfall DSP + Multiface at
0x20000000, irq 11
Multiface found !
1 Hammerfall DSP card found.
Initializing default presets
(let's set the latency how RME likes it)
[root@localhost Documents]# setpci -s a.0 0x0d.b
a8
[root@localhost Documents]# setpci -s a.0
0x0d.b=ff
(at this point I played the sound using jack and jack_metro and the thing
sounded like a beautiful...sine tone :-)
<END>
Again, thanks all for your help!
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
On Sun, Apr 11, 2004 at 09:39:43PM -0400, Ivica Ico Bukvic wrote:
> Hi all! Great news! I managed to fix the issue in Linux. As I suspected it
> was the same problem like in Windows after suspend as the distortion was
> similar.
Don't think the problem is 100% solved just yet - there's still work
to do.
You haven't said which kernel version you're using to test this out
on; 2.6.5 contains some fixes for the CB1410 in these areas, and it
would be useful to know if these are working.
So, as per my previous mail and at risk of sounding like a stuck
record^wCD, which kernel version are you using for this test?
Have you also tried only changing a limited subset of these
registers? The reason this is important is that just immitating
the working scenario out right doesn't really tell us very much.
You should be able to tweak these while the card is playing, so
you could try setting them all to the "working" state, play back
the audio, and then try undoing each change individually.
> 2) PREFERRED: hdsp driver needs to adjust the cardbus controller latency
No. Drivers should not fiddle with other parts of the system they
don't own, and the HDSP driver does not own the cardbus controller.
I suspect that the CB1410 quirk needs to force the latency timer at
startup.
> 3) FOR FURTHER INVESTIGATION: Does linux hdsp driver force the f0 value upon
> the 0x81 register or is it that in Linux one simply cannot select d0 value
> for whatever reason
I suspect it may be caused by using a byte access to a longword-sized
register. 0x81 is supposed to be accessed via:
setpci -s a.0 0x80.l
which of course means its bits 8 to 15.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Mon, Apr 12, 2004 at 08:28:01AM +0100, Russell King wrote:
>
> > 3) FOR FURTHER INVESTIGATION: Does linux hdsp driver force the f0
> > value upon the 0x81 register or is it that in Linux one simply
> > cannot select d0 value for whatever reason
>
> I suspect it may be caused by using a byte access to a longword-sized
> register. 0x81 is supposed to be accessed via:
>
> setpci -s a.0 0x80.l
>
> which of course means its bits 8 to 15.
I don't think so; I'm not sure what the PCI spec has to say about it,
but I have not had problems doing byte reads/writes for longer PCI
configuration registers. Bit 9 of the sysctl register for the TI 1410
is "socket activity"; it is read only and is cleared after each read.
The key change is setting bit 14 (enable upstream burst reads).
Regarding the register at 0xc9, I don't think that is defined in any
TI bridge data sheet; it is in a "reserved" range.
-- Dave
On Mon, Apr 12, 2004 at 02:08:17AM -0700, David Hinds wrote:
> I don't think so; I'm not sure what the PCI spec has to say about it,
Yup, you're right.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
hi ico, hi russell
first of all, congratulations that you, ico, got your hdsp working ...
anyway the registers you were changing have no effect on my setup ... they are zero:
your configuration:
> [root@localhost 00]# hexdump
> -v /proc/bus/pci/00/0a.0
> 0000000 1524 1410 0007 0210 0000 0607 a808 0002
> 0000010 f000 ffe7 00a0 0200 0200 b005 e000 ffe7
> 0000020 e000 ffe7 0000 2000 f000 203f 5000 0000
> 0000030 50fc 0000 5400 0000 54fc 0000 010b 05c0
> 0000040 161f 2032 0001 0000 0000 0000 0000 0000
> 0000050 0000 0000 0000 0000 0000 0000 0000 0000
> 0000060 0000 0000 0000 0000 0000 0000 0000 0000
> 0000070 0000 0000 0000 0000 0000 0000 0000 0000
> 0000080 9021 4044 0000 0000 0000 0000 1002 0100
> 0000090 82c0 6044 0000 0000 0000 0000 0000 0000
> 00000a0 0001 fe01 0000 00c0 0000 0000 001f 0000
> 00000b0 0000 0000 0000 0000 0000 0000 0000 0000
> 00000c0 1000 0000 0080 0080 0600 1008 0000 0000
> 00000d0 0000 0000 0000 0000 0000 0000 0000 0000
> 00000e0 0000 0000 0000 0000 0000 0000 0000 0000
> 00000f0 0000 0000 0000 0000 0000 0000 0000 0000
> 0000100
mine: (kernel 2.6.4-ck1 and 2.6.5-gentoo have the same results)
bash-2.05b# hexdump -v /proc/bus/pci/02/00.1
0000000 1217 6933 0087 0410 0001 0607 a800 0082
0000010 1000 2000 00a0 0200 0702 b00a 0000 20c0
0000020 f000 20ff 0000 2100 f000 213f 4c01 0000
0000030 4cfd 0000 5001 0000 50fd 0000 0200 0580
0000040 1025 0019 0001 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000080 0000 0000 0000 0000 0000 0000 0000 0000
0000090 23bf 4c00 03e8 8242 0000 2050 0000 0000
00000a0 0001 fe02 4000 00c0 0000 0000 0000 0000
00000b0 0000 0000 0000 0000 0000 0000 0000 0000
00000c0 0000 0000 0000 0000 0000 0000 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
00000f0 0000 0000 0000 0000 0000 0000 0000 0000
0000100
after plugging the hdsp in:
> bash-2.05b# hexdump -v /proc/bus/pci/02/00.1
> 0000000 1217 6933 0087 0410 0001 0607 a800 0082
> 0000010 1000 2000 00a0 0200 0702 b00a 0000 20c0
> 0000020 f000 20ff 0000 2100 f000 213f 4c01 0000
> 0000030 4cfd 0000 5001 0000 50fd 0000 0200 0500
> 0000040 1025 0019 0001 0000 0000 0000 0000 0000
> 0000050 0000 0000 0000 0000 0000 0000 0000 0000
> 0000060 0000 0000 0000 0000 0000 0000 0000 0000
> 0000070 0000 0000 0000 0000 0000 0000 0000 0000
> 0000080 0000 0000 0000 0000 0000 0000 0000 0000
> 0000090 23bf 4c00 03e8 8242 0000 2050 0000 0000
> 00000a0 0001 fe02 4000 00c0 0000 0000 0000 0000
> 00000b0 0000 0000 0000 0000 0000 0000 0000 0000
> 00000c0 0000 0000 0000 0000 0000 0000 0000 0000
> 00000d0 0000 0000 0000 0000 0000 0000 0000 0000
> 00000e0 0000 0000 0000 0000 0000 0000 0000 0000
> 00000f0 0000 0000 0000 0000 0000 0000 0000 0000
> 0000100
the only register that's changing after plugging the hdsp in is the MIN_GNT register ... (from 0x80 to 0x00)
the registers ico changed are 00 on my system ... possibly i'll have to install windows on my machine to figure out, if i have the same problem as ico ...
cheers...
Tim mailto:[email protected]
ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
Jack Kerouac
On Mon, Apr 12, 2004 at 01:02:36PM +0200, Tim Blechmann wrote:
> first of all, congratulations that you, ico, got your hdsp working ...
Only the first 0x48 registers are defined by the base specification;
the rest are chip and/or manufacturer specific.
The registers which Ico is changing are specific to the ENE CB1410,
which are a clone of the TI chips.
Your cardbus bridge isn't a clone of TI, so I wouldn't expect the
same fix to work for you.
However, we now have some of the clues, so...
PS, in your first mail I have on this subject, you mentioned someone
called "Timothy" who had the same problem, and was using Red Hat with
a TI bridge. I don't seem to have any responses from him, and it would
be good to get some feedback from him as well. Specifically whether
stock 2.6.5 works or exhibits the same problem.
Stock 2.6.5 with TI bridges should already set 0x81 to 0xd0, and they
don't have the other register at 0xc9. This only leaves the cardbus
bridge latency timer.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
> Only the first 0x48 registers are defined by the base specification;
> the rest are chip and/or manufacturer specific.
i see ...
> The registers which Ico is changing are specific to the ENE CB1410,
> which are a clone of the TI chips.
>
> Your cardbus bridge isn't a clone of TI, so I wouldn't expect the
> same fix to work for you.
:-(
do you want me to install windows and have a look at my register settings on a working setup? since my problem might be a different one, i just want to make sure that its neccessary that i install windows ... i'd have to back up a lot of stuff, so it would take some time...
> PS, in your first mail I have on this subject, you mentioned someone
> called "Timothy" who had the same problem, and was using Red Hat with
> a TI bridge. I don't seem to have any responses from him, and it i forwarded this mail to him ... i hope he will respond, soon...
cheers...
Tim mailto:[email protected]
ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
Jack Kerouac
> Don't think the problem is 100% solved just yet - there's still work
> to do.
>
> You haven't said which kernel version you're using to test this out
> on; 2.6.5 contains some fixes for the CB1410 in these areas, and it
> would be useful to know if these are working.
>
> So, as per my previous mail and at risk of sounding like a stuck
> record^wCD, which kernel version are you using for this test?
Sorry :-) Mandrake Community 10.0 using the 2.6.3 kernel with a patch to fix
the freezing when probing for the pcmcia card on this particular notebook
(see: http://www.muru.com/linux/amd64/).
> Have you also tried only changing a limited subset of these
> registers? The reason this is important is that just immitating
> the working scenario out right doesn't really tell us very much.
Tried various combinations in Windows and only using the 2 in combination
worked. I will test further in Linux if you like when I get the chance. But
as of right now I have a hunch that the same behavior will be observed in
Linux as one value enables burst stuff, while the other value when changed
also introduced distortion (micro-silence between buffers) in Windows if any
other value was used than 0x04.
> You should be able to tweak these while the card is playing, so
> you could try setting them all to the "working" state, play back
> the audio, and then try undoing each change individually.
Will do. I did that with the latency and it still worked for the
before-mentioned reasons but the preferred behavior would be having it at
0xff as that is how the Win driver behaves. However, changing the latency
on-the-fly while JACK audio server and audio is running results in corrupted
audio and JACK needs to be restarted (this is most likely issue with the
fact I was using JACK).
> > 2) PREFERRED: hdsp driver needs to adjust the cardbus controller latency
>
> No. Drivers should not fiddle with other parts of the system they
> don't own, and the HDSP driver does not own the cardbus controller.
> I suspect that the CB1410 quirk needs to force the latency timer at
> startup.
Well, in Windows the latency on the controller is 0x20 and then when the
cardbus soundcard (RME) is inserted it is changed into 0xFF. Matthias, the
support guy from RME also confirmed this behavior (that their driver is
changing the value upon connection).
> > 3) FOR FURTHER INVESTIGATION: Does linux hdsp driver force the f0 value
> upon
> > the 0x81 register or is it that in Linux one simply cannot select d0
> value
> > for whatever reason
>
> I suspect it may be caused by using a byte access to a longword-sized
> register. 0x81 is supposed to be accessed via:
>
> setpci -s a.0 0x80.l
>
> which of course means its bits 8 to 15.
Sounds like that was most likely it. I will test it as soon as I get the
chance to do so.
Thank you very much for all your help!
Best wishes,
Ico
On Mon, Apr 12, 2004 at 10:40:59AM -0400, Ivica Ico Bukvic wrote:
> Sorry :-) Mandrake Community 10.0 using the 2.6.3 kernel with a patch to fix
> the freezing when probing for the pcmcia card on this particular notebook
> (see: http://www.muru.com/linux/amd64/).
Pavel's fix isn't really a fix, it's more a work-around. If we keep
increasing PCIBIOS_MIN_CARDBUS_IO until we hit 0xffff, everyones
system stops working.
The problem there will be that there's some IO registers between 0x4000
and 0x5000 which the BIOS wants access to, but the kernel didn't know
that they existed.
In any case, 2.6.3 does not contain the patches for CB1410, so chances
are that your problem is already half solved in 2.6.5.
Ok, so the action plan is:
- set 0xc9 to 0x04 for CB1410 (and others?)
- find a reasonable solution to the latency timer, maybe just setting it
to 0xff when we detect the bridge.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Monday 12 April 2004 03:39, Ivica Ico Bukvic wrote:
> **I've noted that when I use:
>
> setpci -s a.0 0x81.b
>
> after changing the value to 0xd0 (with setpci -s a.0 0x81.b=d0) it would
> tell me that it was equal to f0, yet the "hexdump -v /proc/bus/pci/00/0a.0"
> would tell me it was d0 after all (see the log below).
>
it's a single bit change from 0xd0 to 0xf0. it's bit 13 of the system control
register at 0x80. it's the socket activity bit that is read-clear. this means
writing to it has no effect, reading it clears the content. so the behavior
is normal...
On Monday 12 April 2004 16:53, Russell King wrote:
> On Mon, Apr 12, 2004 at 10:40:59AM -0400, Ivica Ico Bukvic wrote:
> > Sorry :-) Mandrake Community 10.0 using the 2.6.3 kernel with a patch to fix
> > the freezing when probing for the pcmcia card on this particular notebook
> > (see: http://www.muru.com/linux/amd64/).
>
> Pavel's fix isn't really a fix, it's more a work-around. If we keep
> increasing PCIBIOS_MIN_CARDBUS_IO until we hit 0xffff, everyones
> system stops working.
>
> The problem there will be that there's some IO registers between 0x4000
> and 0x5000 which the BIOS wants access to, but the kernel didn't know
> that they existed.
>
> In any case, 2.6.3 does not contain the patches for CB1410, so chances
> are that your problem is already half solved in 2.6.5.
>
> Ok, so the action plan is:
>
> - set 0xc9 to 0x04 for CB1410 (and others?)
EnE datasheet says it's also available in EnE 1211, 1225, 1420.
and since they are TI clones why not for the TI's too?
ico,
one question. when you insert the card in windows it changes
the latency timer at 0x0d to 0xff. what is the value at 0x1b? is it also 0xff?
if it's not 0xff can you try changing it to 0xff and set 0xc9 to 0x06?
i ask 'cos your screenshot w/o the card has it set to 0x00. and i have
the feeling that the bit at 0xc9 has something to do with the latency
timers....
rgds
-daniel
On Mon, Apr 12, 2004 at 05:31:20PM +0200, Daniel Ritz wrote:
> EnE datasheet says it's also available in EnE 1211, 1225, 1420.
> and since they are TI clones why not for the TI's too?
Because the register supposedly does not exist on TI - it's likely to be
EnE specific.
I'm willing to bet that TI chips will behave as expected without touching
0xc9 at all.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Monday 12 April 2004 17:38, Russell King wrote:
> On Mon, Apr 12, 2004 at 05:31:20PM +0200, Daniel Ritz wrote:
> > EnE datasheet says it's also available in EnE 1211, 1225, 1420.
> > and since they are TI clones why not for the TI's too?
>
> Because the register supposedly does not exist on TI - it's likely to be
> EnE specific.
>
> I'm willing to bet that TI chips will behave as expected without touching
> 0xc9 at all.
you win. just booted my TI1410 laptop . 0xc9 is 0 and read-only.
so the EnE's are not 100% TI clone...
hi all,
i installed windows to check if there is anything happening to the
cardbus registers when working on a supported system... the cardbus
registers, beside the pci registers, are the same as on the linux system
...
i haven't been able to play back some sounds, because rme's driver disc
only contains the win2k driver ...
i have no idea, what this might tell us ... it's not a very good feeling
if someone who seem to have the same problem as yourself finds the
reason for his problem, but it doesn't seem to be the reason of your
problem ... anyway, let's hope the best...
cheers...
Tim mailto:[email protected]
ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
Jack Kerouac
hi russell and others ...
i'm curious, since our discussion got quiet in the last few days ... if
ico was able to solve his problem by altering cardbus registers, but my
hdsp works fine with windows with the same register settings on the
cardbus bridge that won't work with linux ... what does this imply to my
setup? do you have any idea, where could be the problem?
my system doesn't have the pci bus connected directly to the cardbus
bridge, but there is a pci-to-pci bridge in between ... i found a
register difference between the windows and the linux settings in that
... but changing this register doesn't change the behaviour of the hdsp
:-(
cheers...
Tim mailto:[email protected]
ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
Jack Kerouac
