[openbeos-midi] Re: mpu401 module

  • From: Philippe Houdoin <philippe.houdoin@xxxxxxx>
  • To: openbeos-midi@xxxxxxxxxxxxx
  • Date: Fri, 10 Jan 2003 13:04:17 +0100 (CET)

Greg wrote:
> This all happens before the interupt handler is even installed, or midi 
> interrupts are enabled in the soundcard.  
> if ( mpu401->create_device (base_addr + A_MUDATA , &card.midi.driver, 0, 
> midi_interrupt_op, &card.midi) == B_OK)
> {....}
> If I understand what you mean by callback, the function 'midi_interrupt_op' 
> never gets called, or the interrupt hook. 

Make sense, as I guess the interrupt_op will start to be called when 
the mpu401->read/write_hook() will require to activate / desactivate the I/O 
mode of the UART behind the MPU401.
The interrupt_hook is never called by the module itself, unless you call it 
from your interrupt handler or install it directly as the interrupt handler on 
a MPU interrupt.

>  I think that the problem is somehow in the way I create_device.  
> It gets created, but the first time its called, it crashes. 
>  Maybe an incorrect pointer.  

First, it seems that the mpu401->open_hook() send you to frozen land here.
Did you check the card.midi.driver value here? Is it still the same value 
than after a successfull mpu401->create_device() call?

Second, check that the port address you pass to create_device() is the right 
one. There is also this weirdo "workaround" argument in create_device(), too...

Last, you keep the MPU401 module loaded all long (init_driver -> 
uninit_driver), right?

> Also, in the Ad1816 source, the 
> parameter &card.midi is just 0.
> I'm not sure what the module is looking for here.

The last parameter of mpu401->create_device() is the *cookie* value you want to 
be passed back when the module will call your interrupt_op callback.
As the Ad1816 driver doesn't care to support more than one card, and use 
a global variable to keep all his stuff, the author don't use this last 
argument. 

The Sonic Vibes, on other side, use it, because the driver support multiple 
devices. Which is recommended for a driver author for a PCI device these 
days... :-)

PS: Sorry, maybe bedrivertalk will have been a better place now than here.
You tell me...

-Philippe

Other related posts: