To be used for reference in the design discussion related to RPM driver implementation for family A. Regulator driver is a not even close to the shape it should be, but shows a user of the api. Instead of having every regulator exposed as it's own compatible, I would now have it take a resource id as reg and just be compatible with the specific resource consumer. The difference with Josh's proposal is the mapping table in msm_rpm.c, that makes the rpm driver expose logical resources and therefor hides the details of the rpm communication from its clients. This gives, in my mind, a cleaner abstraction and api. Bjorn Andersson (2): mfd: msm_rpm: Initial driver for the Qualcomm RPM regulator: msm_rpm: Initial regulator driver for Qualcomm RPM drivers/mfd/Kconfig | 7 + drivers/mfd/Makefile | 1 + drivers/mfd/msm_rpm-8064.h | 420 +++++++++++++++++++++++++++ drivers/mfd/msm_rpm-8960.h | 400 ++++++++++++++++++++++++++ drivers/mfd/msm_rpm.c | 525 ++++++++++++++++++++++++++++++++++ drivers/regulator/Kconfig | 7 + drivers/regulator/Makefile | 1 + drivers/regulator/msm_rpm-regulator.c | 467 ++++++++++++++++++++++++++++++ include/linux/mfd/msm_rpm.h | 87 ++++++ 9 files changed, 1915 insertions(+) create mode 100644 drivers/mfd/msm_rpm-8064.h create mode 100644 drivers/mfd/msm_rpm-8960.h create mode 100644 drivers/mfd/msm_rpm.c create mode 100644 drivers/regulator/msm_rpm-regulator.c create mode 100644 include/linux/mfd/msm_rpm.h -- 1.8.2.2 -- 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
