[GIT PULL] qcom SoC changes for v3.20

[GIT PULL] qcom SoC changes for v3.20

[Kumar Gala]

The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:

   Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20

for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:

   soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)

----------------------------------------------------------------
Qualcomm ARM Based SoC Updates for v3.20

* Moved scm support into drivers/soc/qcom (allows for use by drivers)
* Various bug fixes and minor feature additions to scm code
* Added big-endian support to debug MSM uart
* Added big-endian support to ARCH_QCOM

----------------------------------------------------------------
Lina Iyer (2):
       ARM: qcom: Add SCM warmboot flags for quad core targets.
       soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc

Olav Haugan (1):
       ARM: qcom: scm: Add logging of actual return code from scm call

Saravana Kannan (1):
       ARM: qcom: scm: Add API to query for service/command availability.

Stephen Boyd (9):
       ARM: debug: Update MSM and QCOM DEBUG_LL help
       ARM: debug: msm: Support big-endian CPUs
       ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
       ARM: qcom: scm: Fix incorrect cache invalidation
       ARM: qcom: scm: Get cacheline size from CTR
       ARM: qcom: scm: Add a feat version query API
       soc: qcom: scm: Move the scm driver to drivers/soc/qcom
       soc: qcom: scm: Add atomic SCM APIs
       soc: qcom: scm: Clarify boot interface

Vikram Mulukutla (1):
       ARM: qcom: scm: Flush the command buffer only instead of the entire cache

  arch/arm/Kconfig.debug                             |   5 +-
  arch/arm/include/debug/msm.S                       |   6 +
  arch/arm/mach-qcom/Kconfig                         |   4 +-
  arch/arm/mach-qcom/Makefile                        |   3 -
  arch/arm/mach-qcom/platsmp.c                       |   2 +-
  drivers/soc/qcom/Kconfig                           |   2 +
  drivers/soc/qcom/Makefile                          |   2 +
  .../arm/mach-qcom => drivers/soc/qcom}/scm-boot.c  |   6 +-
  {arch/arm/mach-qcom => drivers/soc/qcom}/scm.c     | 162 ++++++++++++++++++---
  .../arm/mach-qcom => include/soc/qcom}/scm-boot.h  |   4 +-
  {arch/arm/mach-qcom => include/soc/qcom}/scm.h     |   8 +-
  11 files changed, 173 insertions(+), 31 deletions(-)
  rename {arch/arm/mach-qcom => drivers/soc/qcom}/scm-boot.c (91%)
  rename {arch/arm/mach-qcom => drivers/soc/qcom}/scm.c (62%)
  rename {arch/arm/mach-qcom => include/soc/qcom}/scm-boot.h (87%)
  rename {arch/arm/mach-qcom => include/soc/qcom}/scm.h (70%)

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[GIT PULL] qcom SoC changes for v3.20

[Kumar Gala]

The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:

   Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20

for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:

   soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)

----------------------------------------------------------------
Qualcomm ARM Based SoC Updates for v3.20

* Moved scm support into drivers/soc/qcom (allows for use by drivers)
* Various bug fixes and minor feature additions to scm code
* Added big-endian support to debug MSM uart
* Added big-endian support to ARCH_QCOM

----------------------------------------------------------------
Lina Iyer (2):
       ARM: qcom: Add SCM warmboot flags for quad core targets.
       soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc

Olav Haugan (1):
       ARM: qcom: scm: Add logging of actual return code from scm call

Saravana Kannan (1):
       ARM: qcom: scm: Add API to query for service/command availability.

Stephen Boyd (9):
       ARM: debug: Update MSM and QCOM DEBUG_LL help
       ARM: debug: msm: Support big-endian CPUs
       ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
       ARM: qcom: scm: Fix incorrect cache invalidation
       ARM: qcom: scm: Get cacheline size from CTR
       ARM: qcom: scm: Add a feat version query API
       soc: qcom: scm: Move the scm driver to drivers/soc/qcom
       soc: qcom: scm: Add atomic SCM APIs
       soc: qcom: scm: Clarify boot interface

Vikram Mulukutla (1):
       ARM: qcom: scm: Flush the command buffer only instead of the entire cache

  arch/arm/Kconfig.debug                             |   5 +-
  arch/arm/include/debug/msm.S                       |   6 +
  arch/arm/mach-qcom/Kconfig                         |   4 +-
  arch/arm/mach-qcom/Makefile                        |   3 -
  arch/arm/mach-qcom/platsmp.c                       |   2 +-
  drivers/soc/qcom/Kconfig                           |   2 +
  drivers/soc/qcom/Makefile                          |   2 +
  .../arm/mach-qcom => drivers/soc/qcom}/scm-boot.c  |   6 +-
  {arch/arm/mach-qcom => drivers/soc/qcom}/scm.c     | 162 ++++++++++++++++++---
  .../arm/mach-qcom => include/soc/qcom}/scm-boot.h  |   4 +-
  {arch/arm/mach-qcom => include/soc/qcom}/scm.h     |   8 +-
  11 files changed, 173 insertions(+), 31 deletions(-)
  rename {arch/arm/mach-qcom => drivers/soc/qcom}/scm-boot.c (91%)
  rename {arch/arm/mach-qcom => drivers/soc/qcom}/scm.c (62%)
  rename {arch/arm/mach-qcom => include/soc/qcom}/scm-boot.h (87%)
  rename {arch/arm/mach-qcom => include/soc/qcom}/scm.h (70%)

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [GIT PULL] qcom SoC changes for v3.20

[Olof Johansson]

Hi,


On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
> 
>   Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
> 
> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
> 
>   soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
> 
> ----------------------------------------------------------------
> Qualcomm ARM Based SoC Updates for v3.20
> 
> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
> * Various bug fixes and minor feature additions to scm code
> * Added big-endian support to debug MSM uart
> * Added big-endian support to ARCH_QCOM
> 
> ----------------------------------------------------------------
> Lina Iyer (2):
>       ARM: qcom: Add SCM warmboot flags for quad core targets.
>       soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
> 
> Olav Haugan (1):
>       ARM: qcom: scm: Add logging of actual return code from scm call
> 
> Saravana Kannan (1):
>       ARM: qcom: scm: Add API to query for service/command availability.
> 
> Stephen Boyd (9):
>       ARM: debug: Update MSM and QCOM DEBUG_LL help
>       ARM: debug: msm: Support big-endian CPUs
>       ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>       ARM: qcom: scm: Fix incorrect cache invalidation
>       ARM: qcom: scm: Get cacheline size from CTR
>       ARM: qcom: scm: Add a feat version query API
>       soc: qcom: scm: Move the scm driver to drivers/soc/qcom

I replied on the patch here just now. This isn't the right thing to do,
as far as I can tell.

Seems like sending a fresh request with the material besides the move
to drivers/soc should be mergeable though, so feel free to do that while
the rest is hashed out.


-Olof

[GIT PULL] qcom SoC changes for v3.20

[Olof Johansson]

Hi,


On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
> 
>   Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
> 
> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
> 
>   soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
> 
> ----------------------------------------------------------------
> Qualcomm ARM Based SoC Updates for v3.20
> 
> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
> * Various bug fixes and minor feature additions to scm code
> * Added big-endian support to debug MSM uart
> * Added big-endian support to ARCH_QCOM
> 
> ----------------------------------------------------------------
> Lina Iyer (2):
>       ARM: qcom: Add SCM warmboot flags for quad core targets.
>       soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
> 
> Olav Haugan (1):
>       ARM: qcom: scm: Add logging of actual return code from scm call
> 
> Saravana Kannan (1):
>       ARM: qcom: scm: Add API to query for service/command availability.
> 
> Stephen Boyd (9):
>       ARM: debug: Update MSM and QCOM DEBUG_LL help
>       ARM: debug: msm: Support big-endian CPUs
>       ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>       ARM: qcom: scm: Fix incorrect cache invalidation
>       ARM: qcom: scm: Get cacheline size from CTR
>       ARM: qcom: scm: Add a feat version query API
>       soc: qcom: scm: Move the scm driver to drivers/soc/qcom

I replied on the patch here just now. This isn't the right thing to do,
as far as I can tell.

Seems like sending a fresh request with the material besides the move
to drivers/soc should be mergeable though, so feel free to do that while
the rest is hashed out.


-Olof

Re: [GIT PULL] qcom SoC changes for v3.20

[Kumar Gala]

On Jan 21, 2015, at 7:15 PM, Olof Johansson <olof@lixom.net> wrote:

> Hi,
> 
> 
> On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>> 
>>  Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>> 
>> are available in the git repository at:
>> 
>>  git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
>> 
>> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
>> 
>>  soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
>> 
>> ----------------------------------------------------------------
>> Qualcomm ARM Based SoC Updates for v3.20
>> 
>> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
>> * Various bug fixes and minor feature additions to scm code
>> * Added big-endian support to debug MSM uart
>> * Added big-endian support to ARCH_QCOM
>> 
>> ----------------------------------------------------------------
>> Lina Iyer (2):
>>      ARM: qcom: Add SCM warmboot flags for quad core targets.
>>      soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
>> 
>> Olav Haugan (1):
>>      ARM: qcom: scm: Add logging of actual return code from scm call
>> 
>> Saravana Kannan (1):
>>      ARM: qcom: scm: Add API to query for service/command availability.
>> 
>> Stephen Boyd (9):
>>      ARM: debug: Update MSM and QCOM DEBUG_LL help
>>      ARM: debug: msm: Support big-endian CPUs
>>      ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>      ARM: qcom: scm: Fix incorrect cache invalidation
>>      ARM: qcom: scm: Get cacheline size from CTR
>>      ARM: qcom: scm: Add a feat version query API
>>      soc: qcom: scm: Move the scm driver to drivers/soc/qcom
> 
> I replied on the patch here just now. This isn't the right thing to do,
> as far as I can tell.
> 
> Seems like sending a fresh request with the material besides the move
> to drivers/soc should be mergeable though, so feel free to do that while
> the rest is hashed out.

Would the following be ok (dropped the move to drivers/soc and some additional unused scm APIs as of right now):

ARM: qcom: Drop unnecessary selects from ARCH_QCOM
ARM: qcom: scm: Clarify boot interface
ARM: qcom: Add SCM warmboot flags for quad core targets.
ARM: qcom: scm: Add logging of actual return code from scm call
ARM: qcom: scm: Flush the command buffer only instead of the entire cache
ARM: qcom: scm: Get cacheline size from CTR
ARM: qcom: scm: Fix incorrect cache invalidation
ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
ARM: debug: msm: Support big-endian CPUs
ARM: debug: Update MSM and QCOM DEBUG_LL help

 Kconfig.debug        |    5 ++--
 include/debug/msm.S  |    6 +++++
 mach-qcom/Kconfig    |    3 --
 mach-qcom/scm-boot.c |    2 -
 mach-qcom/scm-boot.h |    4 ++-
 mach-qcom/scm.c      |   55 +++++++++++++++++++++++++++++++++++++--------------
 6 files changed, 54 insertions(+), 21 deletions(-)

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[GIT PULL] qcom SoC changes for v3.20

[Kumar Gala]

On Jan 21, 2015, at 7:15 PM, Olof Johansson <olof@lixom.net> wrote:

> Hi,
> 
> 
> On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>> 
>>  Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>> 
>> are available in the git repository at:
>> 
>>  git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
>> 
>> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
>> 
>>  soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
>> 
>> ----------------------------------------------------------------
>> Qualcomm ARM Based SoC Updates for v3.20
>> 
>> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
>> * Various bug fixes and minor feature additions to scm code
>> * Added big-endian support to debug MSM uart
>> * Added big-endian support to ARCH_QCOM
>> 
>> ----------------------------------------------------------------
>> Lina Iyer (2):
>>      ARM: qcom: Add SCM warmboot flags for quad core targets.
>>      soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
>> 
>> Olav Haugan (1):
>>      ARM: qcom: scm: Add logging of actual return code from scm call
>> 
>> Saravana Kannan (1):
>>      ARM: qcom: scm: Add API to query for service/command availability.
>> 
>> Stephen Boyd (9):
>>      ARM: debug: Update MSM and QCOM DEBUG_LL help
>>      ARM: debug: msm: Support big-endian CPUs
>>      ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>      ARM: qcom: scm: Fix incorrect cache invalidation
>>      ARM: qcom: scm: Get cacheline size from CTR
>>      ARM: qcom: scm: Add a feat version query API
>>      soc: qcom: scm: Move the scm driver to drivers/soc/qcom
> 
> I replied on the patch here just now. This isn't the right thing to do,
> as far as I can tell.
> 
> Seems like sending a fresh request with the material besides the move
> to drivers/soc should be mergeable though, so feel free to do that while
> the rest is hashed out.

Would the following be ok (dropped the move to drivers/soc and some additional unused scm APIs as of right now):

ARM: qcom: Drop unnecessary selects from ARCH_QCOM
ARM: qcom: scm: Clarify boot interface
ARM: qcom: Add SCM warmboot flags for quad core targets.
ARM: qcom: scm: Add logging of actual return code from scm call
ARM: qcom: scm: Flush the command buffer only instead of the entire cache
ARM: qcom: scm: Get cacheline size from CTR
ARM: qcom: scm: Fix incorrect cache invalidation
ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
ARM: debug: msm: Support big-endian CPUs
ARM: debug: Update MSM and QCOM DEBUG_LL help

 Kconfig.debug        |    5 ++--
 include/debug/msm.S  |    6 +++++
 mach-qcom/Kconfig    |    3 --
 mach-qcom/scm-boot.c |    2 -
 mach-qcom/scm-boot.h |    4 ++-
 mach-qcom/scm.c      |   55 +++++++++++++++++++++++++++++++++++++--------------
 6 files changed, 54 insertions(+), 21 deletions(-)

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [GIT PULL] qcom SoC changes for v3.20

[Olof Johansson]

On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Jan 21, 2015, at 7:15 PM, Olof Johansson <olof@lixom.net> wrote:
>
>> Hi,
>>
>>
>> On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
>>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>>>
>>>  Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>>>
>>> are available in the git repository at:
>>>
>>>  git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
>>>
>>> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
>>>
>>>  soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
>>>
>>> ----------------------------------------------------------------
>>> Qualcomm ARM Based SoC Updates for v3.20
>>>
>>> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
>>> * Various bug fixes and minor feature additions to scm code
>>> * Added big-endian support to debug MSM uart
>>> * Added big-endian support to ARCH_QCOM
>>>
>>> ----------------------------------------------------------------
>>> Lina Iyer (2):
>>>      ARM: qcom: Add SCM warmboot flags for quad core targets.
>>>      soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
>>>
>>> Olav Haugan (1):
>>>      ARM: qcom: scm: Add logging of actual return code from scm call
>>>
>>> Saravana Kannan (1):
>>>      ARM: qcom: scm: Add API to query for service/command availability.
>>>
>>> Stephen Boyd (9):
>>>      ARM: debug: Update MSM and QCOM DEBUG_LL help
>>>      ARM: debug: msm: Support big-endian CPUs
>>>      ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>>      ARM: qcom: scm: Fix incorrect cache invalidation
>>>      ARM: qcom: scm: Get cacheline size from CTR
>>>      ARM: qcom: scm: Add a feat version query API
>>>      soc: qcom: scm: Move the scm driver to drivers/soc/qcom
>>
>> I replied on the patch here just now. This isn't the right thing to do,
>> as far as I can tell.
>>
>> Seems like sending a fresh request with the material besides the move
>> to drivers/soc should be mergeable though, so feel free to do that while
>> the rest is hashed out.
>
> Would the following be ok (dropped the move to drivers/soc and some additional unused scm APIs as of right now):
>
> ARM: qcom: Drop unnecessary selects from ARCH_QCOM
> ARM: qcom: scm: Clarify boot interface
> ARM: qcom: Add SCM warmboot flags for quad core targets.
> ARM: qcom: scm: Add logging of actual return code from scm call
> ARM: qcom: scm: Flush the command buffer only instead of the entire cache
> ARM: qcom: scm: Get cacheline size from CTR
> ARM: qcom: scm: Fix incorrect cache invalidation
> ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
> ARM: debug: msm: Support big-endian CPUs
> ARM: debug: Update MSM and QCOM DEBUG_LL help
>
>  Kconfig.debug        |    5 ++--
>  include/debug/msm.S  |    6 +++++
>  mach-qcom/Kconfig    |    3 --
>  mach-qcom/scm-boot.c |    2 -
>  mach-qcom/scm-boot.h |    4 ++-
>  mach-qcom/scm.c      |   55 +++++++++++++++++++++++++++++++++++++--------------
>  6 files changed, 54 insertions(+), 21 deletions(-)

I'd be OK with merging this, send a request and tag. Would that let
the DRM folks make progress too?

If you need a common place for this, drivers/firmware seems like a
better home than drivers/soc.


-Olof

Re: [GIT PULL] qcom SoC changes for v3.20

[Olof Johansson]

On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Jan 21, 2015, at 7:15 PM, Olof Johansson <olof@lixom.net> wrote:
>
>> Hi,
>>
>>
>> On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
>>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>>>
>>>  Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>>>
>>> are available in the git repository at:
>>>
>>>  git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
>>>
>>> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
>>>
>>>  soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
>>>
>>> ----------------------------------------------------------------
>>> Qualcomm ARM Based SoC Updates for v3.20
>>>
>>> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
>>> * Various bug fixes and minor feature additions to scm code
>>> * Added big-endian support to debug MSM uart
>>> * Added big-endian support to ARCH_QCOM
>>>
>>> ----------------------------------------------------------------
>>> Lina Iyer (2):
>>>      ARM: qcom: Add SCM warmboot flags for quad core targets.
>>>      soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
>>>
>>> Olav Haugan (1):
>>>      ARM: qcom: scm: Add logging of actual return code from scm call
>>>
>>> Saravana Kannan (1):
>>>      ARM: qcom: scm: Add API to query for service/command availability.
>>>
>>> Stephen Boyd (9):
>>>      ARM: debug: Update MSM and QCOM DEBUG_LL help
>>>      ARM: debug: msm: Support big-endian CPUs
>>>      ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>>      ARM: qcom: scm: Fix incorrect cache invalidation
>>>      ARM: qcom: scm: Get cacheline size from CTR
>>>      ARM: qcom: scm: Add a feat version query API
>>>      soc: qcom: scm: Move the scm driver to drivers/soc/qcom
>>
>> I replied on the patch here just now. This isn't the right thing to do,
>> as far as I can tell.
>>
>> Seems like sending a fresh request with the material besides the move
>> to drivers/soc should be mergeable though, so feel free to do that while
>> the rest is hashed out.
>
> Would the following be ok (dropped the move to drivers/soc and some additional unused scm APIs as of right now):
>
> ARM: qcom: Drop unnecessary selects from ARCH_QCOM
> ARM: qcom: scm: Clarify boot interface
> ARM: qcom: Add SCM warmboot flags for quad core targets.
> ARM: qcom: scm: Add logging of actual return code from scm call
> ARM: qcom: scm: Flush the command buffer only instead of the entire cache
> ARM: qcom: scm: Get cacheline size from CTR
> ARM: qcom: scm: Fix incorrect cache invalidation
> ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
> ARM: debug: msm: Support big-endian CPUs
> ARM: debug: Update MSM and QCOM DEBUG_LL help
>
>  Kconfig.debug        |    5 ++--
>  include/debug/msm.S  |    6 +++++
>  mach-qcom/Kconfig    |    3 --
>  mach-qcom/scm-boot.c |    2 -
>  mach-qcom/scm-boot.h |    4 ++-
>  mach-qcom/scm.c      |   55 +++++++++++++++++++++++++++++++++++++--------------
>  6 files changed, 54 insertions(+), 21 deletions(-)

I'd be OK with merging this, send a request and tag. Would that let
the DRM folks make progress too?

If you need a common place for this, drivers/firmware seems like a
better home than drivers/soc.


-Olof

[GIT PULL] qcom SoC changes for v3.20

[Olof Johansson]

On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Jan 21, 2015, at 7:15 PM, Olof Johansson <olof@lixom.net> wrote:
>
>> Hi,
>>
>>
>> On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
>>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>>>
>>>  Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>>>
>>> are available in the git repository at:
>>>
>>>  git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
>>>
>>> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
>>>
>>>  soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
>>>
>>> ----------------------------------------------------------------
>>> Qualcomm ARM Based SoC Updates for v3.20
>>>
>>> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
>>> * Various bug fixes and minor feature additions to scm code
>>> * Added big-endian support to debug MSM uart
>>> * Added big-endian support to ARCH_QCOM
>>>
>>> ----------------------------------------------------------------
>>> Lina Iyer (2):
>>>      ARM: qcom: Add SCM warmboot flags for quad core targets.
>>>      soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
>>>
>>> Olav Haugan (1):
>>>      ARM: qcom: scm: Add logging of actual return code from scm call
>>>
>>> Saravana Kannan (1):
>>>      ARM: qcom: scm: Add API to query for service/command availability.
>>>
>>> Stephen Boyd (9):
>>>      ARM: debug: Update MSM and QCOM DEBUG_LL help
>>>      ARM: debug: msm: Support big-endian CPUs
>>>      ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>>      ARM: qcom: scm: Fix incorrect cache invalidation
>>>      ARM: qcom: scm: Get cacheline size from CTR
>>>      ARM: qcom: scm: Add a feat version query API
>>>      soc: qcom: scm: Move the scm driver to drivers/soc/qcom
>>
>> I replied on the patch here just now. This isn't the right thing to do,
>> as far as I can tell.
>>
>> Seems like sending a fresh request with the material besides the move
>> to drivers/soc should be mergeable though, so feel free to do that while
>> the rest is hashed out.
>
> Would the following be ok (dropped the move to drivers/soc and some additional unused scm APIs as of right now):
>
> ARM: qcom: Drop unnecessary selects from ARCH_QCOM
> ARM: qcom: scm: Clarify boot interface
> ARM: qcom: Add SCM warmboot flags for quad core targets.
> ARM: qcom: scm: Add logging of actual return code from scm call
> ARM: qcom: scm: Flush the command buffer only instead of the entire cache
> ARM: qcom: scm: Get cacheline size from CTR
> ARM: qcom: scm: Fix incorrect cache invalidation
> ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
> ARM: debug: msm: Support big-endian CPUs
> ARM: debug: Update MSM and QCOM DEBUG_LL help
>
>  Kconfig.debug        |    5 ++--
>  include/debug/msm.S  |    6 +++++
>  mach-qcom/Kconfig    |    3 --
>  mach-qcom/scm-boot.c |    2 -
>  mach-qcom/scm-boot.h |    4 ++-
>  mach-qcom/scm.c      |   55 +++++++++++++++++++++++++++++++++++++--------------
>  6 files changed, 54 insertions(+), 21 deletions(-)

I'd be OK with merging this, send a request and tag. Would that let
the DRM folks make progress too?

If you need a common place for this, drivers/firmware seems like a
better home than drivers/soc.


-Olof

Re: [GIT PULL] qcom SoC changes for v3.20

[Kumar Gala]

On Jan 22, 2015, at 9:00 PM, Olof Johansson <olof@lixom.net> wrote:

> On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala <galak@codeaurora.org> wrote:
>> 
>> On Jan 21, 2015, at 7:15 PM, Olof Johansson <olof@lixom.net> wrote:
>> 
>>> Hi,
>>> 
>>> 
>>> On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
>>>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>>>> 
>>>> Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>>>> 
>>>> are available in the git repository at:
>>>> 
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
>>>> 
>>>> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
>>>> 
>>>> soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
>>>> 
>>>> ----------------------------------------------------------------
>>>> Qualcomm ARM Based SoC Updates for v3.20
>>>> 
>>>> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
>>>> * Various bug fixes and minor feature additions to scm code
>>>> * Added big-endian support to debug MSM uart
>>>> * Added big-endian support to ARCH_QCOM
>>>> 
>>>> ----------------------------------------------------------------
>>>> Lina Iyer (2):
>>>>     ARM: qcom: Add SCM warmboot flags for quad core targets.
>>>>     soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
>>>> 
>>>> Olav Haugan (1):
>>>>     ARM: qcom: scm: Add logging of actual return code from scm call
>>>> 
>>>> Saravana Kannan (1):
>>>>     ARM: qcom: scm: Add API to query for service/command availability.
>>>> 
>>>> Stephen Boyd (9):
>>>>     ARM: debug: Update MSM and QCOM DEBUG_LL help
>>>>     ARM: debug: msm: Support big-endian CPUs
>>>>     ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>>>     ARM: qcom: scm: Fix incorrect cache invalidation
>>>>     ARM: qcom: scm: Get cacheline size from CTR
>>>>     ARM: qcom: scm: Add a feat version query API
>>>>     soc: qcom: scm: Move the scm driver to drivers/soc/qcom
>>> 
>>> I replied on the patch here just now. This isn't the right thing to do,
>>> as far as I can tell.
>>> 
>>> Seems like sending a fresh request with the material besides the move
>>> to drivers/soc should be mergeable though, so feel free to do that while
>>> the rest is hashed out.
>> 
>> Would the following be ok (dropped the move to drivers/soc and some additional unused scm APIs as of right now):
>> 
>> ARM: qcom: Drop unnecessary selects from ARCH_QCOM
>> ARM: qcom: scm: Clarify boot interface
>> ARM: qcom: Add SCM warmboot flags for quad core targets.
>> ARM: qcom: scm: Add logging of actual return code from scm call
>> ARM: qcom: scm: Flush the command buffer only instead of the entire cache
>> ARM: qcom: scm: Get cacheline size from CTR
>> ARM: qcom: scm: Fix incorrect cache invalidation
>> ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>> ARM: debug: msm: Support big-endian CPUs
>> ARM: debug: Update MSM and QCOM DEBUG_LL help
>> 
>> Kconfig.debug        |    5 ++--
>> include/debug/msm.S  |    6 +++++
>> mach-qcom/Kconfig    |    3 --
>> mach-qcom/scm-boot.c |    2 -
>> mach-qcom/scm-boot.h |    4 ++-
>> mach-qcom/scm.c      |   55 +++++++++++++++++++++++++++++++++++++--------------
>> 6 files changed, 54 insertions(+), 21 deletions(-)
> 
> I'd be OK with merging this, send a request and tag. Would that let
> the DRM folks make progress too?

Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.

> If you need a common place for this, drivers/firmware seems like a
> better home than drivers/soc.

Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?

- k
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [GIT PULL] qcom SoC changes for v3.20

[Kumar Gala]

On Jan 22, 2015, at 9:00 PM, Olof Johansson <olof@lixom.net> wrote:

> On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala <galak@codeaurora.org> wrote:
>> 
>> On Jan 21, 2015, at 7:15 PM, Olof Johansson <olof@lixom.net> wrote:
>> 
>>> Hi,
>>> 
>>> 
>>> On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
>>>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>>>> 
>>>> Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>>>> 
>>>> are available in the git repository at:
>>>> 
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
>>>> 
>>>> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
>>>> 
>>>> soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
>>>> 
>>>> ----------------------------------------------------------------
>>>> Qualcomm ARM Based SoC Updates for v3.20
>>>> 
>>>> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
>>>> * Various bug fixes and minor feature additions to scm code
>>>> * Added big-endian support to debug MSM uart
>>>> * Added big-endian support to ARCH_QCOM
>>>> 
>>>> ----------------------------------------------------------------
>>>> Lina Iyer (2):
>>>>     ARM: qcom: Add SCM warmboot flags for quad core targets.
>>>>     soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
>>>> 
>>>> Olav Haugan (1):
>>>>     ARM: qcom: scm: Add logging of actual return code from scm call
>>>> 
>>>> Saravana Kannan (1):
>>>>     ARM: qcom: scm: Add API to query for service/command availability.
>>>> 
>>>> Stephen Boyd (9):
>>>>     ARM: debug: Update MSM and QCOM DEBUG_LL help
>>>>     ARM: debug: msm: Support big-endian CPUs
>>>>     ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>>>     ARM: qcom: scm: Fix incorrect cache invalidation
>>>>     ARM: qcom: scm: Get cacheline size from CTR
>>>>     ARM: qcom: scm: Add a feat version query API
>>>>     soc: qcom: scm: Move the scm driver to drivers/soc/qcom
>>> 
>>> I replied on the patch here just now. This isn't the right thing to do,
>>> as far as I can tell.
>>> 
>>> Seems like sending a fresh request with the material besides the move
>>> to drivers/soc should be mergeable though, so feel free to do that while
>>> the rest is hashed out.
>> 
>> Would the following be ok (dropped the move to drivers/soc and some additional unused scm APIs as of right now):
>> 
>> ARM: qcom: Drop unnecessary selects from ARCH_QCOM
>> ARM: qcom: scm: Clarify boot interface
>> ARM: qcom: Add SCM warmboot flags for quad core targets.
>> ARM: qcom: scm: Add logging of actual return code from scm call
>> ARM: qcom: scm: Flush the command buffer only instead of the entire cache
>> ARM: qcom: scm: Get cacheline size from CTR
>> ARM: qcom: scm: Fix incorrect cache invalidation
>> ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>> ARM: debug: msm: Support big-endian CPUs
>> ARM: debug: Update MSM and QCOM DEBUG_LL help
>> 
>> Kconfig.debug        |    5 ++--
>> include/debug/msm.S  |    6 +++++
>> mach-qcom/Kconfig    |    3 --
>> mach-qcom/scm-boot.c |    2 -
>> mach-qcom/scm-boot.h |    4 ++-
>> mach-qcom/scm.c      |   55 +++++++++++++++++++++++++++++++++++++--------------
>> 6 files changed, 54 insertions(+), 21 deletions(-)
> 
> I'd be OK with merging this, send a request and tag. Would that let
> the DRM folks make progress too?

Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.

> If you need a common place for this, drivers/firmware seems like a
> better home than drivers/soc.

Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?

- k
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[GIT PULL] qcom SoC changes for v3.20

[Kumar Gala]

On Jan 22, 2015, at 9:00 PM, Olof Johansson <olof@lixom.net> wrote:

> On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala <galak@codeaurora.org> wrote:
>> 
>> On Jan 21, 2015, at 7:15 PM, Olof Johansson <olof@lixom.net> wrote:
>> 
>>> Hi,
>>> 
>>> 
>>> On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
>>>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>>>> 
>>>> Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>>>> 
>>>> are available in the git repository at:
>>>> 
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
>>>> 
>>>> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
>>>> 
>>>> soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
>>>> 
>>>> ----------------------------------------------------------------
>>>> Qualcomm ARM Based SoC Updates for v3.20
>>>> 
>>>> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
>>>> * Various bug fixes and minor feature additions to scm code
>>>> * Added big-endian support to debug MSM uart
>>>> * Added big-endian support to ARCH_QCOM
>>>> 
>>>> ----------------------------------------------------------------
>>>> Lina Iyer (2):
>>>>     ARM: qcom: Add SCM warmboot flags for quad core targets.
>>>>     soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
>>>> 
>>>> Olav Haugan (1):
>>>>     ARM: qcom: scm: Add logging of actual return code from scm call
>>>> 
>>>> Saravana Kannan (1):
>>>>     ARM: qcom: scm: Add API to query for service/command availability.
>>>> 
>>>> Stephen Boyd (9):
>>>>     ARM: debug: Update MSM and QCOM DEBUG_LL help
>>>>     ARM: debug: msm: Support big-endian CPUs
>>>>     ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>>>     ARM: qcom: scm: Fix incorrect cache invalidation
>>>>     ARM: qcom: scm: Get cacheline size from CTR
>>>>     ARM: qcom: scm: Add a feat version query API
>>>>     soc: qcom: scm: Move the scm driver to drivers/soc/qcom
>>> 
>>> I replied on the patch here just now. This isn't the right thing to do,
>>> as far as I can tell.
>>> 
>>> Seems like sending a fresh request with the material besides the move
>>> to drivers/soc should be mergeable though, so feel free to do that while
>>> the rest is hashed out.
>> 
>> Would the following be ok (dropped the move to drivers/soc and some additional unused scm APIs as of right now):
>> 
>> ARM: qcom: Drop unnecessary selects from ARCH_QCOM
>> ARM: qcom: scm: Clarify boot interface
>> ARM: qcom: Add SCM warmboot flags for quad core targets.
>> ARM: qcom: scm: Add logging of actual return code from scm call
>> ARM: qcom: scm: Flush the command buffer only instead of the entire cache
>> ARM: qcom: scm: Get cacheline size from CTR
>> ARM: qcom: scm: Fix incorrect cache invalidation
>> ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>> ARM: debug: msm: Support big-endian CPUs
>> ARM: debug: Update MSM and QCOM DEBUG_LL help
>> 
>> Kconfig.debug        |    5 ++--
>> include/debug/msm.S  |    6 +++++
>> mach-qcom/Kconfig    |    3 --
>> mach-qcom/scm-boot.c |    2 -
>> mach-qcom/scm-boot.h |    4 ++-
>> mach-qcom/scm.c      |   55 +++++++++++++++++++++++++++++++++++++--------------
>> 6 files changed, 54 insertions(+), 21 deletions(-)
> 
> I'd be OK with merging this, send a request and tag. Would that let
> the DRM folks make progress too?

Will do, I don?t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.

> If you need a common place for this, drivers/firmware seems like a
> better home than drivers/soc.

Agreed, what?s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?

- k
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [GIT PULL] qcom SoC changes for v3.20

[Olof Johansson]

On Fri, Jan 23, 2015 at 8:22 AM, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Jan 22, 2015, at 9:00 PM, Olof Johansson <olof@lixom.net> wrote:
>
>> On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala <galak@codeaurora.org> wrote:
>>>
>>> On Jan 21, 2015, at 7:15 PM, Olof Johansson <olof@lixom.net> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
>>>>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>>>>>
>>>>> Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
>>>>>
>>>>> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
>>>>>
>>>>> soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> Qualcomm ARM Based SoC Updates for v3.20
>>>>>
>>>>> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
>>>>> * Various bug fixes and minor feature additions to scm code
>>>>> * Added big-endian support to debug MSM uart
>>>>> * Added big-endian support to ARCH_QCOM
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> Lina Iyer (2):
>>>>>     ARM: qcom: Add SCM warmboot flags for quad core targets.
>>>>>     soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
>>>>>
>>>>> Olav Haugan (1):
>>>>>     ARM: qcom: scm: Add logging of actual return code from scm call
>>>>>
>>>>> Saravana Kannan (1):
>>>>>     ARM: qcom: scm: Add API to query for service/command availability.
>>>>>
>>>>> Stephen Boyd (9):
>>>>>     ARM: debug: Update MSM and QCOM DEBUG_LL help
>>>>>     ARM: debug: msm: Support big-endian CPUs
>>>>>     ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>>>>     ARM: qcom: scm: Fix incorrect cache invalidation
>>>>>     ARM: qcom: scm: Get cacheline size from CTR
>>>>>     ARM: qcom: scm: Add a feat version query API
>>>>>     soc: qcom: scm: Move the scm driver to drivers/soc/qcom
>>>>
>>>> I replied on the patch here just now. This isn't the right thing to do,
>>>> as far as I can tell.
>>>>
>>>> Seems like sending a fresh request with the material besides the move
>>>> to drivers/soc should be mergeable though, so feel free to do that while
>>>> the rest is hashed out.
>>>
>>> Would the following be ok (dropped the move to drivers/soc and some additional unused scm APIs as of right now):
>>>
>>> ARM: qcom: Drop unnecessary selects from ARCH_QCOM
>>> ARM: qcom: scm: Clarify boot interface
>>> ARM: qcom: Add SCM warmboot flags for quad core targets.
>>> ARM: qcom: scm: Add logging of actual return code from scm call
>>> ARM: qcom: scm: Flush the command buffer only instead of the entire cache
>>> ARM: qcom: scm: Get cacheline size from CTR
>>> ARM: qcom: scm: Fix incorrect cache invalidation
>>> ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>> ARM: debug: msm: Support big-endian CPUs
>>> ARM: debug: Update MSM and QCOM DEBUG_LL help
>>>
>>> Kconfig.debug        |    5 ++--
>>> include/debug/msm.S  |    6 +++++
>>> mach-qcom/Kconfig    |    3 --
>>> mach-qcom/scm-boot.c |    2 -
>>> mach-qcom/scm-boot.h |    4 ++-
>>> mach-qcom/scm.c      |   55 +++++++++++++++++++++++++++++++++++++--------------
>>> 6 files changed, 54 insertions(+), 21 deletions(-)
>>
>> I'd be OK with merging this, send a request and tag. Would that let
>> the DRM folks make progress too?
>
> Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>
>> If you need a common place for this, drivers/firmware seems like a
>> better home than drivers/soc.
>
> Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?

Are there any other SoCs out there with similar requirements on
firmware interfaces? I think most of them so far have been fairly
simple compared to the complexity of the qualcomm firmware.

Would it make sense to use firmware_ops for the common pieces and have
direct smc calls for the rest? I'm not sure that would buy us all that
much. Hm.

Well, at least it's an internal implementation detail. If we move it
now and find a better way to do it down the road it can be refactored.


-Olof

Re: [GIT PULL] qcom SoC changes for v3.20

[Olof Johansson]

On Fri, Jan 23, 2015 at 8:22 AM, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Jan 22, 2015, at 9:00 PM, Olof Johansson <olof@lixom.net> wrote:
>
>> On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala <galak@codeaurora.org> wrote:
>>>
>>> On Jan 21, 2015, at 7:15 PM, Olof Johansson <olof@lixom.net> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
>>>>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>>>>>
>>>>> Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
>>>>>
>>>>> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
>>>>>
>>>>> soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> Qualcomm ARM Based SoC Updates for v3.20
>>>>>
>>>>> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
>>>>> * Various bug fixes and minor feature additions to scm code
>>>>> * Added big-endian support to debug MSM uart
>>>>> * Added big-endian support to ARCH_QCOM
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> Lina Iyer (2):
>>>>>     ARM: qcom: Add SCM warmboot flags for quad core targets.
>>>>>     soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
>>>>>
>>>>> Olav Haugan (1):
>>>>>     ARM: qcom: scm: Add logging of actual return code from scm call
>>>>>
>>>>> Saravana Kannan (1):
>>>>>     ARM: qcom: scm: Add API to query for service/command availability.
>>>>>
>>>>> Stephen Boyd (9):
>>>>>     ARM: debug: Update MSM and QCOM DEBUG_LL help
>>>>>     ARM: debug: msm: Support big-endian CPUs
>>>>>     ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>>>>     ARM: qcom: scm: Fix incorrect cache invalidation
>>>>>     ARM: qcom: scm: Get cacheline size from CTR
>>>>>     ARM: qcom: scm: Add a feat version query API
>>>>>     soc: qcom: scm: Move the scm driver to drivers/soc/qcom
>>>>
>>>> I replied on the patch here just now. This isn't the right thing to do,
>>>> as far as I can tell.
>>>>
>>>> Seems like sending a fresh request with the material besides the move
>>>> to drivers/soc should be mergeable though, so feel free to do that while
>>>> the rest is hashed out.
>>>
>>> Would the following be ok (dropped the move to drivers/soc and some additional unused scm APIs as of right now):
>>>
>>> ARM: qcom: Drop unnecessary selects from ARCH_QCOM
>>> ARM: qcom: scm: Clarify boot interface
>>> ARM: qcom: Add SCM warmboot flags for quad core targets.
>>> ARM: qcom: scm: Add logging of actual return code from scm call
>>> ARM: qcom: scm: Flush the command buffer only instead of the entire cache
>>> ARM: qcom: scm: Get cacheline size from CTR
>>> ARM: qcom: scm: Fix incorrect cache invalidation
>>> ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>> ARM: debug: msm: Support big-endian CPUs
>>> ARM: debug: Update MSM and QCOM DEBUG_LL help
>>>
>>> Kconfig.debug        |    5 ++--
>>> include/debug/msm.S  |    6 +++++
>>> mach-qcom/Kconfig    |    3 --
>>> mach-qcom/scm-boot.c |    2 -
>>> mach-qcom/scm-boot.h |    4 ++-
>>> mach-qcom/scm.c      |   55 +++++++++++++++++++++++++++++++++++++--------------
>>> 6 files changed, 54 insertions(+), 21 deletions(-)
>>
>> I'd be OK with merging this, send a request and tag. Would that let
>> the DRM folks make progress too?
>
> Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>
>> If you need a common place for this, drivers/firmware seems like a
>> better home than drivers/soc.
>
> Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?

Are there any other SoCs out there with similar requirements on
firmware interfaces? I think most of them so far have been fairly
simple compared to the complexity of the qualcomm firmware.

Would it make sense to use firmware_ops for the common pieces and have
direct smc calls for the rest? I'm not sure that would buy us all that
much. Hm.

Well, at least it's an internal implementation detail. If we move it
now and find a better way to do it down the road it can be refactored.


-Olof

[GIT PULL] qcom SoC changes for v3.20

[Olof Johansson]

On Fri, Jan 23, 2015 at 8:22 AM, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Jan 22, 2015, at 9:00 PM, Olof Johansson <olof@lixom.net> wrote:
>
>> On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala <galak@codeaurora.org> wrote:
>>>
>>> On Jan 21, 2015, at 7:15 PM, Olof Johansson <olof@lixom.net> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:
>>>>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>>>>>
>>>>> Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20
>>>>>
>>>>> for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e:
>>>>>
>>>>> soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600)
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> Qualcomm ARM Based SoC Updates for v3.20
>>>>>
>>>>> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
>>>>> * Various bug fixes and minor feature additions to scm code
>>>>> * Added big-endian support to debug MSM uart
>>>>> * Added big-endian support to ARCH_QCOM
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> Lina Iyer (2):
>>>>>     ARM: qcom: Add SCM warmboot flags for quad core targets.
>>>>>     soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc
>>>>>
>>>>> Olav Haugan (1):
>>>>>     ARM: qcom: scm: Add logging of actual return code from scm call
>>>>>
>>>>> Saravana Kannan (1):
>>>>>     ARM: qcom: scm: Add API to query for service/command availability.
>>>>>
>>>>> Stephen Boyd (9):
>>>>>     ARM: debug: Update MSM and QCOM DEBUG_LL help
>>>>>     ARM: debug: msm: Support big-endian CPUs
>>>>>     ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>>>>     ARM: qcom: scm: Fix incorrect cache invalidation
>>>>>     ARM: qcom: scm: Get cacheline size from CTR
>>>>>     ARM: qcom: scm: Add a feat version query API
>>>>>     soc: qcom: scm: Move the scm driver to drivers/soc/qcom
>>>>
>>>> I replied on the patch here just now. This isn't the right thing to do,
>>>> as far as I can tell.
>>>>
>>>> Seems like sending a fresh request with the material besides the move
>>>> to drivers/soc should be mergeable though, so feel free to do that while
>>>> the rest is hashed out.
>>>
>>> Would the following be ok (dropped the move to drivers/soc and some additional unused scm APIs as of right now):
>>>
>>> ARM: qcom: Drop unnecessary selects from ARCH_QCOM
>>> ARM: qcom: scm: Clarify boot interface
>>> ARM: qcom: Add SCM warmboot flags for quad core targets.
>>> ARM: qcom: scm: Add logging of actual return code from scm call
>>> ARM: qcom: scm: Flush the command buffer only instead of the entire cache
>>> ARM: qcom: scm: Get cacheline size from CTR
>>> ARM: qcom: scm: Fix incorrect cache invalidation
>>> ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN
>>> ARM: debug: msm: Support big-endian CPUs
>>> ARM: debug: Update MSM and QCOM DEBUG_LL help
>>>
>>> Kconfig.debug        |    5 ++--
>>> include/debug/msm.S  |    6 +++++
>>> mach-qcom/Kconfig    |    3 --
>>> mach-qcom/scm-boot.c |    2 -
>>> mach-qcom/scm-boot.h |    4 ++-
>>> mach-qcom/scm.c      |   55 +++++++++++++++++++++++++++++++++++++--------------
>>> 6 files changed, 54 insertions(+), 21 deletions(-)
>>
>> I'd be OK with merging this, send a request and tag. Would that let
>> the DRM folks make progress too?
>
> Will do, I don?t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>
>> If you need a common place for this, drivers/firmware seems like a
>> better home than drivers/soc.
>
> Agreed, what?s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?

Are there any other SoCs out there with similar requirements on
firmware interfaces? I think most of them so far have been fairly
simple compared to the complexity of the qualcomm firmware.

Would it make sense to use firmware_ops for the common pieces and have
direct smc calls for the rest? I'm not sure that would buy us all that
much. Hm.

Well, at least it's an internal implementation detail. If we move it
now and find a better way to do it down the road it can be refactored.


-Olof

Re: [GIT PULL] qcom SoC changes for v3.20

[Rob Clark]

On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson <olof@lixom.net> wrote:
>>> I'd be OK with merging this, send a request and tag. Would that let
>>> the DRM folks make progress too?
>>
>> Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>>
>>> If you need a common place for this, drivers/firmware seems like a
>>> better home than drivers/soc.
>>
>> Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
>
> Are there any other SoCs out there with similar requirements on
> firmware interfaces? I think most of them so far have been fairly
> simple compared to the complexity of the qualcomm firmware.

I think the question is probably "how do downstream HDCP
implementations work on these other SoCs"..   so far, I think qcom is
the first to try to upstream HDCP support, but I know there have to be
at least a few downstream implementations lurking out there.

And I'm sure as some others come out of the woodwork there will be
some things to refactor.. like possibly shared helpers for
implementing the state machine, etc.

BR,
-R

> Would it make sense to use firmware_ops for the common pieces and have
> direct smc calls for the rest? I'm not sure that would buy us all that
> much. Hm.
>
> Well, at least it's an internal implementation detail. If we move it
> now and find a better way to do it down the road it can be refactored.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] qcom SoC changes for v3.20

[Rob Clark]

On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson <olof@lixom.net> wrote:
>>> I'd be OK with merging this, send a request and tag. Would that let
>>> the DRM folks make progress too?
>>
>> Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>>
>>> If you need a common place for this, drivers/firmware seems like a
>>> better home than drivers/soc.
>>
>> Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
>
> Are there any other SoCs out there with similar requirements on
> firmware interfaces? I think most of them so far have been fairly
> simple compared to the complexity of the qualcomm firmware.

I think the question is probably "how do downstream HDCP
implementations work on these other SoCs"..   so far, I think qcom is
the first to try to upstream HDCP support, but I know there have to be
at least a few downstream implementations lurking out there.

And I'm sure as some others come out of the woodwork there will be
some things to refactor.. like possibly shared helpers for
implementing the state machine, etc.

BR,
-R

> Would it make sense to use firmware_ops for the common pieces and have
> direct smc calls for the rest? I'm not sure that would buy us all that
> much. Hm.
>
> Well, at least it's an internal implementation detail. If we move it
> now and find a better way to do it down the road it can be refactored.

[GIT PULL] qcom SoC changes for v3.20

[Rob Clark]

On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson <olof@lixom.net> wrote:
>>> I'd be OK with merging this, send a request and tag. Would that let
>>> the DRM folks make progress too?
>>
>> Will do, I don?t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>>
>>> If you need a common place for this, drivers/firmware seems like a
>>> better home than drivers/soc.
>>
>> Agreed, what?s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
>
> Are there any other SoCs out there with similar requirements on
> firmware interfaces? I think most of them so far have been fairly
> simple compared to the complexity of the qualcomm firmware.

I think the question is probably "how do downstream HDCP
implementations work on these other SoCs"..   so far, I think qcom is
the first to try to upstream HDCP support, but I know there have to be
at least a few downstream implementations lurking out there.

And I'm sure as some others come out of the woodwork there will be
some things to refactor.. like possibly shared helpers for
implementing the state machine, etc.

BR,
-R

> Would it make sense to use firmware_ops for the common pieces and have
> direct smc calls for the rest? I'm not sure that would buy us all that
> much. Hm.
>
> Well, at least it's an internal implementation detail. If we move it
> now and find a better way to do it down the road it can be refactored.

Re: [GIT PULL] qcom SoC changes for v3.20

[Sean Paul]

On Sun, Jan 25, 2015 at 11:03 AM, Rob Clark <robdclark@gmail.com> wrote:
> On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson <olof@lixom.net> wrote:
>>>> I'd be OK with merging this, send a request and tag. Would that let
>>>> the DRM folks make progress too?
>>>
>>> Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>>>
>>>> If you need a common place for this, drivers/firmware seems like a
>>>> better home than drivers/soc.
>>>
>>> Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
>>
>> Are there any other SoCs out there with similar requirements on
>> firmware interfaces? I think most of them so far have been fairly
>> simple compared to the complexity of the qualcomm firmware.
>
> I think the question is probably "how do downstream HDCP
> implementations work on these other SoCs"..   so far, I think qcom is
> the first to try to upstream HDCP support, but I know there have to be
> at least a few downstream implementations lurking out there.
>

This isn't a concern on exynos, fwiw.

> And I'm sure as some others come out of the woodwork there will be
> some things to refactor.. like possibly shared helpers for
> implementing the state machine, etc.
>

Shared helpers would be useful to have once there's another hdcp
implementation upstream. I haven't looked at our downstream hdcp
implementation in a while, so it's difficult to say how much could be
factored out. It's on my TODO stack... somewhere.

Sean


> BR,
> -R
>
>> Would it make sense to use firmware_ops for the common pieces and have
>> direct smc calls for the rest? I'm not sure that would buy us all that
>> much. Hm.
>>
>> Well, at least it's an internal implementation detail. If we move it
>> now and find a better way to do it down the road it can be refactored.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] qcom SoC changes for v3.20

[Sean Paul]

On Sun, Jan 25, 2015 at 11:03 AM, Rob Clark <robdclark@gmail.com> wrote:
> On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson <olof@lixom.net> wrote:
>>>> I'd be OK with merging this, send a request and tag. Would that let
>>>> the DRM folks make progress too?
>>>
>>> Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>>>
>>>> If you need a common place for this, drivers/firmware seems like a
>>>> better home than drivers/soc.
>>>
>>> Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
>>
>> Are there any other SoCs out there with similar requirements on
>> firmware interfaces? I think most of them so far have been fairly
>> simple compared to the complexity of the qualcomm firmware.
>
> I think the question is probably "how do downstream HDCP
> implementations work on these other SoCs"..   so far, I think qcom is
> the first to try to upstream HDCP support, but I know there have to be
> at least a few downstream implementations lurking out there.
>

This isn't a concern on exynos, fwiw.

> And I'm sure as some others come out of the woodwork there will be
> some things to refactor.. like possibly shared helpers for
> implementing the state machine, etc.
>

Shared helpers would be useful to have once there's another hdcp
implementation upstream. I haven't looked at our downstream hdcp
implementation in a while, so it's difficult to say how much could be
factored out. It's on my TODO stack... somewhere.

Sean


> BR,
> -R
>
>> Would it make sense to use firmware_ops for the common pieces and have
>> direct smc calls for the rest? I'm not sure that would buy us all that
>> much. Hm.
>>
>> Well, at least it's an internal implementation detail. If we move it
>> now and find a better way to do it down the road it can be refactored.

[GIT PULL] qcom SoC changes for v3.20

[Sean Paul]

On Sun, Jan 25, 2015 at 11:03 AM, Rob Clark <robdclark@gmail.com> wrote:
> On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson <olof@lixom.net> wrote:
>>>> I'd be OK with merging this, send a request and tag. Would that let
>>>> the DRM folks make progress too?
>>>
>>> Will do, I don?t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>>>
>>>> If you need a common place for this, drivers/firmware seems like a
>>>> better home than drivers/soc.
>>>
>>> Agreed, what?s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
>>
>> Are there any other SoCs out there with similar requirements on
>> firmware interfaces? I think most of them so far have been fairly
>> simple compared to the complexity of the qualcomm firmware.
>
> I think the question is probably "how do downstream HDCP
> implementations work on these other SoCs"..   so far, I think qcom is
> the first to try to upstream HDCP support, but I know there have to be
> at least a few downstream implementations lurking out there.
>

This isn't a concern on exynos, fwiw.

> And I'm sure as some others come out of the woodwork there will be
> some things to refactor.. like possibly shared helpers for
> implementing the state machine, etc.
>

Shared helpers would be useful to have once there's another hdcp
implementation upstream. I haven't looked at our downstream hdcp
implementation in a while, so it's difficult to say how much could be
factored out. It's on my TODO stack... somewhere.

Sean


> BR,
> -R
>
>> Would it make sense to use firmware_ops for the common pieces and have
>> direct smc calls for the rest? I'm not sure that would buy us all that
>> much. Hm.
>>
>> Well, at least it's an internal implementation detail. If we move it
>> now and find a better way to do it down the road it can be refactored.

qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20)

[Kumar Gala]

>>> I'd be OK with merging this, send a request and tag. Would that let
>>> the DRM folks make progress too?
>> 
>> Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>> 
>>> If you need a common place for this, drivers/firmware seems like a
>>> better home than drivers/soc.
>> 
>> Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
> 
> Are there any other SoCs out there with similar requirements on
> firmware interfaces? I think most of them so far have been fairly
> simple compared to the complexity of the qualcomm firmware.
> 
> Would it make sense to use firmware_ops for the common pieces and have
> direct smc calls for the rest? I'm not sure that would buy us all that
> much. Hm.
> 
> Well, at least it's an internal implementation detail. If we move it
> now and find a better way to do it down the road it can be refactored.

So I’ve been looking at the ARM firmware_ops and I’m not sure it makes much sense to try and contort either the QCOM SCM interface to match or the other way around.  The firmware_ops don’t really match what the qcom scm interface exposes and trying to make it would just seem to make the firmware_ops to QCOM specific to be of any value.

I’ll look at cleaning up the SCM code and moving it to drivers/firmware instead of drivers/soc/qcom if that is more desirable.

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20)

[Kumar Gala]

>>> I'd be OK with merging this, send a request and tag. Would that let
>>> the DRM folks make progress too?
>> 
>> Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>> 
>>> If you need a common place for this, drivers/firmware seems like a
>>> better home than drivers/soc.
>> 
>> Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
> 
> Are there any other SoCs out there with similar requirements on
> firmware interfaces? I think most of them so far have been fairly
> simple compared to the complexity of the qualcomm firmware.
> 
> Would it make sense to use firmware_ops for the common pieces and have
> direct smc calls for the rest? I'm not sure that would buy us all that
> much. Hm.
> 
> Well, at least it's an internal implementation detail. If we move it
> now and find a better way to do it down the road it can be refactored.

So I’ve been looking at the ARM firmware_ops and I’m not sure it makes much sense to try and contort either the QCOM SCM interface to match or the other way around.  The firmware_ops don’t really match what the qcom scm interface exposes and trying to make it would just seem to make the firmware_ops to QCOM specific to be of any value.

I’ll look at cleaning up the SCM code and moving it to drivers/firmware instead of drivers/soc/qcom if that is more desirable.

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20)

[Kumar Gala]

>>> I'd be OK with merging this, send a request and tag. Would that let
>>> the DRM folks make progress too?
>> 
>> Will do, I don?t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>> 
>>> If you need a common place for this, drivers/firmware seems like a
>>> better home than drivers/soc.
>> 
>> Agreed, what?s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
> 
> Are there any other SoCs out there with similar requirements on
> firmware interfaces? I think most of them so far have been fairly
> simple compared to the complexity of the qualcomm firmware.
> 
> Would it make sense to use firmware_ops for the common pieces and have
> direct smc calls for the rest? I'm not sure that would buy us all that
> much. Hm.
> 
> Well, at least it's an internal implementation detail. If we move it
> now and find a better way to do it down the road it can be refactored.

So I?ve been looking at the ARM firmware_ops and I?m not sure it makes much sense to try and contort either the QCOM SCM interface to match or the other way around.  The firmware_ops don?t really match what the qcom scm interface exposes and trying to make it would just seem to make the firmware_ops to QCOM specific to be of any value.

I?ll look at cleaning up the SCM code and moving it to drivers/firmware instead of drivers/soc/qcom if that is more desirable.

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20)

[Olof Johansson]

On Wed, Feb 4, 2015 at 12:45 PM, Kumar Gala <galak@codeaurora.org> wrote:
>>>> I'd be OK with merging this, send a request and tag. Would that let
>>>> the DRM folks make progress too?
>>>
>>> Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>>>
>>>> If you need a common place for this, drivers/firmware seems like a
>>>> better home than drivers/soc.
>>>
>>> Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
>>
>> Are there any other SoCs out there with similar requirements on
>> firmware interfaces? I think most of them so far have been fairly
>> simple compared to the complexity of the qualcomm firmware.
>>
>> Would it make sense to use firmware_ops for the common pieces and have
>> direct smc calls for the rest? I'm not sure that would buy us all that
>> much. Hm.
>>
>> Well, at least it's an internal implementation detail. If we move it
>> now and find a better way to do it down the road it can be refactored.
>
> So I’ve been looking at the ARM firmware_ops and I’m not sure it makes much sense to try and contort either the QCOM SCM interface to match or the other way around.  The firmware_ops don’t really match what the qcom scm interface exposes and trying to make it would just seem to make the firmware_ops to QCOM specific to be of any value.

Ok. Thanks for investigating.

> I’ll look at cleaning up the SCM code and moving it to drivers/firmware instead of drivers/soc/qcom if that is more desirable.

Yeah, that'd be preferred.


-Olof

Re: qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20)

[Olof Johansson]

On Wed, Feb 4, 2015 at 12:45 PM, Kumar Gala <galak@codeaurora.org> wrote:
>>>> I'd be OK with merging this, send a request and tag. Would that let
>>>> the DRM folks make progress too?
>>>
>>> Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>>>
>>>> If you need a common place for this, drivers/firmware seems like a
>>>> better home than drivers/soc.
>>>
>>> Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
>>
>> Are there any other SoCs out there with similar requirements on
>> firmware interfaces? I think most of them so far have been fairly
>> simple compared to the complexity of the qualcomm firmware.
>>
>> Would it make sense to use firmware_ops for the common pieces and have
>> direct smc calls for the rest? I'm not sure that would buy us all that
>> much. Hm.
>>
>> Well, at least it's an internal implementation detail. If we move it
>> now and find a better way to do it down the road it can be refactored.
>
> So I’ve been looking at the ARM firmware_ops and I’m not sure it makes much sense to try and contort either the QCOM SCM interface to match or the other way around.  The firmware_ops don’t really match what the qcom scm interface exposes and trying to make it would just seem to make the firmware_ops to QCOM specific to be of any value.

Ok. Thanks for investigating.

> I’ll look at cleaning up the SCM code and moving it to drivers/firmware instead of drivers/soc/qcom if that is more desirable.

Yeah, that'd be preferred.


-Olof

qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20)

[Olof Johansson]

On Wed, Feb 4, 2015 at 12:45 PM, Kumar Gala <galak@codeaurora.org> wrote:
>>>> I'd be OK with merging this, send a request and tag. Would that let
>>>> the DRM folks make progress too?
>>>
>>> Will do, I don?t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>>>
>>>> If you need a common place for this, drivers/firmware seems like a
>>>> better home than drivers/soc.
>>>
>>> Agreed, what?s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
>>
>> Are there any other SoCs out there with similar requirements on
>> firmware interfaces? I think most of them so far have been fairly
>> simple compared to the complexity of the qualcomm firmware.
>>
>> Would it make sense to use firmware_ops for the common pieces and have
>> direct smc calls for the rest? I'm not sure that would buy us all that
>> much. Hm.
>>
>> Well, at least it's an internal implementation detail. If we move it
>> now and find a better way to do it down the road it can be refactored.
>
> So I?ve been looking at the ARM firmware_ops and I?m not sure it makes much sense to try and contort either the QCOM SCM interface to match or the other way around.  The firmware_ops don?t really match what the qcom scm interface exposes and trying to make it would just seem to make the firmware_ops to QCOM specific to be of any value.

Ok. Thanks for investigating.

> I?ll look at cleaning up the SCM code and moving it to drivers/firmware instead of drivers/soc/qcom if that is more desirable.

Yeah, that'd be preferred.


-Olof