28 Jul
2011
28 Jul
'11
10:31 p.m.
Hi!
I've recently added support for the RME RPM to hdspmixer. Unfortunately,
I don't have one, it's been done blindly with user feedback.
This very user now reports that he needs to upload the device firmware
from windows. I've checked hdsploader, and of course, it needs patching.
I'll take care in a second.
More surprisingly, though, the kernel wasn't able to upload the firmware
itself, because it fails to detect the RPM and hence tries to upload a
multiface firmware.
After reading the kernel source, I think the code in hdsp.c is wrong:
if (hdsp_fifo_wait(hdsp, 0, HDSP_SHORT_WAIT)) {
hdsp_write(hdsp, HDSP_control2Reg, HDSP_VERSION_BIT);
hdsp_write(hdsp, HDSP_control2Reg, HDSP_S_LOAD);
if (hdsp_fifo_wait(hdsp, 0, HDSP_SHORT_WAIT))
hdsp->io_type = RPM;
else
hdsp->io_type = Multiface;
} else {
hdsp->io_type = Digiface;
}
Who here owns a Digiface and can confirm or deny that the kernel
correctly detects it as Digiface? Same for Multiface, though I guess
since it's more or less the default, users wouldn't notice it.
What's wrong with the code above? I think all occurrences of
HDSP_control2Reg in hdsp_check_for_iobox need to be changed to
HDSP_controlRegister and the second hdsp_fifo_wait needs to be inverted.
But this is pure guesswork. If I come up with a patch, who here has a
RPM, Digiface or Multiface to test it?
TIA
28 Jul
28 Jul
11:41 p.m.
On Thu, Jul 28, 2011 at 10:31:07PM +0200, Adrian Knoth wrote:
I've recently added support for the RME RPM to
hdspmixer. Unfortunately,
I don't have one, it's been done blindly with user feedback.
This very user now reports that he needs to upload the device firmware
from windows. I've checked hdsploader, and of course, it needs patching.
I'll take care in a second.
More surprisingly, though, the kernel wasn't able to upload the firmware
itself, because it fails to detect the RPM and hence tries to upload a
multiface firmware.
After reading the kernel source, I think the code in hdsp.c is wrong:
if (hdsp_fifo_wait(hdsp, 0, HDSP_SHORT_WAIT)) {
hdsp_write(hdsp, HDSP_control2Reg, HDSP_VERSION_BIT);
hdsp_write(hdsp, HDSP_control2Reg, HDSP_S_LOAD);
if (hdsp_fifo_wait(hdsp, 0, HDSP_SHORT_WAIT))
hdsp->io_type = RPM;
else
hdsp->io_type = Multiface;
} else {
hdsp->io_type = Digiface;
}
Who here owns a Digiface and can confirm or deny that the kernel
correctly detects it as Digiface? Same for Multiface, though I guess
since it's more or less the default, users wouldn't notice it.
What's wrong with the code above? I think all occurrences of
HDSP_control2Reg in hdsp_check_for_iobox need to be changed to
HDSP_controlRegister and the second hdsp_fifo_wait needs to be inverted.
But this is pure guesswork. If I come up with a patch, who here has a
RPM, Digiface or Multiface to test it?
I have an RPM wich I'd like to use as a signal generator for measurments
etc. (it has those nice balanced line outs). But I never managed to make
it work, despite trying 1000 variations on the code you quoted. It hangs
in one of the hdsp_fifo_wait(), I don't remember which one.
Ciao,
--
FA
11:56 p.m.
On Thu, Jul 28, 2011 at 09:41:09PM +0000, Fons Adriaensen wrote:
I blindly wrote a patch:
http://adi.loris.tv/hdsp_test.tar.bz2
Does it work? If you like and if it's possible to get remote access to
your machine, I'm happy to give it a whirl and start hacking.
I'm somewhat surprised to see so many "wrong" constants in hdsp.c, like
HDSP_fifoData being 368. I have no idea why it is there, I always
thought the fifo write register is 92. (that's what I've changed in the
hdsp_test.tar.bz2, too)
There are even more occurrences of control2Reg in hdsp.c which I would
change to controlRegister, especially in
snd_hdsp_load_firmware_from_cache. But it cannot be totally wrong,
because I guess it must be working for some users...
Cheers
After reading
the kernel source, I think the code in hdsp.c is wrong:
if (hdsp_fifo_wait(hdsp, 0, HDSP_SHORT_WAIT)) {
hdsp_write(hdsp, HDSP_control2Reg, HDSP_VERSION_BIT);
hdsp_write(hdsp, HDSP_control2Reg, HDSP_S_LOAD);
if (hdsp_fifo_wait(hdsp, 0, HDSP_SHORT_WAIT))
hdsp->io_type = RPM;
else
hdsp->io_type = Multiface;
} else {
hdsp->io_type = Digiface;
}
Who here owns a Digiface and can confirm or deny that the kernel
correctly detects it as Digiface? Same for Multiface, though I guess
since it's more or less the default, users wouldn't notice it.
What's wrong with the code above? I think all occurrences of
HDSP_control2Reg in hdsp_check_for_iobox need to be changed to
HDSP_controlRegister and the second hdsp_fifo_wait needs to be inverted.
But this is pure guesswork. If I come up with a patch, who here has a
RPM, Digiface or Multiface to test it?
I have an RPM wich I'd like to use as a signal generator for measurments
etc. (it has those nice balanced line outs). But I never managed to make
it work, despite trying 1000 variations on the code you quoted. It hangs
in one of the hdsp_fifo_wait(), I don't remember which one.
29 Jul
29 Jul
12:28 a.m.
On 07/28/11 23:56, Adrian Knoth wrote:
I blindly wrote a patch:
http://adi.loris.tv/hdsp_test.tar.bz2
Sorry, this was wrong, I've reuploaded the file. So either download
again or change lines 778 and 781 in hdsp.c: remove the "!" to invert
the logic.
Mea culpa.
12:43 a.m.
On 07/28/11 23:56, Adrian Knoth wrote:
>> After reading the kernel source, I think the code in hdsp.c is wrong:
>>
>> if (hdsp_fifo_wait(hdsp, 0, HDSP_SHORT_WAIT)) {
>> hdsp_write(hdsp, HDSP_control2Reg, HDSP_VERSION_BIT);
>> hdsp_write(hdsp, HDSP_control2Reg, HDSP_S_LOAD);
>> if (hdsp_fifo_wait(hdsp, 0, HDSP_SHORT_WAIT))
>> hdsp->io_type = RPM;
>> else
>> hdsp->io_type = Multiface;
>> } else {
>> hdsp->io_type = Digiface;
>> }
>>
>> What's wrong with the code above? I think all occurrences of
>> HDSP_control2Reg in hdsp_check_for_iobox need to be changed to
>> HDSP_controlRegister and the second hdsp_fifo_wait needs to be inverted.
Nope, it was correct. I got confused by bytes-vs-4byte-offsets to the
iobase.
So, control2Reg is right, the logic is right, too.
Only HDSP_VERSION_BIT seems wrong here, try
HDSP_VERSION_BIT | HDSP_S_LOAD
instead. Or change
#define HDSP_VERSION_BIT 0x100
to
#define HDSP_VERSION_BIT (0x100 | HDSP_S_LOAD)
Still pure guesswork.
I blindly wrote a patch:
http://adi.loris.tv/hdsp_test.tar.bz2
Forget it, it was stupid. Removed from the web.
Cheers
10:05 a.m.
On Fri, Jul 29, 2011 at 12:43:02AM +0200, Adrian Knoth wrote:
...
Nope, it was correct. I got confused by bytes-vs-4byte-offsets to the
iobase.
So, control2Reg is right, the logic is right, too.
Only HDSP_VERSION_BIT seems wrong here, try
HDSP_VERSION_BIT | HDSP_S_LOAD
instead. Or change
#define HDSP_VERSION_BIT 0x100
to
#define HDSP_VERSION_BIT (0x100 | HDSP_S_LOAD)
Still pure guesswork.
If you can send me the complete driver source so I just have
to do make and make install I could probably try it out during
the weekend. But the amount of time I can spend on it is limited.
--
FA
12:22 a.m.
On Thu, Jul 28, 2011 at 4:31 PM, Adrian Knoth <adi(a)drcomp.erfurt.thur.de> wrote:
Who here owns a Digiface and can confirm or deny that
the kernel
correctly detects it as Digiface? Same for Multiface, though I guess
since it's more or less the default, users wouldn't notice it.
i have a digiface and it is correctly detected.
alas, i'll be away for about 10 days starting tomorrow, so i can't
test your patch.
--p
4862
days inactive
4863
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
3 participants
participants (3)
-
Adrian Knoth -
Fons Adriaensen -
Paul Davis