* Felipe Contreras <[email protected]> [100519 02:58]: > On Tue, May 18, 2010 at 10:58 PM, Hiroshi DOYU <[email protected]> wrote: > > From: ext Felipe Contreras <[email protected]> > > Subject: Re: [PATCH v2 00/17] omap: mailbox: reorganize init > > Date: Tue, 18 May 2010 18:57:55 +0200 > > > >> On Tue, May 18, 2010 at 4:31 PM, Hiroshi DOYU <[email protected]> > >> wrote: > >>> From: ext Felipe Contreras <[email protected]> > >>>> I'm not familiar with this kind of module loading, but certainly not > >>>> all systems have udev. > >>>> > >>>> I realized the problem because I have a bare-bones system in my > >>>> beagleboard where I had to manually load mailbox_mach. > >>> > >>> With udev or something equivalent, it should work fine. > >> > >> But still, you are relying on udev. I don't think we should, and I > >> don't think there's any need. > > > > Some expert may give some comment here..... > > Russell, Tony: should mailbox_mach, a module that checks for logical > devices be always built-in? > > I think that's the easiest... in my patches I moved the > architecture-specific code from mach-omapX/devices.c to > mach-omapX/mailbox.c, so both the logical devices and real platform > devices are in the same code, and can be built-in. > > This way, there's no need to rely on services like udev to load > mailbox, then mailbox_mach, then bridgedriver. After all, all > mailbox_mach is doing is calling functions in mailbox to register the > logical devices. > > Judging from: > http://article.gmane.org/gmane.linux.ports.arm.kernel/58555 > > The answer is yes.
Maybe try using the tested good old criteria: What works the best for "standard Linux behaviour" out of the box? :) Anything that registers platform devices should be built in. Also anything that's needed to boot the device into a sane operating mode should be built in. For example, the DSP should be powered down (or idled on some earlier omaps) even if no bridge is being used. Cheers, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
