Skip to contentSkip to conversation

asihpi: Remove HPI4000

PATCH In review Eliot Blennerhassett 2 participants 5 messages Mar 6, 2008 – Mar 14, 2008

lore
Share & tools
lore
#0 lore raw

PATCH 3/5 asihpi: Remove HPI4000

Remove HPI4000

---

pci/asihpi/Makefile +1 -1
diff -r 6def4892d3f5 pci/asihpi/Makefile
@@ -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
 
pci/asihpi/hpimsgx.c +7 -6
diff -r 6def4892d3f5 pci/asihpi/hpimsgx.c
@@ -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;
pci/asihpi/hpipcida.h +0 -16
diff -r 6def4892d3f5 pci/asihpi/hpipcida.h
@@ -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,}
#1 lore raw
Quoted 1 line · 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.

#2 lore raw

At Fri, 07 Mar 2008 12:32:52 +1300,

Quoted 8 lines · Eliot Blennerhassett
Quoted 1 line · 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.

Quoted 7 lines

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

#3 lore raw
Quoted 10 lines · Takashi Iwai

At Fri, 07 Mar 2008 12:32:52 +1300,

Quoted 6 lines · Eliot Blennerhassett
Quoted 1 line · 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.

Quoted 9 lines
Quoted 7 lines

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.

Quoted 3 lines

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

#4 lore raw

At Fri, 14 Mar 2008 09:46:02 +1300,

Quoted 8 lines · Eliot Blennerhassett
Quoted 2 lines

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?

Quoted 2 lines

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.

Quoted 7 lines
Quoted 3 lines

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.

Quoted 4 lines

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