All of lore.kernel.org
 help / color / mirror / Atom feed
* Using specific code for midi/gameport instead of generic one.
@ 2005-02-04 19:37 matthieu castet
  2005-02-07  9:35 ` Clemens Ladisch
  0 siblings, 1 reply; 5+ messages in thread
From: matthieu castet @ 2005-02-04 19:37 UTC (permalink / raw)
  To: alsa-devel

Hi,

what's the advantage of using specific code (via82xx.c for example) for 
managing midi/gameport instead of the generic module mpu401 and ns558 ?

These modules should be able to use pnp layer, so they should be able to 
know/change the io ports in use without writing directly in LPC pci device.

regards,

Matthieu CASTET


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Using specific code for midi/gameport instead of generic one.
  2005-02-04 19:37 Using specific code for midi/gameport instead of generic one matthieu castet
@ 2005-02-07  9:35 ` Clemens Ladisch
  2005-02-07 12:19   ` matthieu castet
  0 siblings, 1 reply; 5+ messages in thread
From: Clemens Ladisch @ 2005-02-07  9:35 UTC (permalink / raw)
  To: matthieu castet; +Cc: alsa-devel

matthieu castet wrote:
> what's the advantage of using specific code (via82xx.c for example) for
> managing midi/gameport instead of the generic module mpu401 and ns558 ?

The MPU-401 code in via82xx.c is used only for VT82C686 chips where
the MIDI port shares an interrupt with the AC'97 controller.

There is no reason for the gameport code, except that it would work
even if PnP happens to be disabled.

> These modules should be able to use pnp layer, so they should be able to
> know/change the io ports in use without writing directly in LPC pci device.

There is no driver that changes I/O ports by writing to the LPC bridge
device.  This wouldn't work anyway because the driver wouldn't know
how to reconfigure the SuperIO chip behind the bridge.


Best regards,
Clemens



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Using specific code for midi/gameport instead of generic one.
  2005-02-07  9:35 ` Clemens Ladisch
@ 2005-02-07 12:19   ` matthieu castet
  2005-02-07 15:40     ` Clemens Ladisch
  0 siblings, 1 reply; 5+ messages in thread
From: matthieu castet @ 2005-02-07 12:19 UTC (permalink / raw)
  To: Clemens Ladisch; +Cc: alsa-devel

Hi,

Clemens Ladisch wrote:
> matthieu castet wrote:
> 
>>what's the advantage of using specific code (via82xx.c for example) for
>>managing midi/gameport instead of the generic module mpu401 and ns558 ?
> 
> 
> The MPU-401 code in via82xx.c is used only for VT82C686 chips where
> the MIDI port shares an interrupt with the AC'97 controller.
> 
Ok, I haven't see that via is different from the removed midi code from 
intel ac 97, because it is only for VT82C686 and the midi port is on the 
pci device.
Anyway, we should check if the midi device is found by pnp for these 
chips. If it is the case, what happen if mpu401 module is load before 
the via module ?

> There is no reason for the gameport code, except that it would work
> even if PnP happens to be disabled.
> 
ns558 work even if the PnP is disable : it will try to see if there is 
something on the following ports [1]. And 0x200 is the port harcoded in 
the via driver, so it should detect it. But perhaps VIA_FUNC_ENABLE_GAME 
will be missing...

Thanks,

Matthieu

[1]
static int ns558_isa_portlist[] = { 0x201, 0x200, 0x202, 0x203, 0x204, 
0x205, 0x207, 0x209,
                                     0x20b, 0x20c, 0x20e, 0x20f, 0x211, 
0x219, 0x101, 0 };



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Using specific code for midi/gameport instead of generic one.
  2005-02-07 12:19   ` matthieu castet
@ 2005-02-07 15:40     ` Clemens Ladisch
  2005-02-09 14:17       ` matthieu castet
  0 siblings, 1 reply; 5+ messages in thread
From: Clemens Ladisch @ 2005-02-07 15:40 UTC (permalink / raw)
  To: matthieu castet; +Cc: alsa-devel

matthieu castet wrote:
> Anyway, we should check if the midi device is found by pnp for these
> chips. If it is the case, what happen if mpu401 module is load before
> the via module ?

The I/O ports and the interrupt would already have been taken by the
mpu401 module.  However, the MPU-401 interrupt is usually assumed to
be an unsharable ISA interrupt, so this would prevent the AC'97
controller driver from being loaded.

Are there really any VT686 boards that have PnP information for the
MPU-401?

> Clemens Ladisch wrote:
> > There is no reason for the gameport code, except that it would work
> > even if PnP happens to be disabled.
> >
> ns558 work even if the PnP is disable : it will try to see if there is
> something on the following ports [1]. And 0x200 is the port harcoded in
> the via driver, so it should detect it.

Then there is indeed no reason.

> But perhaps VIA_FUNC_ENABLE_GAME will be missing...

In that case, the user has disabled the gameport in the BIOS setup.



Best regards,
Clemens



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Using specific code for midi/gameport instead of generic one.
  2005-02-07 15:40     ` Clemens Ladisch
@ 2005-02-09 14:17       ` matthieu castet
  0 siblings, 0 replies; 5+ messages in thread
From: matthieu castet @ 2005-02-09 14:17 UTC (permalink / raw)
  To: Clemens Ladisch; +Cc: alsa-devel

Hi,

Clemens Ladisch wrote:
> matthieu castet wrote:
> 
>>Anyway, we should check if the midi device is found by pnp for these
>>chips. If it is the case, what happen if mpu401 module is load before
>>the via module ?
> 
> 
> The I/O ports and the interrupt would already have been taken by the
> mpu401 module.  However, the MPU-401 interrupt is usually assumed to
> be an unsharable ISA interrupt, so this would prevent the AC'97
> controller driver from being loaded.
> 
> Are there really any VT686 boards that have PnP information for the
> MPU-401?

I don't know...

Matthieu



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2005-02-09 14:17 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-02-04 19:37 Using specific code for midi/gameport instead of generic one matthieu castet
2005-02-07  9:35 ` Clemens Ladisch
2005-02-07 12:19   ` matthieu castet
2005-02-07 15:40     ` Clemens Ladisch
2005-02-09 14:17       ` matthieu castet

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.