Re: [PATCH 02/12] drivers: mfd: Add support for Exynos PMU driver
On 04/11/14 04:18, Pankaj Dubey wrote: 2: Since PM domain relies on PMU registers and does not have its own DT binding, MFD client and MFD device is most suitable for making this kind of platform drivers. We have DT binding for the Exynos power domains: Documentation/devicetree/bindings/arm/exynos/power_domain.txt In fact the IO memory regions used in the power domain bindings fall within the (sparse) PMU registers region. There is also DT binding for the PMU subsystem: Documentation/devicetree/bindings/arm/samsung/pmu.txt I guess a platform device driver in drivers/power would be a better fit than drivers/mfd. I doubt introducing an mfd driver now makes much sense, we have already DT bindings for PHYs, the power domains, etc. -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/12] drivers: mfd: Add support for Exynos PMU driver
On Wednesday, November 05, 2014 7:18 PM, Sylwester Nawrocki wrote: On 04/11/14 04:18, Pankaj Dubey wrote: 2: Since PM domain relies on PMU registers and does not have its own DT binding, MFD client and MFD device is most suitable for making this kind of platform drivers. We have DT binding for the Exynos power domains: Documentation/devicetree/bindings/arm/exynos/power_domain.txt In fact the IO memory regions used in the power domain bindings fall within the (sparse) PMU registers region. Correct. But currently there is no platform driver for those DT bindings so we have two options: 1) Register a new platform driver for each of those DT nodes, which are using a very small subset of PMU register region. And we end up getting platform driver's probe for each pd nodes. 2) Register an Exynos power domain driver which will be a client driver of main Exynos PMU driver, and will get platform data from it. And in this probe parse all pd device nodes and populate all related information from those nodes into Exynos_pm_domain struct instances and keep list of these instances. Same has been proposed in Amit's patch. I would prefer second method, as next, we can move pm sleep functionality (which also uses PMU register sets) also into such small mfd client driver. And as far as I know for pm sleep currently there is no DT nodes. There is also DT binding for the PMU subsystem: Documentation/devicetree/bindings/arm/samsung/pmu.txt Yes, and currently I have used same binding to convert PMU implementation into a platform driver [1]. Now what we trying to address is same PMU implementation can be reused for ARM64 based SoC if we have to move it into drivers/mfd/ or drivers/power/ or may be drivers/soc. [1]: http://www.spinics.net/lists/linux-samsung-soc/msg37572.html Currently we moved into drivers/mfd and patches from Amit shows an use case where power domain implementation has been converted into platform driver, but its probe will be called by MFD subsystem and will not be bind to DT nodes of pd as it will be a client device to main PMU device. Please check this [2], [3]. [2]: http://www.spinics.net/lists/linux-samsung-soc/msg38446.html [3]: http://www.spinics.net/lists/linux-samsung-soc/msg38447.html I guess a platform device driver in drivers/power would be a better fit than drivers/mfd. I doubt introducing an mfd driver now makes much sense, we have already DT bindings for PHYs, the power domains, etc. The reason behind making it a mfd driver is, to make following design for pm domain and pm sleep functionality. -- | Exynos - PMU | | MFD device | | drivers/mfd/ | | --- | | --- | Exynos -pd | | Exynos - pm-sleep | | PMU's client device| | PMU's client device | | (drivers/soc/samsung/) | | (drivers/soc/samsung/) | - As Lee mentioned MFD can be used to register the device ( I am assuming he is referring to use of mfd_add_devices from Exynos -PMU driver, to make it a mfd device) but it should be kept outside of drivers/mfd. I just looked for current users of mfd_add_devices but only drivers from drivers/mfd only are calling this API, also once we call this API it will become an MFD device then why not keep into drivers/mfd or maybe I have little understanding of purpose of drivers/mfd. But still if it's OK to register Exynos -PMU as MFD device even if it's not in drivers/mfd folder, then I would suggest better to keep it in drivers/soc/samsung/ as it's very much SoC specific. As drivers/power looks like place to keep external power supply drivers such as batteries, AC, USB etc. Thanks, Pankaj Dubey -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/12] drivers: mfd: Add support for Exynos PMU driver
On Thu, Nov 6, 2014 at 11:18 AM, Pankaj Dubey pankaj.du...@samsung.com wrote: On Wednesday, November 05, 2014 7:18 PM, Sylwester Nawrocki wrote: On 04/11/14 04:18, Pankaj Dubey wrote: 2: Since PM domain relies on PMU registers and does not have its own DT binding, MFD client and MFD device is most suitable for making this kind of platform drivers. We have DT binding for the Exynos power domains: Documentation/devicetree/bindings/arm/exynos/power_domain.txt In fact the IO memory regions used in the power domain bindings fall within the (sparse) PMU registers region. Correct. But currently there is no platform driver for those DT bindings so we have two options: 1) Register a new platform driver for each of those DT nodes, which are using a very small subset of PMU register region. And we end up getting platform driver's probe for each pd nodes. 2) Register an Exynos power domain driver which will be a client driver of main Exynos PMU driver, and will get platform data from it. And in this probe parse all pd device nodes and populate all related information from those nodes into Exynos_pm_domain struct instances and keep list of these instances. Same has been proposed in Amit's patch. I would prefer second method, as next, we can move pm sleep functionality (which also uses PMU register sets) also into such small mfd client driver. And as far as I know for pm sleep currently there is no DT nodes. There is also DT binding for the PMU subsystem: Documentation/devicetree/bindings/arm/samsung/pmu.txt Yes, and currently I have used same binding to convert PMU implementation into a platform driver [1]. Now what we trying to address is same PMU implementation can be reused for ARM64 based SoC if we have to move it into drivers/mfd/ or drivers/power/ or may be drivers/soc. [1]: http://www.spinics.net/lists/linux-samsung-soc/msg37572.html Currently we moved into drivers/mfd and patches from Amit shows an use case where power domain implementation has been converted into platform driver, but its probe will be called by MFD subsystem and will not be bind to DT nodes of pd as it will be a client device to main PMU device. Please check this [2], [3]. [2]: http://www.spinics.net/lists/linux-samsung-soc/msg38446.html [3]: http://www.spinics.net/lists/linux-samsung-soc/msg38447.html I guess a platform device driver in drivers/power would be a better fit than drivers/mfd. I doubt introducing an mfd driver now makes much sense, we have already DT bindings for PHYs, the power domains, etc. The reason behind making it a mfd driver is, to make following design for pm domain and pm sleep functionality. -- | Exynos - PMU | | MFD device | | drivers/mfd/ | | --- | | --- | Exynos -pd | | Exynos - pm-sleep | | PMU's client device| | PMU's client device | | (drivers/soc/samsung/) | | (drivers/soc/samsung/) | - I will post this sleep driver shortly. I also suggest to keep everything in drivers/soc/samsung as all these drivers very much SoC specific. As Lee mentioned MFD can be used to register the device ( I am assuming he is referring to use of mfd_add_devices from Exynos -PMU driver, to make it a mfd device) but it should be kept outside of drivers/mfd. I just looked for current users of mfd_add_devices but only drivers from drivers/mfd only are calling this API, also once we call this API it will become an MFD device then why not keep into drivers/mfd or maybe I have little understanding of purpose of drivers/mfd. But still if it's OK to register Exynos -PMU as MFD device even if it's not in drivers/mfd folder, then I would suggest better to keep it in drivers/soc/samsung/ as it's very much SoC specific. As drivers/power looks like place to keep external power supply drivers such as batteries, AC, USB etc. Thanks, Pankaj Dubey -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/12] drivers: mfd: Add support for Exynos PMU driver
On Tue, 04 Nov 2014, Pankaj Dubey wrote: On Monday, November 03, 2014 8:56 PM, Lee Jones wrote, Subject: Re: [PATCH 02/12] drivers: mfd: Add support for Exynos PMU driver On Mon, 03 Nov 2014, Amit Daniel Kachhap wrote: From: Pankaj Dubey pankaj.du...@samsung.com This patch moves Exynos PMU driver implementation from arm/mach-exynos to drivers/mfd. This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in arch/arm/mach-exynos/pmu.c but moving ahead for ARM64 based SoC support, there is a need of DT based implementation of PMU driver. This driver uses already existing DT binding information. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-exynos/Makefile |2 +- drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + .../mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c |0 5 files changed, 12 insertions(+), 1 deletion(-) rename arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c (100%) I thought we spoke about this already [1]? What's changed? [1] https://lkml.org/lkml/2014/4/29/193 Yes correct, we had discussion about this in above post. But at that time I was not having enough points to put forward for keeping Exynos PMU driver in MFD folder. There are no valid points for keeping PMU code in MFD. At that point there was only one idea behind keeping Exynos PMU that in future it will be reused for ARM64 based SoC for PM related functionalities. But in this series we have implemented Exynos Power Domain for Samsung's ARM64 based SoCs. As far as I can see this will in following ways - 1: Moving out PM domain specific code from mach-exynos and reuse of same code for ARM64 based SoC also. 2: Since PM domain relies on PMU registers and does not have its own DT binding, MFD client and MFD device is most suitable for making this kind of platform drivers. MFD can be used to register the device, but the driver must not live in MFD. Please relocate it into drivers/power. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/12] drivers: mfd: Add support for Exynos PMU driver
On Mon, 03 Nov 2014, Amit Daniel Kachhap wrote: From: Pankaj Dubey pankaj.du...@samsung.com This patch moves Exynos PMU driver implementation from arm/mach-exynos to drivers/mfd. This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in arch/arm/mach-exynos/pmu.c but moving ahead for ARM64 based SoC support, there is a need of DT based implementation of PMU driver. This driver uses already existing DT binding information. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-exynos/Makefile |2 +- drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + .../mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c |0 5 files changed, 12 insertions(+), 1 deletion(-) rename arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c (100%) I thought we spoke about this already [1]? What's changed? [1] https://lkml.org/lkml/2014/4/29/193 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/12] drivers: mfd: Add support for Exynos PMU driver
Hi Lee, On Monday, November 03, 2014 8:56 PM, Lee Jones wrote, Subject: Re: [PATCH 02/12] drivers: mfd: Add support for Exynos PMU driver On Mon, 03 Nov 2014, Amit Daniel Kachhap wrote: From: Pankaj Dubey pankaj.du...@samsung.com This patch moves Exynos PMU driver implementation from arm/mach-exynos to drivers/mfd. This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in arch/arm/mach-exynos/pmu.c but moving ahead for ARM64 based SoC support, there is a need of DT based implementation of PMU driver. This driver uses already existing DT binding information. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-exynos/Makefile |2 +- drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + .../mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c |0 5 files changed, 12 insertions(+), 1 deletion(-) rename arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c (100%) I thought we spoke about this already [1]? What's changed? [1] https://lkml.org/lkml/2014/4/29/193 Yes correct, we had discussion about this in above post. But at that time I was not having enough points to put forward for keeping Exynos PMU driver in MFD folder. At that point there was only one idea behind keeping Exynos PMU that in future it will be reused for ARM64 based SoC for PM related functionalities. But in this series we have implemented Exynos Power Domain for Samsung's ARM64 based SoCs. As far as I can see this will in following ways - 1: Moving out PM domain specific code from mach-exynos and reuse of same code for ARM64 based SoC also. 2: Since PM domain relies on PMU registers and does not have its own DT binding, MFD client and MFD device is most suitable for making this kind of platform drivers. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
