lkml.org 
[lkml]   [2012]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 20/21] ASoC: codecs: Enable AB8500 CODEC for Device Tree
    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.
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2012-07-26 17:21    [W:6.577 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site