[alsa-devel] [PATCH 3/5] asihpi: Remove HPI4000
Remove HPI4000 Signed-off-by: Eliot Blennerhassett <linux@audioscience.com --- diff -r 6def4892d3f5 pci/asihpi/Makefile --- a/pci/asihpi/Makefile Mon Mar 03 11:05:48 2008 +0100 +++ b/pci/asihpi/Makefile Thu Mar 06 14:31:55 2008 +1300 @@ -7,7 +7,7 @@ include $(SND_TOPDIR)/Makefile.conf
snd-asihpi-objs := asihpi.o hpimod.o hpimsginit.o\ hpicmn.o hpifunc.o hpidebug.o hpidspcd.o\ - hpios_linux_kernel.o hpi4000.o hpi6000.o hpi6205.o hpimsgx.o + hpios_linux_kernel.o hpi6000.o hpi6205.o hpimsgx.o
obj-$(CONFIG_SND_ASIHPI) += snd-asihpi.o
diff -r 6def4892d3f5 pci/asihpi/hpimsgx.c --- a/pci/asihpi/hpimsgx.c Mon Mar 03 11:05:48 2008 +0100 +++ b/pci/asihpi/hpimsgx.c Thu Mar 06 12:21:49 2008 +1300 @@ -476,8 +476,6 @@ void HPI_MessageEx( ep_name = "HPI_6000"; else if (ep == HPI_6205) ep_name = "HPI_6205"; - else if (ep == HPI_4000) - ep_name = "HPI_4000"; else ep_name = "unknown";
@@ -598,7 +596,8 @@ static void InStreamClose( if (hOwner == aIStreamUserOpen[phm->wAdapterIndex][phm->u.d.wStreamIndex]. hOwner) { - /* HPI_DEBUG_LOG(INFO,"closing adapter %d instream %d owned by %p\n", + /* HPI_DEBUG_LOG(INFO,"closing adapter %d " + "instream %d owned by %p\n", phm->wAdapterIndex, phm->u.d.wStreamIndex, hOwner); */ aIStreamUserOpen[phm->wAdapterIndex][phm->u.d.wStreamIndex]. hOwner = NULL; @@ -701,7 +700,8 @@ static void OutStreamClose( if (hOwner == aOStreamUserOpen[phm->wAdapterIndex][phm->u.d.wStreamIndex]. hOwner) { - /* HPI_DEBUG_LOG(INFO,"closing adapter %d outstream %d owned by %p\n", + /* HPI_DEBUG_LOG(INFO,"closing adapter %d " + "outstream %d owned by %p\n", phm->wAdapterIndex, phm->u.d.wStreamIndex, hOwner); */ aOStreamUserOpen[phm->wAdapterIndex][phm->u.d.wStreamIndex]. hOwner = NULL; @@ -904,8 +904,9 @@ static u16 HPIMSGX_Init( phr->wError = HPI_ERROR_PROCESSING_MESSAGE; return phr->wError; } - /* if the adapter was created succesfully save the mapping for future use */ if (hr.wError == 0) { + /* the adapter was created succesfully + save the mapping for future use */ hpi_entry_points[hr.u.s.wAdapterIndex] = entry_point_func; /* prepare adapter (pre-open streams etc.) */ HPI_DEBUG_LOG(DEBUG, @@ -936,7 +937,7 @@ static void HPIMSGX_Cleanup( }
for (; wAdapter < wAdapterLimit; wAdapter++) { - /* printk(KERN_INFO "Cleanup adapter #%d\n",wAdapter); */ + /* printk(KERN_INFO "Cleanup adapter #%d\n",wAdapter); */ for (i = 0; i < HPI_MAX_STREAMS; i++) { if (hOwner == aOStreamUserOpen[wAdapter][i].hOwner) { struct hpi_message hm; diff -r 6def4892d3f5 pci/asihpi/hpipcida.h --- a/pci/asihpi/hpipcida.h Mon Mar 03 11:05:48 2008 +0100 +++ b/pci/asihpi/hpipcida.h Wed Mar 05 21:59:17 2008 +1300 @@ -34,20 +34,4 @@ HPI_PCI_VENDOR_ID_TI, HPI_ADAPTER_PCI204 HPI_PCI_VENDOR_ID_AUDIOSCIENCE, PCI_ANY_ID, 0, 0, (kernel_ulong_t) HPI_6000} , { -HPI_PCI_VENDOR_ID_MOTOROLA, HPI_ADAPTER_DSP56301, - HPI_PCI_VENDOR_ID_AUDIOSCIENCE, PCI_ANY_ID, 0, 0, - (kernel_ulong_t) HPI_4000} -, - /* look for ASI cards that have 0x12cf sub-vendor ID, - like the 4300 and 4601 */ -{ -HPI_PCI_VENDOR_ID_MOTOROLA, HPI_ADAPTER_DSP56301, 0x12CF, PCI_ANY_ID, - 0, 0, (kernel_ulong_t) HPI_4000} -, - /* look for ASI cards that have sub-vendor-ID = 0, - like the 4501, 4113 and 4215 revC and below */ -{ -HPI_PCI_VENDOR_ID_MOTOROLA, HPI_ADAPTER_DSP56301, 0, PCI_ANY_ID, 0, 0, - (kernel_ulong_t) HPI_4000} -, { 0,}
On Thursday 06 March 2008 14:49:18 Eliot Blennerhassett wrote:
Remove HPI4000
This also requires update to alsa-firmware/asihpi with files from http://audioscience.com/internet/download/firmware/dspbins30914.tar.gz
dsp4*.bin are no longer required.
Also alsa-driver/pci/asihpi/hpi4000.* are no longer required. AudioScience next stable driver release (3.10.0) will not include support for ASI4xxx cards.
AudioScience will continue to maintain our version 3.08.xx with bugfixes for these cards and ALSA 1.0.16 will be the last alsa release with support for ASI4xxx.
We are dropping support for the family because the cards are not in production any more, and we wont be adding new API support to the DSP code that will be required by new drivers.
regards
Eliot Blennerhassett AudioScience.
At Fri, 07 Mar 2008 12:32:52 +1300, Eliot Blennerhassett wrote:
On Thursday 06 March 2008 14:49:18 Eliot Blennerhassett wrote:
Remove HPI4000
This also requires update to alsa-firmware/asihpi with files from http://audioscience.com/internet/download/firmware/dspbins30914.tar.gz
dsp4*.bin are no longer required.
Oops, forgot to update this -- committed to HG tree now.
Also alsa-driver/pci/asihpi/hpi4000.* are no longer required. AudioScience next stable driver release (3.10.0) will not include support for ASI4xxx cards.
AudioScience will continue to maintain our version 3.08.xx with bugfixes for these cards and ALSA 1.0.16 will be the last alsa release with support for ASI4xxx.
OK. BTW, what if the newer firmware is loaded onto the old driver? Would it be safer to rename the firmware file for each incompatible version? If yes, we can change the asihpi driver code together with the firmware renames to couple tightly.
thanks,
Takashi
Takashi Iwai wrote:
At Fri, 07 Mar 2008 12:32:52 +1300, Eliot Blennerhassett wrote:
On Thursday 06 March 2008 14:49:18 Eliot Blennerhassett wrote:
Remove HPI4000
This also requires update to alsa-firmware/asihpi with files from http://audioscience.com/internet/download/firmware/dspbins30914.tar.gz
dsp4*.bin are no longer required.
Oops, forgot to update this -- committed to HG tree now.
Thanks.
Also alsa-driver/pci/asihpi/hpi4000.* are no longer required. AudioScience next stable driver release (3.10.0) will not include support for ASI4xxx cards.
AudioScience will continue to maintain our version 3.08.xx with bugfixes for these cards and ALSA 1.0.16 will be the last alsa release with support for ASI4xxx.
OK. BTW, what if the newer firmware is loaded onto the old driver?
Within limits (how far apart driver and firmware are) this will work. Mostly we are adding functions to the firmware, so old driver will work with new firmware but a new driver won't work with old firmware. Sometimes old functions are deprecated, but we don't remove them straight away.
In the windows world our "driver" install includes driver, firmware, userspace dll, python bindings, and mixer application all matching.
Would it be safer to rename the firmware file for each incompatible version? If yes, we can change the asihpi driver code together with the firmware renames to couple tightly.
The firmware images contain the HPI version encoded in the header. I will at least log a warning that the driver and firmware version do not match.
I guess its possible to use versioned file names. Did you have something in mind? Currently the filename is generated from an adapter ID:
sprintf(fw_name, "asihpi/dsp%04x.bin", nAdapter);
regards
-- Eliot
At Fri, 14 Mar 2008 09:46:02 +1300, Eliot Blennerhassett wrote:
OK. BTW, what if the newer firmware is loaded onto the old driver?
Within limits (how far apart driver and firmware are) this will work. Mostly we are adding functions to the firmware, so old driver will work with new firmware but a new driver won't work with old firmware. Sometimes old functions are deprecated, but we don't remove them straight away.
As long as the backward-compatibility is kept, I think it's fine to use the same name. What I'm concerned is rather the regression by the firmware package update.
So, I suppose the driver won't crash even if you have only the old firmware?
In the windows world our "driver" install includes driver, firmware, userspace dll, python bindings, and mixer application all matching.
Not that on Linux, obviously :) Of course, distros should provide the consistent packages, though.
Would it be safer to rename the firmware file for each incompatible version? If yes, we can change the asihpi driver code together with the firmware renames to couple tightly.
The firmware images contain the HPI version encoded in the header. I will at least log a warning that the driver and firmware version do not match.
That'll be good.
I guess its possible to use versioned file names. Did you have something in mind? Currently the filename is generated from an adapter ID:
sprintf(fw_name, "asihpi/dsp%04x.bin", nAdapter);
Well, you can simply add a version number suffix to the firmware name, such as, dspxxx-032011.bin. But, I think this versioned name is needed only if the firmware has compatibility issue. As long as the firmware has a certain level of compatibility, we can reuse the same name.
thanks,
Takashi
participants (2)
-
Eliot Blennerhassett -
Takashi Iwai