lkml.org 
[lkml]   [2013]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3] USB: PHY: Palmas USB Transceiver Driver
    On 03/26/2013 03:27 AM, Graeme Gregory wrote:
    ...
    > If we are tightly coupling as above then using platform_irq is an extra
    > inefficiency. You both have to populate this then parse it afterwards.
    > Why not just use the regmap helper? Ill admit this code is like this as
    > there was a period where platform irqs in DT just was not working right!
    >
    > We should really agree now if we are going for loose or tight coupling
    > now rather than keep switching?

    Yes, this is something that I think needs to be fully resolved before
    any more Palmas patches are discussed.

    So you can have the MFD components fully coupled or completely
    standalone. We should fully pick one or the other, not some mish-mash of
    the two.

    In practical terms, this means that:

    a) Tightly coupled

    The top-level MFD device knows exactly which child devices are present.
    It has an internal table to defined the set of child devices, and
    instantiate them. It provides them with IRQs, I2C addresses and register
    base addresses (or regmaps), etc. etc., using purely Palmas-internal
    APIs. If using device tree, the DT won't include any representation of
    which child devices are present, nor their I2C addresses, nor their
    register addresses, nor their IRQs, etc. That's all inside the driver.

    b) Completely decoupled.

    The top-level MFD device knows nothing about its children. It simply
    provides a bus into which they can be instantiated, and a generic IRQ
    controller into which they can hook.

    Platform data or device tree is solely used to define which children
    exist, which of the top-level MFD's I2C addresses is used for each
    child, the base register address for each child device, the IRQs used by
    each child device, etc.


    Which of those two models are different people expecting?

    (b) appears to be the most flexible, and since you have defined the DT
    bindings to contain a separate node for each MFD child device, each with
    its own compatible value, seems to be what you're aiming for. In this
    scenario, there should be no private APIs between the top-level MFD
    device and the children though; everything should be using standard bus
    APIs.


    \
     
     \ /
      Last update: 2013-03-27 04:01    [W:4.116 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site