From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <9e4733910711181349q1f840bc2w8d30bb33d2a353ce@mail.gmail.com> Date: Sun, 18 Nov 2007 16:49:33 -0500 From: "Jon Smirl" To: "Segher Boessenkool" Subject: Re: Revisited, audio codec device tree entries. In-Reply-To: <0fd3304ee694b2dc6a8f3055c08dc015@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <9e4733910711181010q50c08d2ek8413af74d58cf0ce@mail.gmail.com> <0fd3304ee694b2dc6a8f3055c08dc015@kernel.crashing.org> Cc: PowerPC dev list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 11/18/07, Segher Boessenkool wrote: > > David Gibson > > made a proposal that a fabric node wrap the codec node. That doesn't > > work very well with the i2c bus where the bus code is walking down the > > nodes and triggering the instantiation of the i2c drivers. > > Yeah, doesn't work at all. > > > But what about putting the fabric node inside the codec node? > > _Which_ codec node? Having more than one isn't uncommon at all. In all of them. Fabric can probably be split into pieces that corresponds to the codec. > There is no way you can describe this fabric stuff in a generic way in > the device tree. Just hardcode it in your platform support code; if > the platform code supports several variant boards, _it_ can probe that > from the device tree (in whatever way works for that platform). The codec-fabric node was just being used to trigger the loading of the platform specific driver. > > > Segher > > -- Jon Smirl jonsmirl@gmail.com