Re: Driver for TerraTec DMX 6Fire USB

[Torsten Schenk <torsten.schenk@zoho.com>]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

>It means that your driver code tree isn't sync'ed with the latest 
>tree. Just rebase your tree to the latest one. Or... 
The trick is, I have a kernel tree that only contains this Kconfig. So these two should be the same, because I copied them.
No matter, I edited the patch manually and hope it will perform as it should.

>I found that the recent kernel has linux/ihex.h helper functions. 
>They might help for simplifying the code. But, this can be done later 
>as a a clean-up. 
Yes, I also discovered this helper function, but it supports only some kind of binary ihex format. It did not accept
the text .ihx files.

> 
>> diff -Nur a/sound/usb/6fire/pcm.c b/sound/usb/6fire/pcm.c 
>> --- a/sound/usb/6fire/pcm.c    1970-01-01 01:00:00.000000000 +0100 
>> +++ b/sound/usb/6fire/pcm.c    2011-01-20 23:07:24.000000000 +0100 
>... 
>> +/* keep next two synced with 
>> + * FW_EP_W_MAX_PACKET_SIZE[] and RATES_MAX_PACKET_SIZE */ 
>> +static const int RATES_IN_PACKET_SIZE[] = { 228, 228, 420, 420, 404, 404 }; 
>> +static const int RATES_OUT_PACKET_SIZE[] = { 228, 228, 420, 420, 604, 604 }; 
>> +static const int RATES[] = { 44100, 48000, 88200, 96000, 176400, 192000 }; 
> 
>Any reason to use capital letters for these? 
>Because they are const? 
That was exactly the idea.

>Why x86-dependent? 
I thought so because of the firmware stuff. If bit- or byte-order are changed, the firmware uploading might not work. If I figured out the #ifdef stuff for bit and byte order, I will remove this dependency.

Thanks,
Torsten

[-- Attachment #2: usb6fire.tar.bz2 --]
[-- Type: application/octet-stream, Size: 13280 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

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