Re: [Alsa-devel] Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload
El Lunes, 1 de Septiembre de 2003 15:25, Takashi Iwai escribió: Martin Langer wrote: But it fails in case of one device if you do a re-plugin! The first plugin loads the firmware fine. Then you unplug your device and the module still remains in a status of sleep. If you plug in your device again it woke up, but it won't get a download of firmware and I don't saw a hotplug event in the logfile. I believe here is a solution in the ALSA USB corner neccessary. The download can not start by a hotplug event in this case! (My LEDs are still dark here!) perhaps pre-install is not called because the module was not unloaded. i thought hotplug can call the script in a usermap in prior to loading the usb module ? (at least, the hotplug stuff on suse distro does it, initializing the ALSA stuff before loading snd-usb-audio to keep the consistency.) if so, the script should be triggered from hotplug. Yes, it is possible. I remembered a post from Christian Zoz about it, with the relevant scripts attached: http://marc.theaimsgroup.com/?l=linux-hotplug-develm=105176985220653w=2 The trick is to include snd-usb-audio (and some other module names) in the /etc/hotplug/blacklist file; this prevents the automatic module loading. Then, you can invoke in your own hotplug script a modprobe snd-usb-audio command when the usb event ($ACTION environment variable) is add, and modprobe -r snd-usb-audio when the event is remove. But the problem with this was already argued by Karsten: what if you have more that one Tascam USB device? when you plug in the second device, the module unload command will fail because the module is busy, and the fpga configuration data will not be loaded. The solution proposed is a smart loader program talking the hwdep device created by a kernel module, instead of doing the USB transfer by itsef. Of course, if you have a single device, rbtload can be used from hotplug scripts or even be invoked by modutis (pre-install in modules.conf) if you don't want to use hotplug, and you don't plug/unplug the device very often. A better solution IMO is to use hotplug to trigger a smart loader talking to an ALSA hwdep device. Regards, Pedro -- ALSA Library Bindings for Pascal http://alsapas.alturl.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload
At Sun, 31 Aug 2003 11:32:37 +0200, Martin Langer wrote: On Sun, Aug 31, 2003 at 12:27:42AM +0200, Pedro Lopez-Cabanillas wrote: Yes, but it is easier to use the vendor and product id instead of usb dev full path. Something like this: pre-install snd-usb-us122 /usr/sbin/rbtload -P0x8007 -V0x1604 -p71 -Ius122.rbt See the attached patch (untested). Yes again, and it is the same with post-install of course. For USB devices on Linux, there is only a way to handle every event when you plug and unplug a device: hotplug. But it fails in case of one device if you do a re-plugin! The first plugin loads the firmware fine. Then you unplug your device and the module still remains in a status of sleep. If you plug in your device again it woke up, but it won't get a download of firmware and I don't saw a hotplug event in the logfile. I believe here is a solution in the ALSA USB corner neccessary. The download can not start by a hotplug event in this case! (My LEDs are still dark here!) perhaps pre-install is not called because the module was not unloaded. i thought hotplug can call the script in a usermap in prior to loading the usb module ? (at least, the hotplug stuff on suse distro does it, initializing the ALSA stuff before loading snd-usb-audio to keep the consistency.) if so, the script should be triggered from hotplug. Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload
On Sun, Aug 31, 2003 at 12:27:42AM +0200, Pedro Lopez-Cabanillas wrote: Yes, but it is easier to use the vendor and product id instead of usb dev full path. Something like this: pre-install snd-usb-us122 /usr/sbin/rbtload -P0x8007 -V0x1604 -p71 -Ius122.rbt See the attached patch (untested). Yes again, and it is the same with post-install of course. For USB devices on Linux, there is only a way to handle every event when you plug and unplug a device: hotplug. But it fails in case of one device if you do a re-plugin! The first plugin loads the firmware fine. Then you unplug your device and the module still remains in a status of sleep. If you plug in your device again it woke up, but it won't get a download of firmware and I don't saw a hotplug event in the logfile. I believe here is a solution in the ALSA USB corner neccessary. The download can not start by a hotplug event in this case! (My LEDs are still dark here!) martin --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload
On Fri, Aug 29, 2003 at 09:59:13PM +0200, Pedro Lopez-Cabanillas wrote: We can use something like this for Tascam USB devices: pre-install snd-usb-us428 /usr/sbin/rbtload [...] In this way we can be sure that rbtload is executed *before* the module is installed. Of course, we still need to modify rbtload a bit, but it's not a big change. It is not necessary to use the hwdep infrastructure at all. I would prefer this pre-install way. Because we could use rbtload for further FPGA, but non-Tascam devices in an easy way in the future. I've just tried it out on us122 and it's working in my environment. If you know your rbtload parameters it's even possible with an unchanged rbtload 0.1! But I believe in case of two tascam devices the device number two won't get an fw download because the module is already loaded and the pre-install option can't make the download for device number two. But Karsten's proposal could handle more devices without such a restriction and that's a good argument IMO. martin --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload
Am Freitag 29 August 2003 17:34 schrieb Pedro Lopez-Cabanillas: El Jueves, 28 de Agosto de 2003 23:52, Karsten Wiese escribió: when a hotplug occurs (EZUSB Firmware not being looked at here, works as before), the kernel 1.) asks snd-usb-us428.o, if it wants to have the device. snd-usb-us428.o says 'yes!'. this latest snd-usb-us428.o will not start any ALSA-Activity in this stage. It just owns the interface to the us428 (and implements 2 new ioctl-able entriepoints). ...assuming that your module (snd-usb-us428) is already loaded, or it is statically linked into the kernel. Anyway, hotplug will load the module if it's not loaded yet. 2.) starts rbtload (by means of the hotplug-scripts) to download the fpga code. this hacked rbtload does the download by means of standard ioctl() - calls to snd-usb-us428.o. Thus we don't need libusb here anymore. (libusb is still used here for minimizing changing efforts.) if download is finished, snd-usb-us428.o ALSA-Activities are started by another ioctl to snd-usb-us428.o. Result: us428 works as before. What do you think about setting up a 0.2 this way? Not sure. You explained what you are doing, but not why you are doing that. I don't have a us428 or us122 here, so I can't test it myself. I can guess that there is a problem if you try to use rbtload when the kernel driver is already loaded locking the USB interface, and forces rbtload to fail. Another issue is that rbtload can be rewritten without libusb at all. But perhaps you have found some other issues. A good starting point could be to share your concerns, and after that we can try to find the best solution for them. Of course we can arrive to the conclusion that your hack is the best solution at all, but please: let's talk first. the sequence first 'Module load' then 'hotplug script start' is hardcoded in the kernel's usb.c. Before FPGA download, the usx2x dont work. So it is useless to start ALSA-activities at this stage. None the less the module has to say 'YES, I want the device' now. (Maybe there are other ways for an USB-module to get attached to their device(s) but I could not find them.) The usx2x keep their USB ProductIDs after the FPGA load, so the kernel doesn't see a 'new' device and thus wont ask the module again. We know rbtload_0.1 can't download with a module owning the target (interface claim must fail). So before rbtload getting involved, we could unload the module, rbtload and load the module again? Yes, but what if there where more then 1 usx2x attached to the system? unload would fail, if 1 usx2x would be in use. some minutes break Just received an email from Takashi. He asks why not do it like he did it before for the vx interfaces. I found the driver code. The firmware downloader vxloader is part of alsa-tools. as far as i can see it works like I outlined above, except that ALSA already has a sceleton for this purpose. If you are curious, grep for snd_hwdep_dsp_image_t. Now I think I'll make use of that so called 'hardware dependant interface' in the us428 module. Then there should be rbtload 0.2 using this interface from userspace to download the firmware and actually start the ALSA-functions of the usx2x. regards, Karsten --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload
El Viernes, 29 de Agosto de 2003 20:12, Karsten Wiese escribió: Just received an email from Takashi. He asks why not do it like he did it before for the vx interfaces. Another idea, after a closer look on the vxloader utility... Why not to forget hotplug for rbtload? using modutils instead, like vxloader does. quoting vxloader's README: For loading the firmware automatically after the module is loaded, use the post-install command. For example, add the following entry to /etc/modules.conf for VX222 driver: post-install snd-vx222 /usr/bin/vxloader We can use something like this for Tascam USB devices: pre-install snd-usb-us428 /usr/sbin/rbtload [...] In this way we can be sure that rbtload is executed *before* the module is installed. Of course, we still need to modify rbtload a bit, but it's not a big change. It is not necessary to use the hwdep infrastructure at all. Regards, Pedro -- ALSA Library Bindings for Pascal http://alsapas.alturl.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
