[GIT,PULL] ARM: SOC PM domain for 4.12

Message ID 1491500546-6873-1-git-send-email-ssantosh@kernel.org
State New
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/arm-soc-pmdomain

Message

Santosh Shilimkar April 6, 2017, 5:42 p.m.
Hi Arnd, Olof,

As inidcated on the list, because of various dependencies, am senidng
Dave Gerlach's full patchset in single pull request. 

The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81:

  Linux 4.11-rc2 (2017-03-12 14:47:08 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/arm-soc-pmdomain

for you to fetch changes up to ae3874cc931b760c08bd6617a45fec1ba97d87f8:

  ARM: keystone: Drop PM domain support for k2g (2017-04-04 08:59:28 -0700)

----------------------------------------------------------------
ARM SOC PM domain support for 4.12

Dave Gerlach (5):
      PM / Domains: Add generic data pointer to genpd data struct
      PM / Domains: Do not check if simple providers have phandle cells
      dt-bindings: Add TI SCI PM Domains
      soc: ti: Add ti_sci_pm_domains driver
      ARM: keystone: Drop PM domain support for k2g

----------------------------------------------------------------
Dave Gerlach (5):
      PM / Domains: Add generic data pointer to genpd data struct
      PM / Domains: Do not check if simple providers have phandle cells
      dt-bindings: Add TI SCI PM Domains
      soc: ti: Add ti_sci_pm_domains driver
      ARM: keystone: Drop PM domain support for k2g

 .../devicetree/bindings/soc/ti/sci-pm-domain.txt   |  57 ++++++
 MAINTAINERS                                        |   3 +
 arch/arm/mach-keystone/Kconfig                     |   1 +
 arch/arm/mach-keystone/pm_domain.c                 |   4 +-
 drivers/base/power/domain.c                        |   2 -
 drivers/soc/ti/Kconfig                             |  12 ++
 drivers/soc/ti/Makefile                            |   1 +
 drivers/soc/ti/ti_sci_pm_domains.c                 | 202 +++++++++++++++++++++
 include/dt-bindings/genpd/k2g.h                    |  90 +++++++++
 include/linux/pm_domain.h                          |   1 +
 10 files changed, 370 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
 create mode 100644 drivers/soc/ti/ti_sci_pm_domains.c
 create mode 100644 include/dt-bindings/genpd/k2g.h

Comments

Arnd Bergmann April 19, 2017, 7:56 p.m. | #1
On Thu, Apr 6, 2017 at 7:42 PM, Santosh Shilimkar <ssantosh@kernel.org> wrote:
> Hi Arnd, Olof,
>
> As inidcated on the list, because of various dependencies, am senidng
> Dave Gerlach's full patchset in single pull request.
>
> The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81:
>
>   Linux 4.11-rc2 (2017-03-12 14:47:08 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/arm-soc-pmdomain
>
> for you to fetch changes up to ae3874cc931b760c08bd6617a45fec1ba97d87f8:
>
>   ARM: keystone: Drop PM domain support for k2g (2017-04-04 08:59:28 -0700)
>
> ----------------------------------------------------------------
> ARM SOC PM domain support for 4.12
>
> Dave Gerlach (5):
>       PM / Domains: Add generic data pointer to genpd data struct
>       PM / Domains: Do not check if simple providers have phandle cells
>       dt-bindings: Add TI SCI PM Domains
>       soc: ti: Add ti_sci_pm_domains driver
>       ARM: keystone: Drop PM domain support for k2g

I went through the list of arm@kernel.org emails that had not seen a reply after
Olof's pull marathon today. I did not get a reply for this one, but I
see that Olof
has merged it into next/drivers.

Since I was looking at it, I also took a closer look at the contents of the
patch series. The driver itself looks fine, but for the record, I'm not that
happy about seeing a header file duplicating the information from the
data sheet: We only use dt-binding headers to establish an interface between
the driver and the sources when there is well-defined fixed way to enumerate
resources, but in this case there clearly is...

        Arnd
Santosh Shilimkar April 19, 2017, 10:54 p.m. | #2
+Dave,

On 4/19/17 12:56 PM, Arnd Bergmann wrote:
> On Thu, Apr 6, 2017 at 7:42 PM, Santosh Shilimkar <ssantosh@kernel.org> wrote:
>> Hi Arnd, Olof,
>>
>> As inidcated on the list, because of various dependencies, am senidng
>> Dave Gerlach's full patchset in single pull request.
>>
>> The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81:
>>
>>   Linux 4.11-rc2 (2017-03-12 14:47:08 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/arm-soc-pmdomain
>>
>> for you to fetch changes up to ae3874cc931b760c08bd6617a45fec1ba97d87f8:
>>
>>   ARM: keystone: Drop PM domain support for k2g (2017-04-04 08:59:28 -0700)
>>
>> ----------------------------------------------------------------
>> ARM SOC PM domain support for 4.12
>>
>> Dave Gerlach (5):
>>       PM / Domains: Add generic data pointer to genpd data struct
>>       PM / Domains: Do not check if simple providers have phandle cells
>>       dt-bindings: Add TI SCI PM Domains
>>       soc: ti: Add ti_sci_pm_domains driver
>>       ARM: keystone: Drop PM domain support for k2g
>
> I went through the list of arm@kernel.org emails that had not seen a reply after
> Olof's pull marathon today. I did not get a reply for this one, but I
> see that Olof
> has merged it into next/drivers.
>
Thanks.

> Since I was looking at it, I also took a closer look at the contents of the
> patch series. The driver itself looks fine, but for the record, I'm not that
> happy about seeing a header file duplicating the information from the
> data sheet: We only use dt-binding headers to establish an interface between
> the driver and the sources when there is well-defined fixed way to enumerate
> resources, but in this case there clearly is...
>
Dave, please care to follow up Arnd's concerns on those defines.

Regards,
Santosh
Dave Gerlach April 20, 2017, 1:44 a.m. | #3
Arnd,
On 04/19/2017 05:54 PM, santosh.shilimkar@oracle.com wrote:
> +Dave,
> 
> On 4/19/17 12:56 PM, Arnd Bergmann wrote:
>> On Thu, Apr 6, 2017 at 7:42 PM, Santosh Shilimkar <ssantosh@kernel.org> wrote:
>>> Hi Arnd, Olof,
>>>
>>> As inidcated on the list, because of various dependencies, am senidng
>>> Dave Gerlach's full patchset in single pull request.
>>>
>>> The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81:
>>>
>>>   Linux 4.11-rc2 (2017-03-12 14:47:08 -0700)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
>>> tags/arm-soc-pmdomain
>>>
>>> for you to fetch changes up to ae3874cc931b760c08bd6617a45fec1ba97d87f8:
>>>
>>>   ARM: keystone: Drop PM domain support for k2g (2017-04-04 08:59:28 -0700)
>>>
>>> ----------------------------------------------------------------
>>> ARM SOC PM domain support for 4.12
>>>
>>> Dave Gerlach (5):
>>>       PM / Domains: Add generic data pointer to genpd data struct
>>>       PM / Domains: Do not check if simple providers have phandle cells
>>>       dt-bindings: Add TI SCI PM Domains
>>>       soc: ti: Add ti_sci_pm_domains driver
>>>       ARM: keystone: Drop PM domain support for k2g
>>
>> I went through the list of arm@kernel.org emails that had not seen a reply after
>> Olof's pull marathon today. I did not get a reply for this one, but I
>> see that Olof
>> has merged it into next/drivers.
>>
> Thanks.
> 
>> Since I was looking at it, I also took a closer look at the contents of the
>> patch series. The driver itself looks fine, but for the record, I'm not that
>> happy about seeing a header file duplicating the information from the
>> data sheet: We only use dt-binding headers to establish an interface between
>> the driver and the sources when there is well-defined fixed way to enumerate
>> resources, but in this case there clearly is...
>>

I apologize but I'm not clear on exactly what your concern is? Currently we
define a device ID which is associated to a "device" in the firmware's view of
the world, however the firmware has no knowledge of what goes on in the kernel
and vice-versa. The device ID is associated to that device only on that
hardware, it could be a different ID on a different SoC making use of SCI. The
only way a device is identified to the firmware is through this number, it will
also be used by the ti-sci-clock [1] and ti-sci-reset [2] drivers to identify
the device.

I'm not sure what you mean by "We only use dt-binding headers to establish an
interface between the driver and the sources when there is well-defined fixed
way to enumerate resources."

Regards,
Dave

[1] https://www.spinics.net/lists/arm-kernel/msg537665.html
[2] https://www.spinics.net/lists/devicetree/msg151643.html

> Dave, please care to follow up Arnd's concerns on those defines.
> 
> Regards,
> Santosh
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Arnd Bergmann April 20, 2017, 8:04 a.m. | #4
On Thu, Apr 20, 2017 at 3:44 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
> On 04/19/2017 05:54 PM, santosh.shilimkar@oracle.com wrote:
>> On 4/19/17 12:56 PM, Arnd Bergmann wrote:

>>
>>> Since I was looking at it, I also took a closer look at the contents of the
>>> patch series. The driver itself looks fine, but for the record, I'm not that
>>> happy about seeing a header file duplicating the information from the
>>> data sheet: We only use dt-binding headers to establish an interface between
>>> the driver and the sources when there is well-defined fixed way to enumerate
>>> resources, but in this case there clearly is...
>>>
>
> I apologize but I'm not clear on exactly what your concern is? Currently we
> define a device ID which is associated to a "device" in the firmware's view of
> the world, however the firmware has no knowledge of what goes on in the kernel
> and vice-versa. The device ID is associated to that device only on that
> hardware, it could be a different ID on a different SoC making use of SCI. The
> only way a device is identified to the firmware is through this number, it will
> also be used by the ti-sci-clock [1] and ti-sci-reset [2] drivers to identify
> the device.
>
> I'm not sure what you mean by "We only use dt-binding headers to establish an
> interface between the driver and the sources when there is well-defined fixed
> way to enumerate resources."

More generally speaking, header files are used as interfaces when you want to
ensure that a number you pick, or a function prototype is the same between
two or more parts of a system.

For the reset handling and the pm domain, this is not the case: the header
only gets included by the dts files and the driver does not use it at all, so
you can simply remove the header and open-code the numbers in the
dts file, as you do in the same files for all other numbers (register addresses,
interrupts, gpio lines). Please remove these to save the pointless  indirection.

For the clk driver, this is a little less obvious as you do use the K2G_DEV_*
macros in both the dts files and in the driver. However, I think these still
fall in the same basic category, as the numbers are not picked arbitrarily
when writing the driver to describe the usual mess of register offsets in
a clock controller. Rather this one is apparently used for communicating
with the firmware using a proper interface, so you can simply move the
header file contents into the driver.

      Arnd