Re: [PATCH] hamradio: baycom: use new parport device model
Acked-By: Thomas Sailer <t.sai...@alumni.ethz.ch>
Am 17.09.2017 um 13:46 schrieb Sudip Mukherjee:
Modify baycom driver to use the new parallel port device model.
Signed-off-by: Sudip Mukherjee <sudipm.mukher...@gmail.com>
---
Not tested on real hardware, only tested on qemu and verified that the
device is binding to the driver properly in epp_open but then unbinding
as the device was not found.
drivers/net/hamradio/baycom_epp.c | 50 +++
1 file changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/net/hamradio/baycom_epp.c
b/drivers/net/hamradio/baycom_epp.c
index 1503f10..1e62d00 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -840,6 +840,7 @@ static int epp_open(struct net_device *dev)
unsigned char tmp[128];
unsigned char stat;
unsigned long tstart;
+ struct pardev_cb par_cb;
if (!pp) {
printk(KERN_ERR "%s: parport at 0x%lx unknown\n", bc_drvname,
dev->base_addr);
@@ -859,8 +860,21 @@ static int epp_open(struct net_device *dev)
return -EIO;
}
memset(>modem, 0, sizeof(bc->modem));
-bc->pdev = parport_register_device(pp, dev->name, NULL, epp_wakeup,
- NULL, PARPORT_DEV_EXCL, dev);
+ memset(_cb, 0, sizeof(par_cb));
+ par_cb.wakeup = epp_wakeup;
+ par_cb.private = (void *)dev;
+ par_cb.flags = PARPORT_DEV_EXCL;
+ for (i = 0; i < NR_PORTS; i++)
+ if (baycom_device[i] == dev)
+ break;
+
+ if (i == NR_PORTS) {
+ pr_err("%s: no device found\n", bc_drvname);
+ parport_put_port(pp);
+ return -ENODEV;
+ }
+
+ bc->pdev = parport_register_dev_model(pp, dev->name, _cb, i);
parport_put_port(pp);
if (!bc->pdev) {
printk(KERN_ERR "%s: cannot register parport at 0x%lx\n",
bc_drvname, pp->base);
@@ -1185,6 +1199,23 @@ MODULE_LICENSE("GPL");
/* - */
+static int baycom_epp_par_probe(struct pardevice *par_dev)
+{
+ struct device_driver *drv = par_dev->dev.driver;
+ int len = strlen(drv->name);
+
+ if (strncmp(par_dev->name, drv->name, len))
+ return -ENODEV;
+
+ return 0;
+}
+
+static struct parport_driver baycom_epp_par_driver = {
+ .name = "bce",
+ .probe = baycom_epp_par_probe,
+ .devmodel = true,
+};
+
static void __init baycom_epp_dev_setup(struct net_device *dev)
{
struct baycom_state *bc = netdev_priv(dev);
@@ -1204,10 +1235,15 @@ static void __init baycom_epp_dev_setup(struct
net_device *dev)
static int __init init_baycomepp(void)
{
- int i, found = 0;
+ int i, found = 0, ret;
char set_hw = 1;
printk(bc_drvinfo);
+
+ ret = parport_register_driver(_epp_par_driver);
+ if (ret)
+ return ret;
+
/*
* register net devices
*/
@@ -1241,7 +1277,12 @@ static int __init init_baycomepp(void)
found++;
}
- return found ? 0 : -ENXIO;
+ if (found == 0) {
+ parport_unregister_driver(_epp_par_driver);
+ return -ENXIO;
+ }
+
+ return 0;
}
static void __exit cleanup_baycomepp(void)
@@ -1260,6 +1301,7 @@ static void __exit cleanup_baycomepp(void)
printk(paranoia_str, "cleanup_module");
}
}
+ parport_unregister_driver(_epp_par_driver);
}
module_init(init_baycomepp);
Re: [PATCH] hamradio: baycom: use new parport device model
Acked-By: Thomas Sailer
Am 17.09.2017 um 13:46 schrieb Sudip Mukherjee:
Modify baycom driver to use the new parallel port device model.
Signed-off-by: Sudip Mukherjee
---
Not tested on real hardware, only tested on qemu and verified that the
device is binding to the driver properly in epp_open but then unbinding
as the device was not found.
drivers/net/hamradio/baycom_epp.c | 50 +++
1 file changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/net/hamradio/baycom_epp.c
b/drivers/net/hamradio/baycom_epp.c
index 1503f10..1e62d00 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -840,6 +840,7 @@ static int epp_open(struct net_device *dev)
unsigned char tmp[128];
unsigned char stat;
unsigned long tstart;
+ struct pardev_cb par_cb;
if (!pp) {
printk(KERN_ERR "%s: parport at 0x%lx unknown\n", bc_drvname,
dev->base_addr);
@@ -859,8 +860,21 @@ static int epp_open(struct net_device *dev)
return -EIO;
}
memset(>modem, 0, sizeof(bc->modem));
-bc->pdev = parport_register_device(pp, dev->name, NULL, epp_wakeup,
- NULL, PARPORT_DEV_EXCL, dev);
+ memset(_cb, 0, sizeof(par_cb));
+ par_cb.wakeup = epp_wakeup;
+ par_cb.private = (void *)dev;
+ par_cb.flags = PARPORT_DEV_EXCL;
+ for (i = 0; i < NR_PORTS; i++)
+ if (baycom_device[i] == dev)
+ break;
+
+ if (i == NR_PORTS) {
+ pr_err("%s: no device found\n", bc_drvname);
+ parport_put_port(pp);
+ return -ENODEV;
+ }
+
+ bc->pdev = parport_register_dev_model(pp, dev->name, _cb, i);
parport_put_port(pp);
if (!bc->pdev) {
printk(KERN_ERR "%s: cannot register parport at 0x%lx\n",
bc_drvname, pp->base);
@@ -1185,6 +1199,23 @@ MODULE_LICENSE("GPL");
/* - */
+static int baycom_epp_par_probe(struct pardevice *par_dev)
+{
+ struct device_driver *drv = par_dev->dev.driver;
+ int len = strlen(drv->name);
+
+ if (strncmp(par_dev->name, drv->name, len))
+ return -ENODEV;
+
+ return 0;
+}
+
+static struct parport_driver baycom_epp_par_driver = {
+ .name = "bce",
+ .probe = baycom_epp_par_probe,
+ .devmodel = true,
+};
+
static void __init baycom_epp_dev_setup(struct net_device *dev)
{
struct baycom_state *bc = netdev_priv(dev);
@@ -1204,10 +1235,15 @@ static void __init baycom_epp_dev_setup(struct
net_device *dev)
static int __init init_baycomepp(void)
{
- int i, found = 0;
+ int i, found = 0, ret;
char set_hw = 1;
printk(bc_drvinfo);
+
+ ret = parport_register_driver(_epp_par_driver);
+ if (ret)
+ return ret;
+
/*
* register net devices
*/
@@ -1241,7 +1277,12 @@ static int __init init_baycomepp(void)
found++;
}
- return found ? 0 : -ENXIO;
+ if (found == 0) {
+ parport_unregister_driver(_epp_par_driver);
+ return -ENXIO;
+ }
+
+ return 0;
}
static void __exit cleanup_baycomepp(void)
@@ -1260,6 +1301,7 @@ static void __exit cleanup_baycomepp(void)
printk(paranoia_str, "cleanup_module");
}
}
+ parport_unregister_driver(_epp_par_driver);
}
module_init(init_baycomepp);
Re: [PATCH] net: hamradio: baycom_ser_fdx: Replace timeval with timespec64
Reviewed-by: Thomas Sailer Thanks!
Re: [PATCH] net: hamradio: baycom_ser_fdx: Replace timeval with timespec64
Reviewed-by: Thomas Sailer <t.sai...@alumni.ethz.ch> Thanks!
Re: [PATCH v3 08/18] baycom_epp: Replace rdtscl() with native_read_tsc()
Acked-by: Thomas Sailer
On 06/17/2015 02:35 AM, Andy Lutomirski wrote:
This is only used if BAYCOM_DEBUG is defined.
Cc: walter harms
Cc: Ralf Baechle
Cc: Thomas Sailer
Cc: linux-h...@vger.kernel.org
Signed-off-by: Andy Lutomirski
---
I'm hoping for an ack for this to go through -tip.
drivers/net/hamradio/baycom_epp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/baycom_epp.c
b/drivers/net/hamradio/baycom_epp.c
index 83c7cce0d172..44e5c3b5e0af 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -638,7 +638,7 @@ static int receive(struct net_device *dev, int cnt)
#define GETTICK(x)\
({\
if (cpu_has_tsc) \
- rdtscl(x);\
+ x = (unsigned int)native_read_tsc(); \
})
#else /* __i386__ */
#define GETTICK(x)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 08/18] baycom_epp: Replace rdtscl() with native_read_tsc()
Acked-by: Thomas Sailer t.sai...@alumni.ethz.ch
On 06/17/2015 02:35 AM, Andy Lutomirski wrote:
This is only used if BAYCOM_DEBUG is defined.
Cc: walter harms wha...@bfs.de
Cc: Ralf Baechle r...@linux-mips.org
Cc: Thomas Sailer t.sai...@alumni.ethz.ch
Cc: linux-h...@vger.kernel.org
Signed-off-by: Andy Lutomirski l...@kernel.org
---
I'm hoping for an ack for this to go through -tip.
drivers/net/hamradio/baycom_epp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/baycom_epp.c
b/drivers/net/hamradio/baycom_epp.c
index 83c7cce0d172..44e5c3b5e0af 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -638,7 +638,7 @@ static int receive(struct net_device *dev, int cnt)
#define GETTICK(x)\
({\
if (cpu_has_tsc) \
- rdtscl(x);\
+ x = (unsigned int)native_read_tsc(); \
})
#else /* __i386__ */
#define GETTICK(x)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Patch for WindowsMobile5 on Linux Kernel
On Tue, 2007-10-09 at 11:37 +0200, Xavier Bestel wrote: > FWIW, the patch in question is a one-liner: That's not a valid argument. This may work with a WM5 device, but looks very dubious, wrt. other RNDIS devices. Why are these constants hardcoded and not taken in some way from the descriptors? There must be some justification why these values need to be hardcoded, and if so, this must be dependent on the rndis device really being a WM5 device. Nacked-By: Thomas Sailer <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch for WindowsMobile5 on Linux Kernel
On Tue, 2007-10-09 at 11:37 +0200, Xavier Bestel wrote: FWIW, the patch in question is a one-liner: That's not a valid argument. This may work with a WM5 device, but looks very dubious, wrt. other RNDIS devices. Why are these constants hardcoded and not taken in some way from the descriptors? There must be some justification why these values need to be hardcoded, and if so, this must be dependent on the rndis device really being a WM5 device. Nacked-By: Thomas Sailer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [369/2many] MAINTAINERS - PCI SOUND DRIVERS (ES1370, ES1371 and SONICVIBES)
On Sun, 2007-08-12 at 23:33 -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> Acked-By: Thomas Sailer <[EMAIL PROTECTED]> NB: I thought these old non-alsa drivers were going to be removed "soon"... Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [90/2many] MAINTAINERS - BAYCOM/HDLCDRV DRIVERS FOR AX.25
On Sun, 2007-08-12 at 23:24 -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> Acked-By: Thomas Sailer <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [90/2many] MAINTAINERS - BAYCOM/HDLCDRV DRIVERS FOR AX.25
On Sun, 2007-08-12 at 23:24 -0700, [EMAIL PROTECTED] wrote: Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] Acked-By: Thomas Sailer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [369/2many] MAINTAINERS - PCI SOUND DRIVERS (ES1370, ES1371 and SONICVIBES)
On Sun, 2007-08-12 at 23:33 -0700, [EMAIL PROTECTED] wrote: Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] Acked-By: Thomas Sailer [EMAIL PROTECTED] NB: I thought these old non-alsa drivers were going to be removed soon... Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel + gcc 4.1 = several problems
On Wed, 2007-01-03 at 08:03 -0800, Linus Torvalds wrote: > and assuming the branch is AT ALL predictable (and 95+% of all branches > are), the branch-over will actually be a LOT better for a CPU. IF... Counterexample: Add-Compare-Select in a Viterbi Decoder. If the compare can be predicted, you botched the compression of the data (if you can predict the data, you could have compressed it better), or your noise is not white, i.e. you f*** up the whitening filter. So in any practical viterbi decoder, the compares cannot be predicted. I remember cmov made a big difference in Viterbi Decoder performance on a Cyrix 6x86. But granted, nowadays these things are usually done with SIMD and masks. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel + gcc 4.1 = several problems
On Wed, 2007-01-03 at 08:03 -0800, Linus Torvalds wrote: and assuming the branch is AT ALL predictable (and 95+% of all branches are), the branch-over will actually be a LOT better for a CPU. IF... Counterexample: Add-Compare-Select in a Viterbi Decoder. If the compare can be predicted, you botched the compression of the data (if you can predict the data, you could have compressed it better), or your noise is not white, i.e. you f*** up the whitening filter. So in any practical viterbi decoder, the compares cannot be predicted. I remember cmov made a big difference in Viterbi Decoder performance on a Cyrix 6x86. But granted, nowadays these things are usually done with SIMD and masks. Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OSS driver removal, 3nd round
On Tue, 2006-12-19 at 05:11 +0100, Adrian Bunk wrote: > 1. ALSA drivers for the same hardware > > SOUND_ES1371 Acked-By: Thomas Sailer <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OSS driver removal, 3nd round
On Tue, 2006-12-19 at 05:11 +0100, Adrian Bunk wrote: 1. ALSA drivers for the same hardware SOUND_ES1371 Acked-By: Thomas Sailer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Nokia E61 and the kernel BUG at mm/slab.c:594
On Tue, 2006-12-12 at 12:16 +0100, Oliver Neukum wrote: > What functions does this mode involve? Here are the descriptors: PC-Suite Mode: Bus 001 Device 005: ID 0421:0418 Nokia Mobile Phones Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0421 Nokia Mobile Phones idProduct 0x0418 bcdDevice1.00 iManufacturer 1 Nokia iProduct2 Nokia E70 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 466 bNumInterfaces 16 bConfigurationValue 1 iConfiguration 4 Bulk transfer method configuration bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass 8 Wireless Handset Control bInterfaceProtocol 0 iInterface 0 CDC Header: bcdCDC 1.10 UNRECOGNIZED: 05 24 11 00 01 CDC Union: bMasterInterface0 bSlaveInterface 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass 8 Wireless Handset Control bInterfaceProtocol 1 iInterface 0 CDC Header: bcdCDC 1.10 UNRECOGNIZED: 05 24 08 00 01 CDC Union: bMasterInterface1 bSlaveInterface 2 3 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass254 bInterfaceProtocol 0 iInterface 0 CDC Header: bcdCDC 1.10 UNRECOGNIZED: 05 24 ab 05 15 CDC Union: bMasterInterface2 bSlaveInterface 3 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber4 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass 11 OBEX bInterfaceProtocol 0 iInterface 5 SYNCML-SYNC CDC Header: bcdCDC 1.10 UNRECOGNIZED: 05 24 15 00 01 CDC Union: bMasterInterface4 bSlaveInterface 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber5 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber5
Re: Nokia E61 and the kernel BUG at mm/slab.c:594
On Tue, 2006-12-12 at 11:44 +0200, Muli Ben-Yehuda wrote: > I assume the previous crash was 2.6.19 with SMP? did it work with > earlier kernels? It happens to me as well, current Fedora 6 update kernel-2.6.18-1.2849.fc6.i686 UP, with a Nokia E70 in "PC Suite" mode. It works ok in mass storage mode. Haven't had time to debug this, though... Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Nokia E61 and the kernel BUG at mm/slab.c:594
On Tue, 2006-12-12 at 11:44 +0200, Muli Ben-Yehuda wrote: I assume the previous crash was 2.6.19 with SMP? did it work with earlier kernels? It happens to me as well, current Fedora 6 update kernel-2.6.18-1.2849.fc6.i686 UP, with a Nokia E70 in PC Suite mode. It works ok in mass storage mode. Haven't had time to debug this, though... Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Nokia E61 and the kernel BUG at mm/slab.c:594
On Tue, 2006-12-12 at 12:16 +0100, Oliver Neukum wrote: What functions does this mode involve? Here are the descriptors: PC-Suite Mode: Bus 001 Device 005: ID 0421:0418 Nokia Mobile Phones Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0421 Nokia Mobile Phones idProduct 0x0418 bcdDevice1.00 iManufacturer 1 Nokia iProduct2 Nokia E70 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 466 bNumInterfaces 16 bConfigurationValue 1 iConfiguration 4 Bulk transfer method configuration bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass 8 Wireless Handset Control bInterfaceProtocol 0 iInterface 0 CDC Header: bcdCDC 1.10 UNRECOGNIZED: 05 24 11 00 01 CDC Union: bMasterInterface0 bSlaveInterface 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass 8 Wireless Handset Control bInterfaceProtocol 1 iInterface 0 CDC Header: bcdCDC 1.10 UNRECOGNIZED: 05 24 08 00 01 CDC Union: bMasterInterface1 bSlaveInterface 2 3 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass254 bInterfaceProtocol 0 iInterface 0 CDC Header: bcdCDC 1.10 UNRECOGNIZED: 05 24 ab 05 15 CDC Union: bMasterInterface2 bSlaveInterface 3 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber4 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass 11 OBEX bInterfaceProtocol 0 iInterface 5 SYNCML-SYNC CDC Header: bcdCDC 1.10 UNRECOGNIZED: 05 24 15 00 01 CDC Union: bMasterInterface4 bSlaveInterface 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber5 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber5
Re: [2.6 patch] schedule obsolete OSS drivers for removal
On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote: > This patch schedules obsolete OSS drivers (with ALSA drivers that > support the same hardware) for removal. > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Acked-by: Thomas Sailer <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] schedule obsolete OSS drivers for removal
On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote: This patch schedules obsolete OSS drivers (with ALSA drivers that support the same hardware) for removal. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Acked-by: Thomas Sailer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Synaptics probe problem on Acer Travelmate 3004WTMi
On Wed, 2005-07-13 at 20:38 +0200, Vojtech Pavlik wrote:
> Also try the usual options ("i8042.nomux=1" and "usb-handoff"). One or
> both may make the problem disappear.
usb-handoff did it, thanks a lot!
Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Synaptics probe problem on Acer Travelmate 3004WTMi
On Wed, 2005-07-13 at 20:38 +0200, Vojtech Pavlik wrote: Also try the usual options (i8042.nomux=1 and usb-handoff). One or both may make the problem disappear. usb-handoff did it, thanks a lot! Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Synaptics probe problem on Acer Travelmate 3004WTMi
Hi Vojtech,
I've got a problem with my Acer Travelmate 3004WTMi Laptop: vanilla 2.6
does not detect the synaptics touchpad.
The problem lies within psmouse_probe: after the PSMOUSE_CMD_GETID
command, param[0] contains 0xfa, and not one of the expected values. If
I just ignore this and continue, the synaptics pad is detected and
everything works ok.
Tom
static int psmouse_probe(struct psmouse *psmouse)
642 {
643 struct ps2dev *ps2dev = >ps2dev;
644 unsigned char param[2];
645
646 /*
647 * First, we check if it's a mouse. It should send 0x00 or 0x03
648 * in case of an IntelliMouse in 4-byte mode or 0x04 for IM
Explorer.
649 * Sunrex K8561 IR Keyboard/Mouse reports 0xff on second and
subsequent
650 * ID queries, probably due to a firmware bug.
651 */
652
653 param[0] = 0xa5;
654 if (ps2_command(ps2dev, param, PSMOUSE_CMD_GETID))
655 return -1;
656
657 if (param[0] != 0x00 && param[0] != 0x03 &&
658 param[0] != 0x04 && param[0] != 0xff)
659 return -1;
660
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Synaptics probe problem on Acer Travelmate 3004WTMi
Hi Vojtech,
I've got a problem with my Acer Travelmate 3004WTMi Laptop: vanilla 2.6
does not detect the synaptics touchpad.
The problem lies within psmouse_probe: after the PSMOUSE_CMD_GETID
command, param[0] contains 0xfa, and not one of the expected values. If
I just ignore this and continue, the synaptics pad is detected and
everything works ok.
Tom
static int psmouse_probe(struct psmouse *psmouse)
642 {
643 struct ps2dev *ps2dev = psmouse-ps2dev;
644 unsigned char param[2];
645
646 /*
647 * First, we check if it's a mouse. It should send 0x00 or 0x03
648 * in case of an IntelliMouse in 4-byte mode or 0x04 for IM
Explorer.
649 * Sunrex K8561 IR Keyboard/Mouse reports 0xff on second and
subsequent
650 * ID queries, probably due to a firmware bug.
651 */
652
653 param[0] = 0xa5;
654 if (ps2_command(ps2dev, param, PSMOUSE_CMD_GETID))
655 return -1;
656
657 if (param[0] != 0x00 param[0] != 0x03
658 param[0] != 0x04 param[0] != 0xff)
659 return -1;
660
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESUBMIT] [PATCH] [BUGFIX] sound/oss/es1371.c: Don't print joystick address before it's set.
On Thu, 2005-03-03 at 16:48 +0100, Bodo Eggert wrote: > Signed-off-by: Bodo Eggert <[EMAIL PROTECTED]> Acked-By: Thomas Sailer <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESUBMIT] [PATCH] [BUGFIX] sound/oss/es1371.c: Don't print joystick address before it's set.
On Thu, 2005-03-03 at 16:48 +0100, Bodo Eggert wrote: Signed-off-by: Bodo Eggert [EMAIL PROTECTED] Acked-By: Thomas Sailer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac9
Christoph Hellwig schrieb: > > In article <[EMAIL PROTECTED]> you wrote: > > 2.4.5-ac9 > > > o Add es1371 sound driver locking (Frank Davis) > > It's buggy. The locking in ->read and ->write will give > double ups when a signal is pending and remove a not added waitq > when programming the dmabuf fails. But Alan added a different patch than yours, that doesn't seem to have poll in the guard. Also, both your and Frank Davis' patch don't care about dac, which seems bogus to me. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac9
Alan Cox schrieb: > 2.4.5-ac9 > o Add es1371 sound driver locking (Frank Davis) Looks bogus. Independent processes can open the same device once for reading and once for writing, now you are serializing needlessly these processes. Please revert. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USBDEVFS_URB_TYPE_INTERRUPT
John Chris Wren schrieb: > I don't really want to write a full-up kernel mode driver for this device, > but interrupt type messages are the preferred method for communicating, > since once a message needs to be sent, it should be timely (whereas control > messages could be delayed a significant amount on a busy USB channel). If you critically depend on tight timing you'll need a kernel driver anyway, as your usermode task might be delayed on a busy machine too. Otherwise you can use bulk ins timed from userspace Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USBDEVFS_URB_TYPE_INTERRUPT
John Chris Wren schrieb: I don't really want to write a full-up kernel mode driver for this device, but interrupt type messages are the preferred method for communicating, since once a message needs to be sent, it should be timely (whereas control messages could be delayed a significant amount on a busy USB channel). If you critically depend on tight timing you'll need a kernel driver anyway, as your usermode task might be delayed on a busy machine too. Otherwise you can use bulk ins timed from userspace Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac9
Alan Cox schrieb: 2.4.5-ac9 o Add es1371 sound driver locking (Frank Davis) Looks bogus. Independent processes can open the same device once for reading and once for writing, now you are serializing needlessly these processes. Please revert. Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac9
Christoph Hellwig schrieb: In article [EMAIL PROTECTED] you wrote: 2.4.5-ac9 o Add es1371 sound driver locking (Frank Davis) It's buggy. The locking in -read and -write will give double ups when a signal is pending and remove a not added waitq when programming the dmabuf fails. But Alan added a different patch than yours, that doesn't seem to have poll in the guard. Also, both your and Frank Davis' patch don't care about dac, which seems bogus to me. Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
"H. Peter Anvin" schrieb: > How about for other device classes? Cheap USB devices (and sometimes even expensive ones) do not have serial numbers or other unique identifiers. Therefore some sort of topology based addressing scheme has to be used in that case. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
H. Peter Anvin schrieb: How about for other device classes? Cheap USB devices (and sometimes even expensive ones) do not have serial numbers or other unique identifiers. Therefore some sort of topology based addressing scheme has to be used in that case. Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: init_rwsem redefinition warning in usbdevice_fs.h
Alex Riesen wrote: > Should it be fixed? And, maybe the other define's around > should be fixed too? The comment line above actually says it all. The defines have been added because at the time of writing this file rw semaphores did not work in a module, so they were replaced with mutexes using these defines. If rw sems work now just delete these defines Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: init_rwsem redefinition warning in usbdevice_fs.h
Alex Riesen wrote: Should it be fixed? And, maybe the other define's around should be fixed too? The comment line above actually says it all. The defines have been added because at the time of writing this file rw semaphores did not work in a module, so they were replaced with mutexes using these defines. If rw sems work now just delete these defines Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usb audio
Landsberger Brian J wrote: > > Has anyone been able to get the Apple Pro (the round clear) speakers to > work in Linux? I've read the howto's and followed the various steps to > no avail. The various usb modules print the following to syslog: This looks ok. So what is wrong? Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usb audio
Landsberger Brian J wrote: Has anyone been able to get the Apple Pro (the round clear) speakers to work in Linux? I've read the howto's and followed the various steps to no avail. The various usb modules print the following to syslog: This looks ok. So what is wrong? Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19/2.4.0-test and usbdevfs
> modprobe: modprobe: Can't locate module usbdevfs > mount: fs type usbdevfs not supported by kernel Add: alias usbdevfs usbcore to /etc/modules.conf Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19/2.4.0-test and usbdevfs
modprobe: modprobe: Can't locate module usbdevfs mount: fs type usbdevfs not supported by kernel Add: alias usbdevfs usbcore to /etc/modules.conf Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i810_audio 2.4.0-test11
Alan Cox wrote: > What format is it that causes the problems, the only badly supported key format > right know I know of is 16bit bigendian. That needs some small esd patches. S8 is a not very well supported format. And btw there are many applications that cannot live with esd for latency reasons. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i810_audio 2.4.0-test11
Alan Cox wrote: > Definitely we should If you start killing format conversion then >99% of the existing applications won't work anymore with usbaudio. At that point you can dump the OSS interface just as well. And before killing format conversion you should kill the mmap stunt, because the format conversion complexity (~25 LOC) is by far dwarfed by the mmap emulation stuff. The underlying question is: - do we want an usb audio driver that supports the OSS interface and with which most existing applications work - or do we want a simple driver with its own non-OSS interface. Anything in between is IMO silly. Killing the format conversion drops the advantage of running many existing applications but don't bring you much closer to the goal of simplicity. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i810_audio 2.4.0-test11
Alan Cox wrote: Definitely we should If you start killing format conversion then 99% of the existing applications won't work anymore with usbaudio. At that point you can dump the OSS interface just as well. And before killing format conversion you should kill the mmap stunt, because the format conversion complexity (~25 LOC) is by far dwarfed by the mmap emulation stuff. The underlying question is: - do we want an usb audio driver that supports the OSS interface and with which most existing applications work - or do we want a simple driver with its own non-OSS interface. Anything in between is IMO silly. Killing the format conversion drops the advantage of running many existing applications but don't bring you much closer to the goal of simplicity. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i810_audio 2.4.0-test11
Alan Cox wrote: What format is it that causes the problems, the only badly supported key format right know I know of is 16bit bigendian. That needs some small esd patches. S8 is a not very well supported format. And btw there are many applications that cannot live with esd for latency reasons. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: 2.4.0-testx: ac97_codec
In the current ac97_codec, computation of attenuation values may overflow
the register width, thus resulting in maximum volume when minimum was requested.
This patch adds overflow checks and limitations.
Tom
--- ac97_codec.c.orig Thu Nov 23 13:13:13 2000
+++ ac97_codec.cThu Nov 23 13:20:01 2000
@@ -284,6 +284,10 @@
if (oss_channel == SOUND_MIXER_IGAIN) {
right = (right * mh->scale) / 100;
left = (left * mh->scale) / 100;
+ if (right >= mh->scale)
+ right = mh->scale-1;
+ if (left >= mh->scale)
+ left = mh->scale-1;
} else {
/* these may have 5 or 6 bit resolution */
if (oss_channel == SOUND_MIXER_VOLUME ||
@@ -294,27 +298,49 @@
right = ((100 - right) * scale) / 100;
left = ((100 - left) * scale) / 100;
- }
+ if (right >= scale)
+ right = scale-1;
+ if (left >= scale)
+ left = scale-1;
+ }
val = (left << 8) | right;
}
} else if (oss_channel == SOUND_MIXER_BASS) {
val = codec->codec_read(codec , mh->offset) & ~0x0f00;
- val |= 100 - left) * mh->scale) / 100) << 8) & 0x0e00;
+ left = ((100 - left) * mh->scale) / 100;
+ if (left >= mh->scale)
+ left = mh->scale-1;
+ val |= (left << 8) & 0x0e00;
} else if (oss_channel == SOUND_MIXER_TREBLE) {
val = codec->codec_read(codec , mh->offset) & ~0x000f;
- val |= (((100 - left) * mh->scale) / 100) & 0x000e;
+ left = ((100 - left) * mh->scale) / 100;
+ if (left >= mh->scale)
+ left = mh->scale-1;
+ val |= left & 0x000e;
} else if(left == 0) {
val = AC97_MUTE;
} else if (oss_channel == SOUND_MIXER_SPEAKER) {
- val = (((100 - left) * mh->scale) / 100) << 1;
+ left = ((100 - left) * mh->scale) / 100;
+ if (left >= mh->scale)
+ left = mh->scale-1;
+ val = left << 1;
} else if (oss_channel == SOUND_MIXER_PHONEIN) {
- val = (((100 - left) * mh->scale) / 100);
+ left = ((100 - left) * mh->scale) / 100;
+ if (left >= mh->scale)
+ left = mh->scale-1;
+ val = left;
} else if (oss_channel == SOUND_MIXER_PHONEOUT) {
scale = (1 << codec->bit_resolution);
- val = (((100 - left) * scale) / 100);
+ left = ((100 - left) * scale) / 100;
+ if (left >= mh->scale)
+ left = mh->scale-1;
+ val = left;
} else if (oss_channel == SOUND_MIXER_MIC) {
val = codec->codec_read(codec , mh->offset) & ~0x801f;
- val |= (((100 - left) * mh->scale) / 100);
+ left = ((100 - left) * mh->scale) / 100;
+ if (left >= mh->scale)
+ left = mh->scale-1;
+ val |= left;
/* the low bit is optional in the tone sliders and masking
it lets us avoid the 0xf 'bypass'.. */
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: 2.4.0-testx: USB Audio
This patch adds a workaround for the Dallas chip; the chip tags
its 8bit formats with PCM8 but expects signed data.
Also, the driver is less verbose; I forward ported Alan Cox's changes
in 2.2.18pre
Tom
--- drivers/usb/audio.c.origFri Oct 13 21:13:29 2000
+++ drivers/usb/audio.c Mon Nov 27 18:32:32 2000
@@ -89,6 +89,9 @@
* Somewhat peculiar due to OSS interface limitations. Only works
* for channels where a "slider" is already in front of it (i.e.
* a MIXER unit or a FEATURE unit with volume capability).
+ * 2000-11-26: Thomas Sailer
+ * Workaround for Dallas DS4201. The DS4201 uses PCM8 as format tag for
+ * its 8 bit modes, but expects signed data (and should therefore have
+used PCM).
*
*/
@@ -191,6 +194,7 @@
#define SND_DEV_DSP16 5
+#define dprintk(x)
/* - */
@@ -472,10 +476,10 @@
}
db->bufsize = nr << PAGE_SHIFT;
db->ready = 1;
- printk(KERN_DEBUG "dmabuf_init: bytepersec %d bufs %d ossfragshift %d
ossmaxfrags %d "
- "fragshift %d fragsize %d numfrag %d dmasize %d bufsize %d fmt 0x%x\n",
- bytepersec, bufs, db->ossfragshift, db->ossmaxfrags, db->fragshift,
db->fragsize,
- db->numfrag, db->dmasize, db->bufsize, db->format);
+ dprintk((KERN_DEBUG "dmabuf_init: bytepersec %d bufs %d ossfragshift %d
+ossmaxfrags %d "
+"fragshift %d fragsize %d numfrag %d dmasize %d bufsize %d fmt
+0x%x\n",
+bytepersec, bufs, db->ossfragshift, db->ossmaxfrags, db->fragshift,
+db->fragsize,
+db->numfrag, db->dmasize, db->bufsize, db->format));
return 0;
}
@@ -829,7 +833,7 @@
for (i = 0; i < DESCFRAMES; i++) {
cp = ((unsigned char *)urb->transfer_buffer) +
urb->iso_frame_desc[i].offset;
if (urb->iso_frame_desc[i].status) {
- printk(KERN_DEBUG "usbin_retire_desc: frame %u status %d\n",
i, urb->iso_frame_desc[i].status);
+ dprintk((KERN_DEBUG "usbin_retire_desc: frame %u status %d\n",
+i, urb->iso_frame_desc[i].status));
continue;
}
scnt = urb->iso_frame_desc[i].actual_length >> ufmtsh;
@@ -921,7 +925,7 @@
for (i = 0; i < SYNCFRAMES; i++)
if (urb->iso_frame_desc[0].status)
- printk(KERN_DEBUG "usbin_sync_retire_desc: frame %u status
%d\n", i, urb->iso_frame_desc[i].status);
+ dprintk((KERN_DEBUG "usbin_sync_retire_desc: frame %u status
+%d\n", i, urb->iso_frame_desc[i].status));
return 0;
}
@@ -954,7 +958,7 @@
} else {
u->flags &= ~(mask | FLG_RUNNING);
wake_up(>dma.wait);
- printk(KERN_DEBUG "usbin_sync_completed: descriptor not restarted
(usb_submit_urb: %d)\n", suret);
+ dprintk((KERN_DEBUG "usbin_sync_completed: descriptor not restarted
+(usb_submit_urb: %d)\n", suret));
}
spin_unlock_irqrestore(>lock, flags);
}
@@ -1211,7 +1215,7 @@
for (i = 0; i < DESCFRAMES; i++) {
if (urb->iso_frame_desc[i].status) {
- printk(KERN_DEBUG "usbout_retire_desc: frame %u status %d\n",
i, urb->iso_frame_desc[i].status);
+ dprintk((KERN_DEBUG "usbout_retire_desc: frame %u status
+%d\n", i, urb->iso_frame_desc[i].status));
continue;
}
}
@@ -1247,7 +1251,7 @@
} else {
u->flags &= ~(mask | FLG_RUNNING);
wake_up(>dma.wait);
- printk(KERN_DEBUG "usbout_completed: descriptor not restarted
(usb_submit_urb: %d)\n", suret);
+ dprintk((KERN_DEBUG "usbout_completed: descriptor not restarted
+(usb_submit_urb: %d)\n", suret));
}
spin_unlock_irqrestore(>lock, flags);
}
@@ -1273,11 +1277,11 @@
for (i = 0; i < SYNCFRAMES; i++, cp += 3) {
if (urb->iso_frame_desc[i].status) {
- printk(KERN_DEBUG "usbout_sync_retire_desc: frame %u status
%d\n", i, urb->iso_frame_desc[i].status);
+ dprintk((KERN_DEBUG "usbout_sync_retire_desc: frame %u status
+%d\n", i, urb->iso_frame_desc[i].status));
continue;
}
if (urb->iso_frame_desc[i].actual_length < 3) {
- printk(KERN_DEBUG "usbout_sync_retire_desc: frame %u length
%d\n", i, urb->iso_frame_desc[i].actual_length
[PATCH]: USB Audio 2.2.18pre
This patch adds a workaround for the Dallas chip; the chip tags
its 8bit formats with PCM8 but expects signed data.
--- drivers/usb/audio.c.origMon Oct 2 15:23:28 2000
+++ drivers/usb/audio.c Mon Nov 27 00:08:54 2000
@@ -89,6 +89,9 @@
* Somewhat peculiar due to OSS interface limitations. Only works
* for channels where a "slider" is already in front of it (i.e.
* a MIXER unit or a FEATURE unit with volume capability).
+ * 2000-11-26: Thomas Sailer
+ * Workaround for Dallas DS4201. The DS4201 uses PCM8 as format tag for
+ * its 8 bit modes, but expects signed data (and should therefore have
+used PCM).
*
*/
@@ -1551,6 +1554,7 @@
dev->devnum, u->interface, fmt->altsetting, d->srate, data[0] |
(data[1] << 8) | (data[2] << 16)));
d->srate = data[0] | (data[1] << 8) | (data[2] << 16);
}
+ dprintk((KERN_DEBUG "usbaudio: set_format_in: USB format 0x%x, DMA format 0x%x
+srate %u\n", u->format, d->format, d->srate));
return 0;
}
@@ -1647,6 +1651,7 @@
dev->devnum, u->interface, fmt->altsetting, d->srate, data[0] |
(data[1] << 8) | (data[2] << 16)));
d->srate = data[0] | (data[1] << 8) | (data[2] << 16);
}
+ dprintk((KERN_DEBUG "usbaudio: set_format_out: USB format 0x%x, DMA format
+0x%x srate %u\n", u->format, d->format, d->srate));
return 0;
}
@@ -2851,6 +2856,9 @@
continue;
}
format = (fmt[5] == 2) ? (AFMT_U16_LE | AFMT_U8) :
(AFMT_S16_LE | AFMT_S8);
+ /* Dallas DS4201 workaround */
+ if (dev->descriptor.idVendor == 0x04fa &&
+dev->descriptor.idProduct == 0x4201)
+ format = (AFMT_S16_LE | AFMT_S8);
fmt = find_csinterface_descriptor(buffer, buflen, NULL,
FORMAT_TYPE, asifout, i);
if (!fmt) {
printk(KERN_ERR "usbaudio: device %u interface %u
altsetting %u FORMAT_TYPE descriptor not found\n",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: USB Audio 2.2.18pre
This patch adds a workaround for the Dallas chip; the chip tags
its 8bit formats with PCM8 but expects signed data.
--- drivers/usb/audio.c.origMon Oct 2 15:23:28 2000
+++ drivers/usb/audio.c Mon Nov 27 00:08:54 2000
@@ -89,6 +89,9 @@
* Somewhat peculiar due to OSS interface limitations. Only works
* for channels where a "slider" is already in front of it (i.e.
* a MIXER unit or a FEATURE unit with volume capability).
+ * 2000-11-26: Thomas Sailer
+ * Workaround for Dallas DS4201. The DS4201 uses PCM8 as format tag for
+ * its 8 bit modes, but expects signed data (and should therefore have
+used PCM).
*
*/
@@ -1551,6 +1554,7 @@
dev-devnum, u-interface, fmt-altsetting, d-srate, data[0] |
(data[1] 8) | (data[2] 16)));
d-srate = data[0] | (data[1] 8) | (data[2] 16);
}
+ dprintk((KERN_DEBUG "usbaudio: set_format_in: USB format 0x%x, DMA format 0x%x
+srate %u\n", u-format, d-format, d-srate));
return 0;
}
@@ -1647,6 +1651,7 @@
dev-devnum, u-interface, fmt-altsetting, d-srate, data[0] |
(data[1] 8) | (data[2] 16)));
d-srate = data[0] | (data[1] 8) | (data[2] 16);
}
+ dprintk((KERN_DEBUG "usbaudio: set_format_out: USB format 0x%x, DMA format
+0x%x srate %u\n", u-format, d-format, d-srate));
return 0;
}
@@ -2851,6 +2856,9 @@
continue;
}
format = (fmt[5] == 2) ? (AFMT_U16_LE | AFMT_U8) :
(AFMT_S16_LE | AFMT_S8);
+ /* Dallas DS4201 workaround */
+ if (dev-descriptor.idVendor == 0x04fa
+dev-descriptor.idProduct == 0x4201)
+ format = (AFMT_S16_LE | AFMT_S8);
fmt = find_csinterface_descriptor(buffer, buflen, NULL,
FORMAT_TYPE, asifout, i);
if (!fmt) {
printk(KERN_ERR "usbaudio: device %u interface %u
altsetting %u FORMAT_TYPE descriptor not found\n",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: 2.4.0-testx: USB Audio
This patch adds a workaround for the Dallas chip; the chip tags
its 8bit formats with PCM8 but expects signed data.
Also, the driver is less verbose; I forward ported Alan Cox's changes
in 2.2.18pre
Tom
--- drivers/usb/audio.c.origFri Oct 13 21:13:29 2000
+++ drivers/usb/audio.c Mon Nov 27 18:32:32 2000
@@ -89,6 +89,9 @@
* Somewhat peculiar due to OSS interface limitations. Only works
* for channels where a "slider" is already in front of it (i.e.
* a MIXER unit or a FEATURE unit with volume capability).
+ * 2000-11-26: Thomas Sailer
+ * Workaround for Dallas DS4201. The DS4201 uses PCM8 as format tag for
+ * its 8 bit modes, but expects signed data (and should therefore have
+used PCM).
*
*/
@@ -191,6 +194,7 @@
#define SND_DEV_DSP16 5
+#define dprintk(x)
/* - */
@@ -472,10 +476,10 @@
}
db-bufsize = nr PAGE_SHIFT;
db-ready = 1;
- printk(KERN_DEBUG "dmabuf_init: bytepersec %d bufs %d ossfragshift %d
ossmaxfrags %d "
- "fragshift %d fragsize %d numfrag %d dmasize %d bufsize %d fmt 0x%x\n",
- bytepersec, bufs, db-ossfragshift, db-ossmaxfrags, db-fragshift,
db-fragsize,
- db-numfrag, db-dmasize, db-bufsize, db-format);
+ dprintk((KERN_DEBUG "dmabuf_init: bytepersec %d bufs %d ossfragshift %d
+ossmaxfrags %d "
+"fragshift %d fragsize %d numfrag %d dmasize %d bufsize %d fmt
+0x%x\n",
+bytepersec, bufs, db-ossfragshift, db-ossmaxfrags, db-fragshift,
+db-fragsize,
+db-numfrag, db-dmasize, db-bufsize, db-format));
return 0;
}
@@ -829,7 +833,7 @@
for (i = 0; i DESCFRAMES; i++) {
cp = ((unsigned char *)urb-transfer_buffer) +
urb-iso_frame_desc[i].offset;
if (urb-iso_frame_desc[i].status) {
- printk(KERN_DEBUG "usbin_retire_desc: frame %u status %d\n",
i, urb-iso_frame_desc[i].status);
+ dprintk((KERN_DEBUG "usbin_retire_desc: frame %u status %d\n",
+i, urb-iso_frame_desc[i].status));
continue;
}
scnt = urb-iso_frame_desc[i].actual_length ufmtsh;
@@ -921,7 +925,7 @@
for (i = 0; i SYNCFRAMES; i++)
if (urb-iso_frame_desc[0].status)
- printk(KERN_DEBUG "usbin_sync_retire_desc: frame %u status
%d\n", i, urb-iso_frame_desc[i].status);
+ dprintk((KERN_DEBUG "usbin_sync_retire_desc: frame %u status
+%d\n", i, urb-iso_frame_desc[i].status));
return 0;
}
@@ -954,7 +958,7 @@
} else {
u-flags = ~(mask | FLG_RUNNING);
wake_up(u-dma.wait);
- printk(KERN_DEBUG "usbin_sync_completed: descriptor not restarted
(usb_submit_urb: %d)\n", suret);
+ dprintk((KERN_DEBUG "usbin_sync_completed: descriptor not restarted
+(usb_submit_urb: %d)\n", suret));
}
spin_unlock_irqrestore(as-lock, flags);
}
@@ -1211,7 +1215,7 @@
for (i = 0; i DESCFRAMES; i++) {
if (urb-iso_frame_desc[i].status) {
- printk(KERN_DEBUG "usbout_retire_desc: frame %u status %d\n",
i, urb-iso_frame_desc[i].status);
+ dprintk((KERN_DEBUG "usbout_retire_desc: frame %u status
+%d\n", i, urb-iso_frame_desc[i].status));
continue;
}
}
@@ -1247,7 +1251,7 @@
} else {
u-flags = ~(mask | FLG_RUNNING);
wake_up(u-dma.wait);
- printk(KERN_DEBUG "usbout_completed: descriptor not restarted
(usb_submit_urb: %d)\n", suret);
+ dprintk((KERN_DEBUG "usbout_completed: descriptor not restarted
+(usb_submit_urb: %d)\n", suret));
}
spin_unlock_irqrestore(as-lock, flags);
}
@@ -1273,11 +1277,11 @@
for (i = 0; i SYNCFRAMES; i++, cp += 3) {
if (urb-iso_frame_desc[i].status) {
- printk(KERN_DEBUG "usbout_sync_retire_desc: frame %u status
%d\n", i, urb-iso_frame_desc[i].status);
+ dprintk((KERN_DEBUG "usbout_sync_retire_desc: frame %u status
+%d\n", i, urb-iso_frame_desc[i].status));
continue;
}
if (urb-iso_frame_desc[i].actual_length 3) {
- printk(KERN_DEBUG "usbout_sync_retire_desc: frame %u length
%d\n", i, urb-iso_frame_desc[i].actual_length);
+ dprintk((KERN_DEBUG "usbout_sync_retire_desc: frame %u length
+%d\n", i, urb-iso_frame_desc[i].actual_length));
continue;
}
[PATCH]: 2.4.0-testx: ac97_codec
In the current ac97_codec, computation of attenuation values may overflow
the register width, thus resulting in maximum volume when minimum was requested.
This patch adds overflow checks and limitations.
Tom
--- ac97_codec.c.orig Thu Nov 23 13:13:13 2000
+++ ac97_codec.cThu Nov 23 13:20:01 2000
@@ -284,6 +284,10 @@
if (oss_channel == SOUND_MIXER_IGAIN) {
right = (right * mh-scale) / 100;
left = (left * mh-scale) / 100;
+ if (right = mh-scale)
+ right = mh-scale-1;
+ if (left = mh-scale)
+ left = mh-scale-1;
} else {
/* these may have 5 or 6 bit resolution */
if (oss_channel == SOUND_MIXER_VOLUME ||
@@ -294,27 +298,49 @@
right = ((100 - right) * scale) / 100;
left = ((100 - left) * scale) / 100;
- }
+ if (right = scale)
+ right = scale-1;
+ if (left = scale)
+ left = scale-1;
+ }
val = (left 8) | right;
}
} else if (oss_channel == SOUND_MIXER_BASS) {
val = codec-codec_read(codec , mh-offset) ~0x0f00;
- val |= 100 - left) * mh-scale) / 100) 8) 0x0e00;
+ left = ((100 - left) * mh-scale) / 100;
+ if (left = mh-scale)
+ left = mh-scale-1;
+ val |= (left 8) 0x0e00;
} else if (oss_channel == SOUND_MIXER_TREBLE) {
val = codec-codec_read(codec , mh-offset) ~0x000f;
- val |= (((100 - left) * mh-scale) / 100) 0x000e;
+ left = ((100 - left) * mh-scale) / 100;
+ if (left = mh-scale)
+ left = mh-scale-1;
+ val |= left 0x000e;
} else if(left == 0) {
val = AC97_MUTE;
} else if (oss_channel == SOUND_MIXER_SPEAKER) {
- val = (((100 - left) * mh-scale) / 100) 1;
+ left = ((100 - left) * mh-scale) / 100;
+ if (left = mh-scale)
+ left = mh-scale-1;
+ val = left 1;
} else if (oss_channel == SOUND_MIXER_PHONEIN) {
- val = (((100 - left) * mh-scale) / 100);
+ left = ((100 - left) * mh-scale) / 100;
+ if (left = mh-scale)
+ left = mh-scale-1;
+ val = left;
} else if (oss_channel == SOUND_MIXER_PHONEOUT) {
scale = (1 codec-bit_resolution);
- val = (((100 - left) * scale) / 100);
+ left = ((100 - left) * scale) / 100;
+ if (left = mh-scale)
+ left = mh-scale-1;
+ val = left;
} else if (oss_channel == SOUND_MIXER_MIC) {
val = codec-codec_read(codec , mh-offset) ~0x801f;
- val |= (((100 - left) * mh-scale) / 100);
+ left = ((100 - left) * mh-scale) / 100;
+ if (left = mh-scale)
+ left = mh-scale-1;
+ val |= left;
/* the low bit is optional in the tone sliders and masking
it lets us avoid the 0xf 'bypass'.. */
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre6 still very broken
Vojtech Pavlik wrote: > Oops? I thought the paired controller there is for OSes not being able > to handle EHCI yet? So that USB works even for those ... I think EHCI > should handle even 1.x devices ... I may be wrong, though. Check the Intel EHCI spec. Esp. the chapter about port handover... Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre6 still very broken
Vojtech Pavlik wrote: Oops? I thought the paired controller there is for OSes not being able to handle EHCI yet? So that USB works even for those ... I think EHCI should handle even 1.x devices ... I may be wrong, though. Check the Intel EHCI spec. Esp. the chapter about port handover... Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: 2.4.0-testx: sound drivers
In poll, the DMA buffers need to be allocated if not already, otherwise
fragsize, dmasize, count etc. contain bogus values, which lead to bogus
poll mask return. (The alternative would have been to special case
!dmabuf_*.ready and defer DMA buffer allocation, but when the user
does poll, it likely means he will want to also read/write to the
device...)
Testcase provided by Hrafnkell Eiriksson <[EMAIL PROTECTED]>
Tom
--- drivers/sound/es1370.c.orig Tue Nov 21 00:37:47 2000
+++ drivers/sound/es1370.c Tue Nov 21 00:41:45 2000
@@ -117,6 +117,7 @@
*08.01.2000 0.32 Prevent some ioctl's from returning bad count values on
underrun/overrun;
* Tim Janik's BSE (Bedevilled Sound Engine) found this
*07.02.2000 0.33 Use pci_alloc_consistent and pci_register_driver
+ *21.11.2000 0.34 Initialize dma buffers in poll, otherwise poll may return a
+bogus mask
*
* some important things missing in Ensoniq documentation:
*
@@ -1281,10 +1282,16 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
- if (file->f_mode & FMODE_WRITE)
+ if (file->f_mode & FMODE_WRITE) {
+ if (!s->dma_dac2.ready && prog_dmabuf_dac2(s))
+ return 0;
poll_wait(file, >dma_dac2.wait, wait);
- if (file->f_mode & FMODE_READ)
+ }
+ if (file->f_mode & FMODE_READ) {
+ if (!s->dma_adc.ready && prog_dmabuf_adc(s))
+ return 0;
poll_wait(file, >dma_adc.wait, wait);
+ }
spin_lock_irqsave(>lock, flags);
es1370_update_ptr(s);
if (file->f_mode & FMODE_READ) {
@@ -1856,6 +1863,8 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
+ if (!s->dma_dac1.ready && prog_dmabuf_dac1(s))
+ return 0;
poll_wait(file, >dma_dac1.wait, wait);
spin_lock_irqsave(>lock, flags);
es1370_update_ptr(s);
@@ -2656,7 +2665,7 @@
{
if (!pci_present()) /* No PCI bus in this machine! */
return -ENODEV;
- printk(KERN_INFO "es1370: version v0.33 time " __TIME__ " " __DATE__ "\n");
+ printk(KERN_INFO "es1370: version v0.34 time " __TIME__ " " __DATE__ "\n");
return pci_module_init(_driver);
}
--- drivers/sound/es1371.c.orig Tue Nov 21 00:37:50 2000
+++ drivers/sound/es1371.c Tue Nov 21 00:41:05 2000
@@ -102,6 +102,7 @@
*07.02.2000 0.25 Use ac97_codec
*01.03.2000 0.26 SPDIF patch by Mikael Bouillot <[EMAIL PROTECTED]>
* Use pci_module_init
+ *21.11.2000 0.27 Initialize dma buffers in poll, otherwise poll may return a
+bogus mask
*/
/*/
@@ -1464,10 +1465,16 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
- if (file->f_mode & FMODE_WRITE)
+ if (file->f_mode & FMODE_WRITE) {
+ if (!s->dma_dac2.ready && prog_dmabuf_dac2(s))
+ return 0;
poll_wait(file, >dma_dac2.wait, wait);
- if (file->f_mode & FMODE_READ)
+ }
+ if (file->f_mode & FMODE_READ) {
+ if (!s->dma_adc.ready && prog_dmabuf_adc(s))
+ return 0;
poll_wait(file, >dma_adc.wait, wait);
+ }
spin_lock_irqsave(>lock, flags);
es1371_update_ptr(s);
if (file->f_mode & FMODE_READ) {
@@ -2036,6 +2043,8 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
+ if (!s->dma_dac1.ready && prog_dmabuf_dac1(s))
+ return 0;
poll_wait(file, >dma_dac1.wait, wait);
spin_lock_irqsave(>lock, flags);
es1371_update_ptr(s);
@@ -2928,7 +2937,7 @@
{
if (!pci_present()) /* No PCI bus in this machine! */
return -ENODEV;
- printk(KERN_INFO PFX "version v0.26 time " __TIME__ " " __DATE__ "\n");
+ printk(KERN_INFO PFX "version v0.27 time " __TIME__ " " __DATE__ "\n");
return pci_module_init(_driver);
}
--- drivers/sound/esssolo1.c.orig Tue Nov 21 00:37:58 2000
+++ drivers/sound/esssolo1.cTue Nov 21 00:42:57 2000
@@ -69,6 +69,7 @@
*07.02.2000 0.13 Use pci_alloc_consistent and pci_register_driver
*19.02.2000 0.14 Use pci_dma_supported to determine if recording should be
disabled
*13.03.2000 0.15 Reintroduce initialization of a couple of PCI config space
registers
+ *21.11.2000 0.16 Initialize dma buffers in poll, otherwise poll may return a
+bogus mask
*/
/*/
@@ -1168,10 +1169,16 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
- if (file->f_mode & FMODE_WRITE)
+ if (file->f_mode & FMODE_WRITE) {
+ if (!s->dma_dac.ready && prog_dmabuf_dac(s))
+ return 0;
poll_wait(file, >dma_dac.wait, wait);
- if (file->f_mode & FMODE_READ)
+
[PATCH]: 2.2.18pre: sound drivers
In poll, the DMA buffers need to be allocated if not already, otherwise
fragsize, dmasize, count etc. contain bogus values, which lead to bogus
poll mask return. (The alternative would have been to special case
!dmabuf_*.ready and defer DMA buffer allocation, but when the user
does poll, it likely means he will want to also read/write to the
device...)
Testcase provided by Hrafnkell Eiriksson <[EMAIL PROTECTED]>
Tom
--- drivers/sound/es1370.c.orig Tue Nov 21 00:15:35 2000
+++ drivers/sound/es1370.c Tue Nov 21 00:54:12 2000
@@ -114,6 +114,7 @@
*03.09.1999 0.30 change read semantics for MIDI to match
* OSS more closely; remove possible wakeup race
*28.10.1999 0.31 More waitqueue races fixed
+ *21.11.2000 0.32 Initialize dma buffers in poll, otherwise poll may return a
+bogus mask
*
* some important things missing in Ensoniq documentation:
*
@@ -1298,6 +1299,12 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
+ if (file->f_mode & FMODE_WRITE)
+ if (!s->dma_dac2.ready && prog_dmabuf_dac2(s))
+ return 0;
+ if (file->f_mode & FMODE_READ)
+ if (!s->dma_adc.ready && prog_dmabuf_adc(s))
+ return 0;
if (file->f_mode & (FMODE_READ|FMODE_WRITE))
poll_wait(file, >poll_wait, wait);
spin_lock_irqsave(>lock, flags);
@@ -1836,6 +1843,8 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
+ if (!s->dma_dac1.ready && prog_dmabuf_dac1(s))
+ return 0;
poll_wait(file, >dma_dac1.wait, wait);
spin_lock_irqsave(>lock, flags);
es1370_update_ptr(s);
@@ -2463,7 +2472,7 @@
if (!pci_present()) /* No PCI bus in this machine! */
return -ENODEV;
- printk(KERN_INFO "es1370: version v0.31 time " __TIME__ " " __DATE__ "\n");
+ printk(KERN_INFO "es1370: version v0.32 time " __TIME__ " " __DATE__ "\n");
while (index < NR_DEVICE &&
(pcidev = pci_find_device(PCI_VENDOR_ID_ENSONIQ,
PCI_DEVICE_ID_ENSONIQ_ES1370, pcidev))) {
if (pcidev->base_address[0] == 0 ||
--- drivers/sound/es1371.c.orig Tue Nov 21 00:33:35 2000
+++ drivers/sound/es1371.c Tue Nov 21 00:54:05 2000
@@ -96,6 +96,7 @@
* detect ES137x chip and derivatives.
*05.01.2000 0.22 Should now work with rev7 boards; patch by
* Eric Lemar, [EMAIL PROTECTED]
+ *21.11.2000 0.23 Initialize dma buffers in poll, otherwise poll may return a
+bogus mask
*/
/*/
@@ -1881,6 +1882,12 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
+ if (file->f_mode & FMODE_WRITE)
+ if (!s->dma_dac2.ready && prog_dmabuf_dac2(s))
+ return 0;
+ if (file->f_mode & FMODE_READ)
+ if (!s->dma_adc.ready && prog_dmabuf_adc(s))
+ return 0;
if (file->f_mode & (FMODE_WRITE|FMODE_READ))
poll_wait(file, >poll_wait, wait);
spin_lock_irqsave(>lock, flags);
@@ -2416,6 +2423,8 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
+ if (!s->dma_dac1.ready && prog_dmabuf_dac1(s))
+ return 0;
poll_wait(file, >dma_dac1.wait, wait);
spin_lock_irqsave(>lock, flags);
es1371_update_ptr(s);
@@ -3261,7 +3270,7 @@
if (!pci_present()) /* No PCI bus in this machine! */
return -ENODEV;
- printk(KERN_INFO "es1371: version v0.22 time " __TIME__ " " __DATE__ "\n");
+ printk(KERN_INFO "es1371: version v0.23 time " __TIME__ " " __DATE__ "\n");
for (pcidev = pci_devices; pcidev && index < NR_DEVICE; pcidev = pcidev->next)
{
if (pcidev->vendor == PCI_VENDOR_ID_ENSONIQ) {
if (pcidev->device != PCI_DEVICE_ID_ENSONIQ_ES1371 &&
--- drivers/sound/esssolo1.c.orig Tue Nov 21 00:33:49 2000
+++ drivers/sound/esssolo1.cTue Nov 21 00:57:17 2000
@@ -63,6 +63,7 @@
*28.10.1999 0.10 More waitqueue races fixed
*09.12.1999 0.11 Work around stupid Alpha port issue
(virt_to_bus(kmalloc(GFP_DMA)) > 16M)
* Disabling recording on Alpha
+ *21.11.2000 0.12 Initialize dma buffers in poll, otherwise poll may return a
+bogus mask
*
*/
@@ -180,6 +181,7 @@
struct semaphore open_sem;
mode_t open_mode;
wait_queue_head_t open_wait;
+ wait_queue_head_t poll_wait;
struct dmabuf {
void *rawbuf;
@@ -555,16 +557,20 @@
s->dma_adc.hwptr, s->dma_adc.swptr, s->dma_adc.dmasize,
s->dma_adc.count);
#endif
if (s->dma_adc.mapped) {
- if (s->dma_adc.count >= (signed)s->dma_adc.fragsize)
+ if (s->dma_adc.count >= (signed)s->dma_adc.fragsize) {
Re: test11-pre6 still very broken
Linus Torvalds wrote: > I'd disagree. UHCI has tons of advantages, not the least of which is > [Cthat it was there first and is widely available. If OHCI hadn't been > done we'd have _one_ nice good USB controller implementation instead of UHCI has a couple of disadvantages, though (and some of them could have been fixed with only very little added gates). For example: - one cannot reliably unlink transfer buffers from the queues without waiting 1ms - bandwidth reclamation can be a real PCI hog > I hope EHCI makes it all moot. Some way or another. Only for USB2 devices. EHCI is supposed to be paired with an existing UHCI or OHCI controller core that is supposed to take over the USB connector if an USB 1.x hub or device is plugged in. So we end up needing to support UHCI and OHCI for a very long time, I don't see mice and keyboards going USB2 anytime soon 8-) Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: 2.4.0-testx: sound drivers
In poll, the DMA buffers need to be allocated if not already, otherwise
fragsize, dmasize, count etc. contain bogus values, which lead to bogus
poll mask return. (The alternative would have been to special case
!dmabuf_*.ready and defer DMA buffer allocation, but when the user
does poll, it likely means he will want to also read/write to the
device...)
Testcase provided by Hrafnkell Eiriksson [EMAIL PROTECTED]
Tom
--- drivers/sound/es1370.c.orig Tue Nov 21 00:37:47 2000
+++ drivers/sound/es1370.c Tue Nov 21 00:41:45 2000
@@ -117,6 +117,7 @@
*08.01.2000 0.32 Prevent some ioctl's from returning bad count values on
underrun/overrun;
* Tim Janik's BSE (Bedevilled Sound Engine) found this
*07.02.2000 0.33 Use pci_alloc_consistent and pci_register_driver
+ *21.11.2000 0.34 Initialize dma buffers in poll, otherwise poll may return a
+bogus mask
*
* some important things missing in Ensoniq documentation:
*
@@ -1281,10 +1282,16 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
- if (file-f_mode FMODE_WRITE)
+ if (file-f_mode FMODE_WRITE) {
+ if (!s-dma_dac2.ready prog_dmabuf_dac2(s))
+ return 0;
poll_wait(file, s-dma_dac2.wait, wait);
- if (file-f_mode FMODE_READ)
+ }
+ if (file-f_mode FMODE_READ) {
+ if (!s-dma_adc.ready prog_dmabuf_adc(s))
+ return 0;
poll_wait(file, s-dma_adc.wait, wait);
+ }
spin_lock_irqsave(s-lock, flags);
es1370_update_ptr(s);
if (file-f_mode FMODE_READ) {
@@ -1856,6 +1863,8 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
+ if (!s-dma_dac1.ready prog_dmabuf_dac1(s))
+ return 0;
poll_wait(file, s-dma_dac1.wait, wait);
spin_lock_irqsave(s-lock, flags);
es1370_update_ptr(s);
@@ -2656,7 +2665,7 @@
{
if (!pci_present()) /* No PCI bus in this machine! */
return -ENODEV;
- printk(KERN_INFO "es1370: version v0.33 time " __TIME__ " " __DATE__ "\n");
+ printk(KERN_INFO "es1370: version v0.34 time " __TIME__ " " __DATE__ "\n");
return pci_module_init(es1370_driver);
}
--- drivers/sound/es1371.c.orig Tue Nov 21 00:37:50 2000
+++ drivers/sound/es1371.c Tue Nov 21 00:41:05 2000
@@ -102,6 +102,7 @@
*07.02.2000 0.25 Use ac97_codec
*01.03.2000 0.26 SPDIF patch by Mikael Bouillot [EMAIL PROTECTED]
* Use pci_module_init
+ *21.11.2000 0.27 Initialize dma buffers in poll, otherwise poll may return a
+bogus mask
*/
/*/
@@ -1464,10 +1465,16 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
- if (file-f_mode FMODE_WRITE)
+ if (file-f_mode FMODE_WRITE) {
+ if (!s-dma_dac2.ready prog_dmabuf_dac2(s))
+ return 0;
poll_wait(file, s-dma_dac2.wait, wait);
- if (file-f_mode FMODE_READ)
+ }
+ if (file-f_mode FMODE_READ) {
+ if (!s-dma_adc.ready prog_dmabuf_adc(s))
+ return 0;
poll_wait(file, s-dma_adc.wait, wait);
+ }
spin_lock_irqsave(s-lock, flags);
es1371_update_ptr(s);
if (file-f_mode FMODE_READ) {
@@ -2036,6 +2043,8 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
+ if (!s-dma_dac1.ready prog_dmabuf_dac1(s))
+ return 0;
poll_wait(file, s-dma_dac1.wait, wait);
spin_lock_irqsave(s-lock, flags);
es1371_update_ptr(s);
@@ -2928,7 +2937,7 @@
{
if (!pci_present()) /* No PCI bus in this machine! */
return -ENODEV;
- printk(KERN_INFO PFX "version v0.26 time " __TIME__ " " __DATE__ "\n");
+ printk(KERN_INFO PFX "version v0.27 time " __TIME__ " " __DATE__ "\n");
return pci_module_init(es1371_driver);
}
--- drivers/sound/esssolo1.c.orig Tue Nov 21 00:37:58 2000
+++ drivers/sound/esssolo1.cTue Nov 21 00:42:57 2000
@@ -69,6 +69,7 @@
*07.02.2000 0.13 Use pci_alloc_consistent and pci_register_driver
*19.02.2000 0.14 Use pci_dma_supported to determine if recording should be
disabled
*13.03.2000 0.15 Reintroduce initialization of a couple of PCI config space
registers
+ *21.11.2000 0.16 Initialize dma buffers in poll, otherwise poll may return a
+bogus mask
*/
/*/
@@ -1168,10 +1169,16 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
- if (file-f_mode FMODE_WRITE)
+ if (file-f_mode FMODE_WRITE) {
+ if (!s-dma_dac.ready prog_dmabuf_dac(s))
+ return 0;
poll_wait(file, s-dma_dac.wait, wait);
- if (file-f_mode FMODE_READ)
+ }
+ if
[PATCH]: 2.2.18pre: sound drivers
In poll, the DMA buffers need to be allocated if not already, otherwise
fragsize, dmasize, count etc. contain bogus values, which lead to bogus
poll mask return. (The alternative would have been to special case
!dmabuf_*.ready and defer DMA buffer allocation, but when the user
does poll, it likely means he will want to also read/write to the
device...)
Testcase provided by Hrafnkell Eiriksson [EMAIL PROTECTED]
Tom
--- drivers/sound/es1370.c.orig Tue Nov 21 00:15:35 2000
+++ drivers/sound/es1370.c Tue Nov 21 00:54:12 2000
@@ -114,6 +114,7 @@
*03.09.1999 0.30 change read semantics for MIDI to match
* OSS more closely; remove possible wakeup race
*28.10.1999 0.31 More waitqueue races fixed
+ *21.11.2000 0.32 Initialize dma buffers in poll, otherwise poll may return a
+bogus mask
*
* some important things missing in Ensoniq documentation:
*
@@ -1298,6 +1299,12 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
+ if (file-f_mode FMODE_WRITE)
+ if (!s-dma_dac2.ready prog_dmabuf_dac2(s))
+ return 0;
+ if (file-f_mode FMODE_READ)
+ if (!s-dma_adc.ready prog_dmabuf_adc(s))
+ return 0;
if (file-f_mode (FMODE_READ|FMODE_WRITE))
poll_wait(file, s-poll_wait, wait);
spin_lock_irqsave(s-lock, flags);
@@ -1836,6 +1843,8 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
+ if (!s-dma_dac1.ready prog_dmabuf_dac1(s))
+ return 0;
poll_wait(file, s-dma_dac1.wait, wait);
spin_lock_irqsave(s-lock, flags);
es1370_update_ptr(s);
@@ -2463,7 +2472,7 @@
if (!pci_present()) /* No PCI bus in this machine! */
return -ENODEV;
- printk(KERN_INFO "es1370: version v0.31 time " __TIME__ " " __DATE__ "\n");
+ printk(KERN_INFO "es1370: version v0.32 time " __TIME__ " " __DATE__ "\n");
while (index NR_DEVICE
(pcidev = pci_find_device(PCI_VENDOR_ID_ENSONIQ,
PCI_DEVICE_ID_ENSONIQ_ES1370, pcidev))) {
if (pcidev-base_address[0] == 0 ||
--- drivers/sound/es1371.c.orig Tue Nov 21 00:33:35 2000
+++ drivers/sound/es1371.c Tue Nov 21 00:54:05 2000
@@ -96,6 +96,7 @@
* detect ES137x chip and derivatives.
*05.01.2000 0.22 Should now work with rev7 boards; patch by
* Eric Lemar, [EMAIL PROTECTED]
+ *21.11.2000 0.23 Initialize dma buffers in poll, otherwise poll may return a
+bogus mask
*/
/*/
@@ -1881,6 +1882,12 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
+ if (file-f_mode FMODE_WRITE)
+ if (!s-dma_dac2.ready prog_dmabuf_dac2(s))
+ return 0;
+ if (file-f_mode FMODE_READ)
+ if (!s-dma_adc.ready prog_dmabuf_adc(s))
+ return 0;
if (file-f_mode (FMODE_WRITE|FMODE_READ))
poll_wait(file, s-poll_wait, wait);
spin_lock_irqsave(s-lock, flags);
@@ -2416,6 +2423,8 @@
unsigned int mask = 0;
VALIDATE_STATE(s);
+ if (!s-dma_dac1.ready prog_dmabuf_dac1(s))
+ return 0;
poll_wait(file, s-dma_dac1.wait, wait);
spin_lock_irqsave(s-lock, flags);
es1371_update_ptr(s);
@@ -3261,7 +3270,7 @@
if (!pci_present()) /* No PCI bus in this machine! */
return -ENODEV;
- printk(KERN_INFO "es1371: version v0.22 time " __TIME__ " " __DATE__ "\n");
+ printk(KERN_INFO "es1371: version v0.23 time " __TIME__ " " __DATE__ "\n");
for (pcidev = pci_devices; pcidev index NR_DEVICE; pcidev = pcidev-next)
{
if (pcidev-vendor == PCI_VENDOR_ID_ENSONIQ) {
if (pcidev-device != PCI_DEVICE_ID_ENSONIQ_ES1371
--- drivers/sound/esssolo1.c.orig Tue Nov 21 00:33:49 2000
+++ drivers/sound/esssolo1.cTue Nov 21 00:57:17 2000
@@ -63,6 +63,7 @@
*28.10.1999 0.10 More waitqueue races fixed
*09.12.1999 0.11 Work around stupid Alpha port issue
(virt_to_bus(kmalloc(GFP_DMA)) 16M)
* Disabling recording on Alpha
+ *21.11.2000 0.12 Initialize dma buffers in poll, otherwise poll may return a
+bogus mask
*
*/
@@ -180,6 +181,7 @@
struct semaphore open_sem;
mode_t open_mode;
wait_queue_head_t open_wait;
+ wait_queue_head_t poll_wait;
struct dmabuf {
void *rawbuf;
@@ -555,16 +557,20 @@
s-dma_adc.hwptr, s-dma_adc.swptr, s-dma_adc.dmasize,
s-dma_adc.count);
#endif
if (s-dma_adc.mapped) {
- if (s-dma_adc.count = (signed)s-dma_adc.fragsize)
+ if (s-dma_adc.count = (signed)s-dma_adc.fragsize) {
wake_up(s-dma_adc.wait);
+
Re: test11-pre6 still very broken
Linus Torvalds wrote: I'd disagree. UHCI has tons of advantages, not the least of which is [Cthat it was there first and is widely available. If OHCI hadn't been done we'd have _one_ nice good USB controller implementation instead of UHCI has a couple of disadvantages, though (and some of them could have been fixed with only very little added gates). For example: - one cannot reliably unlink transfer buffers from the queues without waiting 1ms - bandwidth reclamation can be a real PCI hog I hope EHCI makes it all moot. Some way or another. Only for USB2 devices. EHCI is supposed to be paired with an existing UHCI or OHCI controller core that is supposed to take over the USB connector if an USB 1.x hub or device is plugged in. So we end up needing to support UHCI and OHCI for a very long time, I don't see mice and keyboards going USB2 anytime soon 8-) Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poll and OSS API
"Richard B. Johnson" wrote: > The specification is bogus and should be fixed. select() is not Don't tell me, I didn't write that spec. > side-affects is patently wrong. ioctl() was designed to control > things. It already exists, ioctl(fd, SNDCTL_DSP_SETTRIGGER, PCM_ENABLE_INPUT). If we officially declare the poll/select side effect to be unacceptable, I'm happy with it, as my sound drivers already work that way 8-) Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Poll and OSS API
The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff) specifies that a select _with the sounddriver's filedescriptor set in the read mask_ should start the recording. Implementing this is currently not possible, as the driver does not get to know whether the application had the filedescriptor set in the select call. Similarily for poll, the driver does not get the caller's events. Different drivers do it differently. The ISA SB driver just unconditionally starts recording on select, whether the bit in the read mask is set or not. es137* unconditionally does not start recording. Both drivers violate the API. I don't think this is all that important though, because it's that way for more than a year and the first complaint reached me yesterday. Comments? Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Poll and OSS API
The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff) specifies that a select _with the sounddriver's filedescriptor set in the read mask_ should start the recording. Implementing this is currently not possible, as the driver does not get to know whether the application had the filedescriptor set in the select call. Similarily for poll, the driver does not get the caller's events. Different drivers do it differently. The ISA SB driver just unconditionally starts recording on select, whether the bit in the read mask is set or not. es137* unconditionally does not start recording. Both drivers violate the API. I don't think this is all that important though, because it's that way for more than a year and the first complaint reached me yesterday. Comments? Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poll and OSS API
"Richard B. Johnson" wrote: The specification is bogus and should be fixed. select() is not Don't tell me, I didn't write that spec. side-affects is patently wrong. ioctl() was designed to control things. It already exists, ioctl(fd, SNDCTL_DSP_SETTRIGGER, PCM_ENABLE_INPUT). If we officially declare the poll/select side effect to be unacceptable, I'm happy with it, as my sound drivers already work that way 8-) Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
Alan Cox wrote: > > > 4. Boot Time Failures > > > > * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for > >more info) > > Add Palmax PD1100 hangs during boot since 2.4.0-test9 My Asus P55TP4 (i430FX)/AMD K5 PC also crashes after "Booting the kernel..." and before printing anything else Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
Alan Cox wrote: 4. Boot Time Failures * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for more info) Add Palmax PD1100 hangs during boot since 2.4.0-test9 My Asus P55TP4 (i430FX)/AMD K5 PC also crashes after "Booting the kernel..." and before printing anything else Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
