Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload

Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload

[Karsten Wiese]

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

Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload

[Pedro Lopez-Cabanillas]

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

Re: Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload

[Martin Langer]

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

Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload

[Martin Langer]

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

Re: Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload

[Takashi Iwai]

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

Re: Re: [usb-midi-fw-devel] proposal concerning cooperation of snd-usb-usx2x.o and rbtload

[Pedro Lopez-Cabanillas]

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-devel&m=105176985220653&w=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