Menu
▾
▴
linuxdc-dev
|
From: Adrian M. <ad...@mc...> - 2002-02-03 00:25:11
|
What are the circumstances under which the 'connect' function for a maple client device will be called? I am building an experimental driver - as a module - for the microphone and while clearly the init and exit functions are being called and the maple core correctly reports the loading of a microphone driver, connect doesn't seem to get called. Is this correct behaviour? Adrian |
|
From: M. R. B. <mr...@0x...> - 2002-02-03 00:39:01
|
* Adrian McMenamin <ad...@mc...> on Sun, Feb 03, 2002:
> What are the circumstances under which the 'connect' function for a maple=
=20
> client device will be called?
>=20
> I am building an experimental driver - as a module - for the microphone a=
nd=20
> while clearly the init and exit functions are being called and the maple =
core=20
> correctly reports the loading of a microphone driver, connect doesn't see=
m to=20
> get called.
>=20
Did you register your driver with maple? Your init() routine should have a
call to maple_register_driver() with a pointer to the statically allocated
maple_driver structure in your source. Are you sure this is being setup
correctly?
static struct maple_driver microphone_driver =3D {
function: MAPLE_FUNC_MICROPHONE,
name: "Microphone",
connect: my_microphone_connect,
disconnect: my_microphone_disconnect,
};
M. R.
|
|
From: Adrian M. <ad...@mc...> - 2002-02-03 00:43:05
|
On Sunday 03 Feb 2002 12:38 am, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Sun, Feb 03, 2002:
> > What are the circumstances under which the 'connect' function for a maple
> > client device will be called?
> >
> > I am building an experimental driver - as a module - for the microphone
> > and while clearly the init and exit functions are being called and the
> > maple core correctly reports the loading of a microphone driver, connect
> > doesn't seem to get called.
>
> Did you register your driver with maple? Your init() routine should have a
> call to maple_register_driver() with a pointer to the statically allocated
> maple_driver structure in your source. Are you sure this is being setup
> correctly?
>
> static struct maple_driver microphone_driver = {
> function: MAPLE_FUNC_MICROPHONE,
> name: "Microphone",
> connect: my_microphone_connect,
> disconnect: my_microphone_disconnect,
> };
>
> M. R.
I think I am - unless you can spot an error here - is this a modularisation
problem - ie this can't be done as a module?
static struct maple_driver dc_microphone_driver = {
function: MAPLE_FUNC_MICROPHONE,
name: "Dreamcast microphone",
connect: dc_microphone_connect,
disconnect: dc_microphone_disconnect,
reply: dc_microphone_callback,
vblank: maple_getcond_vblank_callback,
};
static int __init dc_microphone_init(void)
{
maple_register_driver(&dc_microphone_driver);
return 0;
}
static void __exit dc_microphone_exit(void)
{
maple_unregister_driver(&dc_microphone_driver);
if (unload_microphone()){
DEBGM("Maple: Microphone did not unload cleanly\n");
}
}
|
|
From: M. R. B. <mr...@0x...> - 2002-02-03 00:48:47
|
* Adrian McMenamin <ad...@mc...> on Sun, Feb 03, 2002: >=20 > I think I am - unless you can spot an error here - is this a modularisati= on=20 > problem - ie this can't be done as a module? >=20 Yeah, Maple is *completely* broken as modules. I haven't investigated why since Paul was planning an eventual rewrite of the core. It's always been broken in module form. M. R. |
|
From: Fredrik H. <hu...@hu...> - 2002-02-03 02:36:11
|
"M. R. Brown" <mr...@0x...> writes:
> * Adrian McMenamin <ad...@mc...> on Sun, Feb 03, 2002:
>
> >
> > I think I am - unless you can spot an error here - is this a modularisation
> > problem - ie this can't be done as a module?
> >
>
> Yeah, Maple is *completely* broken as modules. I haven't investigated why
> since Paul was planning an eventual rewrite of the core.
>
> It's always been broken in module form.
>
> M. R.
I think I see the modulariisation problem...
Have you tried connecting the microphone to the DC *after* having loaded
the module? I think that will work. (Let me know)
I haven't had time to work on the maple stuff for a little while, but
if the problem is what I think it is it should be fairly easy to fix.
/Hubbe
|
|
From: M. R. B. <mr...@0x...> - 2002-02-03 02:52:48
|
* Fredrik Hubinette <hu...@hu...> on Sat, Feb 02, 2002: >=20 > Have you tried connecting the microphone to the DC *after* having loaded > the module? I think that will work. (Let me know) >=20 Have you been able to detect any other Maple devices after the corresponding module has been loaded? I haven't. No device detection occu= rs whatsoever when Maple is built as modules. Even when the core of Maple itself (maplebus.o) is built into the kernel, it still doesn't work. Maybe this is a good time to start discussing the new core, or what should become of the new core? M. R. |
|
From: Fredrik H. <hu...@hu...> - 2002-02-03 05:49:15
|
"M. R. Brown" <mr...@0x...> writes:
> * Fredrik Hubinette <hu...@hu...> on Sat, Feb 02, 2002:
>
> >
> > Have you tried connecting the microphone to the DC *after* having loaded
> > the module? I think that will work. (Let me know)
> >
>
> Have you been able to detect any other Maple devices after the
> corresponding module has been loaded? I haven't. No device detection occurs
> whatsoever when Maple is built as modules. Even when the core of Maple
> itself (maplebus.o) is built into the kernel, it still doesn't work.
I never tried to compile any maple stuff as modules before today.
I tried compiling maple itself as a module, which gives me an unresolved
symbol '__flush_purge_region' when I try to load it.
However, if I comple maple.c into the kernel and leave the individual
drivers as modules, modprobe the drivers and then connect a device to
the dreamcast everything works as normal.
I'm going to write a little code that connects drivers to devices when
modules are added so that no disconnection will be needed, but I don't
know how to fix the unresolved symbol problem.
Also, I suppose some code that auto-loads the driver modules would
be nice, but I don't know how to do that either. (yet)
/Hubbe
|
|
From: Fredrik H. <hu...@hu...> - 2002-02-03 07:59:40
|
Fredrik Hubinette <hu...@hu...> writes:
> I'm going to write a little code that connects drivers to devices when
> modules are added so that no disconnection will be needed, but I don't
> know how to fix the unresolved symbol problem.
Ok, I commited some patches to maple.c which attach drivers to units
whenever they are loaded. Maple itself still can't be compiled as
a module because of the unresolved symbol, but at least maple module
development should be smoother now.
/Hubbe
|
|
From: Adrian M. <ad...@mc...> - 2002-02-03 13:13:26
|
On Sunday 03 Feb 2002 7:59 am, Fredrik Hubinette wrote: > Fredrik Hubinette <hu...@hu...> writes: > > I'm going to write a little code that connects drivers to devices when > > modules are added so that no disconnection will be needed, but I don't > > know how to fix the unresolved symbol problem. > > Ok, I commited some patches to maple.c which attach drivers to units > whenever they are loaded. Maple itself still can't be compiled as > a module because of the unresolved symbol, but at least maple module > development should be smoother now. > > /Hubbe This appears to work fine for my microphone 'driver'. Thanks for that |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X