Thread (46 messages) flat view 46 messages, 7 authors, 2008-07-18

Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers

From: Mark Brown <hidden>
Date: 2008-07-15 14:04:42
Also in: alsa-devel

On Tue, Jul 15, 2008 at 09:08:28AM -0400, Jon Smirl wrote:
On 7/15/08, Mark Brown [off-list ref] wrote:
quoted
Binding isn't the issue here - it's loading the driver in the first
 place.  Once the drivers are loaded they can (hopefully) figure out if
 they are running on appropriate hardware.
In this case we would end up with two core PowerPC machine drivers
bound, not ALSA ones. We have machine drivers in the PowerPC core,
that's one reason why it is confusing to call the ALSA drivers machine
drivers too.
Again, I'm not talking about binding anything.
quoted
This is what I'm suggesting, modulo the fact that I'm suggesting *not*
 creating virtual devices but rather providing a mechanism for drivers to
 load without binding to anything.  It strikes me that you're going to
If you have drivers for four different hardware releases compiled into
your kernel, the only kernel mechanism I know of  to trigger only one
of these to initialize is to create a device and then let the probe
mechanism sort it out. This is even more true when the drivers are on
initrd and need to be dynamically loaded. The module load code will
search through the alias lists in the module .ko files.
This can be handled in the module initialisation (rather than driver
probe) - providing something can arrange for the driver to get loaded
then the drivers can check the system they're running on when that
happens and fail if it's inappropriate.  The ARM ASoC drivers and x86
DMI based stuff do things this way, for example (ARM doesn't have the
automatic module load stuff implemented, though).

The infrastructure for automatically loading modules is usable
separately from device registration, though normally the two do go hand
in hand.
It has been pointed out that a lite5200b-fabric device isn't really a
virtual devices. It's a device that represents the traces on the PCB
wiring the generic chip drivers together.
This was brought up very early on when you guys first started working on
it. :/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help