Re: [PATCH 02/12] drivers: mfd: Add support for Exynos PMU driver

2014-11-05 Thread amit daniel kachhap
On Thu, Nov 6, 2014 at 11:18 AM, Pankaj Dubey  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

RE: [PATCH 02/12] drivers: mfd: Add support for Exynos PMU driver

2014-11-05 Thread Pankaj Dubey
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

2014-11-05 Thread Sylwester Nawrocki
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

2014-11-04 Thread Lee Jones
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 
> > >
> > > 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 
> > > CC: Samuel Ortiz 
> > > CC: Lee Jones 
> > > Signed-off-by: Pankaj Dubey 
> > > Signed-off-by: Amit Daniel Kachhap 
> > > ---
> > >  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

2014-11-03 Thread Pankaj Dubey
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 
> >
> > 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 
> > CC: Samuel Ortiz 
> > CC: Lee Jones 
> > Signed-off-by: Pankaj Dubey 
> > Signed-off-by: Amit Daniel Kachhap 
> > ---
> >  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


Re: [PATCH 02/12] drivers: mfd: Add support for Exynos PMU driver

2014-11-03 Thread Lee Jones
On Mon, 03 Nov 2014, Amit Daniel Kachhap wrote:

> From: Pankaj Dubey 
> 
> 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 
> CC: Samuel Ortiz 
> CC: Lee Jones 
> Signed-off-by: Pankaj Dubey 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  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