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

From: Kumar Gala
Date: Fri Jan 23 2015 - 11:22:21 EST



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/