Kumar Gala <galak@xxxxxxxxxxxxxx> writes: > On Jun 18, 2014, at 10:53 AM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: > >> Bjorn Andersson <bjorn@xxxxxxx> writes: >> >>> On Tue, Jun 17, 2014 at 10:07 AM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >>>> +Paul Walmsley >>>> >>>> Bjorn Andersson <bjorn.andersson@xxxxxxxxxxxxxx> writes: >>>> >>>>> This series adds a regulator driver for the Resource Power Manager found in >>>>> Qualcomm 8660, 8960 and 8064 based devices. >>>>> >>>>> The RPM driver exposes resources to its child devices, that can be accessed to >>>>> implement drivers for the regulators, clocks and bus frequency control that's >>>>> owned by the RPM in these devices. >>>>> >>>>> Changes since v2: >>>>> - Fix copy-paste error in dt binding >>>>> - Correct incomplete move from mfd to soc >>>>> - Correct const mistake in regulator driver >>>>> >>>>> Changes since v1: >>>>> - Moved rpm driver to drivers/soc >>>> >>>> I'm not sure I follow the motivation for having this under drivers/soc? >>>> >>> Hi Kevin, >>> >>> I've made the argument that to me this is conceptually a black box >>> handling regulators, clocks and other stuff; hence similar to a PMIC, >>> which would fit nicely into drivers/mfd. >>> >>> I still think this is the case and now that I look back I didn't get >>> any pushback from Lee Jones so maybe the move was premature? >> >> Yes, IMO, the move was premature, but hopefully the drivers/soc folks >> can chime in an clarify the criteria for inclusion there. >> >> Kevin > > I dont agree, I think having this in drivers/soc means that we can > clearly go through drivers/soc in the future and look for patterns > across SoCs that should be re-factored. I don't believe that was the goal in creating drivers/soc. > Where MFD seems like its become the new drivers misc. Well, I don't think that drivers/soc wants to be the new drivers/misc either. ;) Thinking more about what this RPM driver actually does, and since you mentioned patterns across SoCs, it seems to me the RPM driver bascially just doing the IPC. So, rather than MFD or drivers/soc, it seems to me that it should be implmented as a controller in the new common mailbox framwork[1] being worked on by Jassi Brar (added to Cc.) IIUC, RPM is actually only doing one-way IPC (it only exposes a write() interface to clients) so it seems like a rather simple implementation of a mailbox controller. I believe Bjorn is already on the list of folks Cc'd on the common mailbox framework, so it would be good to hear from him why RPM wouldn't fit under that framework. Thanks, Kevin [1] https://lkml.org/lkml/2014/6/12/470 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
