On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote: > Heh, I'm one of the folks who objected to it; here's what was written: > > > > > > > > > [EMAIL PROTECTED] { // use to trigger loading platform specific fabric > > > > driver > > > > device_type = "pseudo-sound" > > > > }; > > > > > > I don't think this is a good idea. The device tree is for describing > > > your hardware; so the layout should reflect that. Make the platform > > > code do the right thing with the real nodes. > > What I objected to was that the pseudo-sound node didn't contain any > real information. It was just being a hook to trigger calling a probe > function. If you're going to do that then you might as well just call > it directly from platform code.
Calling it directly from the platform code is an option, but where does the fabric driver code live? It doesn't make a lot of sense to put ALSA code into arch/powerpc/platforms/52xx. I could make a function call from arch/powerpc/platforms/52xx over to sound/soc/powerpc but that's not very pretty. Another option is to make the fabric driver a "struct platform_driver" instead of a "struct of_platform_driver". "struct platform_driver" is not being probed in the current mpc5200 code. This option makes senses to me, "struct platform_driver" will load without a device tree node. The driver will still need to check and see if it is on the right platform when more than one is compiled in. > > > > For example: > > > [EMAIL PROTECTED] { > > > compatible = "<mfg>,<board>,sound" // The board might have > > > more than one sound i/f which could be wired differently > > > codec-handle = <&codec0>; > > > }; > > The difference here is that the node provides real information about > the board. It has a compatible field which tells you *exactly* what > sound circuit is present on the board. It can have additional > information that does make sense to encode into the device tree (ie. > the codec that is used). It's not addressable (no registers or > anything), but it does describe the board. > > It would be possible and reasonable for a single fabric driver to work > with many different circuit layouts as long as it has the information > needed to adapt each instance. That is how the Apple driver is implemented. There is a single fabric driver that uses layout-id to set everything up to match the physical PCB. sound/aoa/fabrics/snd-aoa-fabric-layout.c But Apple put the layout id down inside the a sound node: /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/sound: name "sound" device_type "soundchip" compatible "AOAbase" built-in layout-id 00000046 (70) object-model-version 00000002 vendor-id 0000106b (4203) platform-tas-codec-ref ff98cba8 linux,phandle ff985d48 > > > > > Do you even need the parameters, how about simply this? > > > > sound-fabric { > > }; > > But this goes back to having nodes that don't provide any information. > You don't want that. > > > > > That will trigger loading all of the sound-fabric drivers built into > > the kernel. In their probe functions they can look in the device tree > > and extract the machine name and then decide to stay loaded or fail > > the probe. > > > > ... > > Now is probably a good time to mention that there is *nothing* in the > device tree that enforces a 1:1 relationship between device tree nodes > and driver instances. Sure, it make sense to register the i2s and > codec drivers from probing on the i2s and codec nodes. However, there > is nothing that prevents the codec driver from *also* registering a > fabric driver based on a property in the codec node or the board-level > compatible property. But there is something in the kernel that enforces it. I haven't checked the powerpc code, but the PCI code won't probe anymore drivers once one has attached to a device. The rule of one driver per device is a good one. Places where that rule has been broken have caused a lot of problems (fbdev vs DRM). > Fabric drivers are codec specific anyway. It's not all that > unrealistic for the device tree binding for a codec to have a list of > fabric drivers that it can register. The codec drivers in asoc are completely agnostic. The same codec driver works on x86, arm, powerpc, etc. > > Cheers, > g. > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > [EMAIL PROTECTED] > (403) 399-0195 > -- Jon Smirl [EMAIL PROTECTED] _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev