[GIT PULL] qcom SoC changes for v3.20

On Fri, Jan 23, 2015 at 8:22 AM, Kumar Gala [off-list ref] wrote:

On Jan 22, 2015, at 9:00 PM, Olof Johansson [off-list ref] wrote:

quoted

On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala [off-list ref] wrote:

quoted

On Jan 21, 2015, at 7:15 PM, Olof Johansson [off-list ref] wrote:

quoted

Hi,


On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote:

quoted

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.

quoted

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