On Fri, Aug 20, 2010 at 12:51 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > Grant Likely <grant.likely@xxxxxxxxxxxx> 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-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
