Re: [PATCH 20/21] ASoC: codecs: Enable AB8500 CODEC for Device Tree

[Lee Jones]

On 26/07/12 15:43, Mark Brown wrote:
> On Thu, Jul 26, 2012 at 03:15:01PM +0100, Lee Jones wrote:
> > Sorry missed this:
>
> > > Why are we doing this?  The MFD cells are a totally Linux specific
> > > thing, there's no reason to represent them in the device tree unless
> > > they're in some way reusable and the "ab8500-codec" name suggests that's
> > > unlikely.  Just put the properties on the parent node and instantiate
> > > the MFD cell as normal.
>
> > We have all of the AB8500 devices into the Device Tree to accurately
> > represent the hardware. We will also be passing configuration
> > information into the AB8500 Codec from Device Tree. The only reason
> > we're still registering them using the MFD API is to overcome
> > addressing issues encountered earlier. Each 'device' still belongs
> > in the 'device' tree.
>
> The device here is the AB8500.  The fact that Linux chooses to represent
> it as an MFD with a particular set of subdrivers is a Linux specific
> decision and may well change over time.  For example it's likely that
> we'll want to migrate the clocks out of the audio driver and into the
> clock API when that becomes useful.  Similarly currently a lot of these
> devices use ASoC level jack detection but that's going to move over to
> extcon over time.
>
> There's no way you're going to be able to reuse this for anything that
> isn't an AB8500, there's no abstraction of the SoC integration here.  If
> you had clearly identifiable, repeatable IPs which you could reasonably
> bind to a different bit of silicon then that'd be different but there's
> nothing like that here.  We already know that the functionality covered
> by the driver is going to be present simply by virtue of knowing that
> there's an AB8500 and similarly there's no real way this driver could
> ever be used without the core driver.  All the "device" in the device
> tree is doing is serving as a container to place some of the DT
> properties into, this needs to be separated out from the instantiation
> of the Linux device driver.  There's nothing stopping the driver from
> looking at the OF node of its parent here.
>
> The goal here isn't just to copy the Linux device model and platform
> data into device tree bindings, the device tree bindings need to think
> about what the chip actually is so they can be reused by other OSs and
> by future versions of Linux.
>
> > If we were to take this Device Tree and use it on something
> > non-Linux, that OS will still need to know about each of the AB8500
> > devices and every associated configuration option. Only in Linux do
> > we continue to register them though a different API, which doesn't
> > affect any other OS.
>
> Another OS might have a different idea about how it's going to split up
> the chip which better fits with the models which that OS has for the
> functions present on the device.  The reason this is a distinct device
> in Linux is all to do with how Linux models the hardware.

Okay, so your suggestion is to strip out all of the sub-devices under 
the AB8500. It's doable, but will take some restructuring and thinking 
about. This is a job for another day. I think it's okay to continue with 
the current semantics for the time-being. The line we're discussing does 
need to be split out though. I didn't mean to merge it in with the ASoC 
stuff.

--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org â Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/