midi problem, an isa device on a pci card

[Mathew Kanner]

On Apr 08, M. Warner Losh wrote:
> In message: <20030408042202.GS17533 at cnd.mcgill.ca>
>             Mathew Kanner <mat at cnd.mcgill.ca> writes:

[snip]

> : > that's not possible.  It is *NOT* an ISA device unless it is on a card
> : > that has ISA fingers on it.  Otherwise it *IS* a PCI device.  Does the
> : > pci card have a PCI to ISA bridge on it?  If not, then you have to
> : > deal with it as a PCI bus.
> : 
> : 	I learned my lesson in math class not to argue from instinct
> : alone, so I accept that what you are saying is the truth and try to
> : make it hang off the pci device.
> 
> Yes.  I'm sorry if I'm sounding grumpy about it :-).

	No at all, I like having your input and help. If you're ever
in Montreal, I'll bribe you with beer.

> : 	Does your gut say I can bus_bus_alloc_resource in the pci driver and do
> : port io given that I could from the isa driver?  Will it catch overlap
> : from the pci and isa busses?  (suppose I really had an isa pnp mpu
> : card and this pci card both wanting ports 0x300-0x302)
> 
> Yes.  You can do that.  In fact, most of the drivers in the tree have
> common 'resource allocation' routines.

	Ok, a quick and possibly unrelated question, I see the nexus
device, the root of all devices and busses, but what/where is the code
that defines the root0 device that I see from devinfo -u?

> 
> : 	I had a look at the netbsd code and they can say stuff like
> : this is a config file:
> : mpu at isa?
> : mpu at somesoundcard?
> : 	I hope my mpu code doesn't need to know about particular
> : soundcards, like
> : DRIVER_MODULE(mpu, snd_cmi,...)
> : DRIVER_MODULE(mpu, snd_visamstrcrd,...)
> 
> While you can do that, chances you'll want to do a mii-like bus to
> make this easier.
> 
> There are a couple of different ways to deal with doing these sorts of
> things.  I think the easiest follows after the mii model.
> 
> Network drivers with mii hardware attach an miibus child to them when
> they detect that their NIC has an mii attachment.  What mii is doesn't
> matter too much, but it is basically similar.  The sound cards would
> attach, in their attach routine, a sbbus (sbbus == soundblaster bus)
> child.  The sbbus would then have different children: mpu, joystick
> and maybe others that are common to all sbbus.  I think that the sbbus
> may need to have the sound card driver code enumerate these devices
> and assign their resources so that they can later attach.
> 
> This is, in some ways, similar to what you were doing with the 'reach
> around' attachment to the ISA bus.
> 
> I'd be happy to help you out a little with writing some sample code
> for you so that you can concentrate on the mpu devices and such if my
> description isn't clear or detailed enough to do this.

	Good description, sbbus -> lmmbus (legacy multimedia bus), but
I'm open to suggestions.  I plan to include mpu and joysticks.  

> 
> : 	Incidentally, what about vga and joysticks for that matter?
> : Not isa, but isa drivers.
> 
> vga is a very special case.  joysticks also are poorly handled in
> FreeBSD right now.
> 
> : > [...more snips...]
> : > You likely need to attach the mpu device to the pci soundcard in some
> : > way, or if the pci device has its own function, directly to the pci
> : > device.  Chances are excellent that's what the interrupt problem you
> : > are encountering are.
> : 
> : 	Not an interrupt problem.  Looking at code for other OSes, it
> : doesn't seem like anybody has interrupts for tx ready for mpu401s.
> 
> OK.
> 
> : 	I dug out my other soundcard and the older midi driver that I
> : did a few months ago and it now has the exact same problem of blasting
> : the stuff too fast.  I can only assume something has changed in the
> : synth timer code (unlikely), or the general freebsd timer code in last
> : few months.  
> 
> FreeBSD timer could would be my guess.  Maybe the defualt 'HZ' has
> changed?

	Argh, yes I changed the default HZ.  Really I have to work on
understanding the midi infrastructure better.
	Current road map (also increasing order of not happening):
	- kldunload'ing of midi
	- handle multiple midi devices without panic-ing
	- understand / fixing midi timing
	- snd_es137x midi working again (with joy on lmmbus)
	- generic mpu 401
	- get timidity to run off a pass-through midi dev
	- opl (anybody whos seen/heard of opl and has wants to
	  participate please stand up)
	
	I hope to be able to do all the code myself but expect me to
badger you in a week or so.  You've become my shepherd whether you like
or not :)

	Cheers and thanks,
	--Mat

-- 
Tactic: Are you a good user, or a bad user? (ReBoot)