lkml.org 
[lkml]   [2010]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses
    Date
    Grant Likely <grant.likely@secretlab.ca> writes:

    [...]

    >>>
    >>> My fears on this point may very well be unfounded.  This isn't the
    >>> hill I'm going to die on either.  Show me an implementation of driver
    >>> sharing that is clean and prove me wrong!  :-)
    >>
    >> IMHO, simply overriding the few dev_pm_ops methods was the cleanest and
    >> simplest.
    >>
    >> Since we seem to be in agreement now that the a new bus may not the
    >> right abstraction for this (since we want it to be completely
    >> transparent to the drivers), I'll go back to the original design.  No new
    >> bus types, keep the platform_bus as is, but simply override the few
    >> dev_pm_ops methods I care about.  This is what is done on SH,
    >> SH-Mobile[1] and my original version for OMAP that started this
    >> conversation.
    >>
    >> Yes, the weak-symbol method of overriding is not scalable, but that's a
    >> separate issue from whether or not to create a new bus.  I have a
    >> proposed fix for the weak which I'll post shortly.
    >
    > Okay.
    >
    > One constraint remains though: If you can override the dev_pm_ops on
    > a per-device or per-device-parent basis, then you've got my support.

    hmm, a new requirement?, and one that would require some significant
    changes to the driver model.

    Currently, dev_pm_ops for a bus applies globally to *all* devices on
    that bus (or class or type) and changing that would require changing the
    platform_bus code to start having per-device (or per-parent-device)
    checks.

    > If the override (even when fixed to work at runtime) applies to every
    > device on the platform_bus_type, then I'll nack it.

    /me can't help but wonder why the OMAP implementation is getting all the
    negative attention while the other identical implementations are already
    upstream.

    > My concern here is that the SoC or platform support code doesn't get
    > to "own" the platform_bus_type.

    Well, I'm not proposing that here. This "feature" already exists in
    mainline (albeit using the less-than-optimal weak symbol approach.) All
    I'm proposing is fixing it to make it multi-arch friendly.

    If you think this behavior should be changed to non global, that should
    be done a separate series since it is not directly related to runtime PM
    support for a given platform, IMO.

    > Other drivers/code can register their own set of
    > platform_devices, which may also need to perform their own dev_pm_ops
    > override.

    IMHO, we should deal with such hypothetical, future problems *if* they
    arise down the road.

    > If the override is global to the platform_bus_type, then the model
    > will not scale.

    It will not scale any more (or less) than the current functionality of
    the driver model which handles this globally. Again, if scalabilty
    becomes a problem down the road, lets fix it then.

    Kevin
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-08-21 02:13    [W:0.028 / U:0.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site