lkml.org 
[lkml]   [2010]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses
    On Fri, Aug 20, 2010 at 12:51 PM, Kevin Hilman
    <khilman@deeprootsystems.com> wrote:
    > Grant Likely <grant.likely@secretlab.ca> writes:
    >
    > [...]
    >
    >>> One of the primary goals of this (at least for me and it seems Magnus also)
    >>> is to keep drivers ignorant of their bus type, and any bus-type-specific
    >>> code should be done in the bus_type implementation.
    >>
    >> Heh; which just screams to me that bus_type is the wrong level to be
    >> abstracting the behaviour
    >
    > Heh, now I feel like we're going around in circles.  Remember, I never
    > wanted to create add a new bus_type.  Someone else [ahem] suggested
    > doing the abstraction at the bus_type level.  ;)

    Hey! I didn't suggest it either! I believe that was Greg at ELC. I
    just... um... kind of took it and ran with it. :-)

    >> (but I also understand your need for the
    >> "omap_device" wrapper around platform_device which also requires some
    >> method to sort out when a platform_device really is an omap_device
    >> without an unsafe dereference).
    >
    > Yes, I'm working on the devres approach to that now, as is Magnus for
    > the sh-mobile version (proposed for .36-rc1[1])
    >
    >>> Both for SH and OMAP, we've been using the (admiteddly broken)
    >>> weak-symbol-override approach to getting a custom bus-type based on the
    >>> platform_bus.  We've been using that in OMAP for a while now and have
    >>> not seen any need to for the drivers to know if they are on the vanilla
    >>> platform_bus or the customized one.
    >>>
    >>> I'm very curious to hear what type of impact you expect to the drivers.
    >>
    >> 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.
    If the override (even when fixed to work at runtime) applies to every
    device on the platform_bus_type, then I'll nack it. My concern here
    is that the SoC or platform support code doesn't get to "own" the
    platform_bus_type. Other drivers/code can register their own set of
    platform_devices, which may also need to perform their own dev_pm_ops
    override. If the override is global to the platform_bus_type, then
    the model will not scale.

    Cheers,
    g.
    --
    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-20 22:11    [W:0.031 / U:0.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site