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    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site