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

[Kumar Gala]

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

> On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala <galak@xxxxxxxxxxxxxx> wrote:
>> 
>> On Jan 21, 2015, at 7:15 PM, Olof Johansson <olof@xxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/