* [GIT PULL] qcom SoC changes for v3.20
@ 2015-01-19 18:27 Kumar Gala
2015-01-22 1:15 ` Olof Johansson
0 siblings, 1 reply; 10+ messages in thread
From: Kumar Gala @ 2015-01-19 18:27 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [GIT PULL] qcom SoC changes for v3.20 2015-01-19 18:27 [GIT PULL] qcom SoC changes for v3.20 Kumar Gala @ 2015-01-22 1:15 ` Olof Johansson 2015-01-22 17:02 ` Kumar Gala 0 siblings, 1 reply; 10+ messages in thread From: Olof Johansson @ 2015-01-22 1:15 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [GIT PULL] qcom SoC changes for v3.20 2015-01-22 1:15 ` Olof Johansson @ 2015-01-22 17:02 ` Kumar Gala 2015-01-23 3:00 ` Olof Johansson 0 siblings, 1 reply; 10+ messages in thread From: Kumar Gala @ 2015-01-22 17:02 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [GIT PULL] qcom SoC changes for v3.20 2015-01-22 17:02 ` Kumar Gala @ 2015-01-23 3:00 ` Olof Johansson 2015-01-23 16:22 ` Kumar Gala 0 siblings, 1 reply; 10+ messages in thread From: Olof Johansson @ 2015-01-23 3:00 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [GIT PULL] qcom SoC changes for v3.20 2015-01-23 3:00 ` Olof Johansson @ 2015-01-23 16:22 ` Kumar Gala 2015-01-23 18:43 ` Olof Johansson 0 siblings, 1 reply; 10+ messages in thread From: Kumar Gala @ 2015-01-23 16:22 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [GIT PULL] qcom SoC changes for v3.20 2015-01-23 16:22 ` Kumar Gala @ 2015-01-23 18:43 ` Olof Johansson 2015-01-25 16:03 ` Rob Clark 2015-02-04 20:45 ` qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20) Kumar Gala 0 siblings, 2 replies; 10+ messages in thread From: Olof Johansson @ 2015-01-23 18:43 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [GIT PULL] qcom SoC changes for v3.20 2015-01-23 18:43 ` Olof Johansson @ 2015-01-25 16:03 ` Rob Clark 2015-01-25 16:11 ` Sean Paul 2015-02-04 20:45 ` qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20) Kumar Gala 1 sibling, 1 reply; 10+ messages in thread From: Rob Clark @ 2015-01-25 16:03 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [GIT PULL] qcom SoC changes for v3.20 2015-01-25 16:03 ` Rob Clark @ 2015-01-25 16:11 ` Sean Paul 0 siblings, 0 replies; 10+ messages in thread From: Sean Paul @ 2015-01-25 16:11 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20) 2015-01-23 18:43 ` Olof Johansson 2015-01-25 16:03 ` Rob Clark @ 2015-02-04 20:45 ` Kumar Gala 2015-02-04 20:49 ` Olof Johansson 1 sibling, 1 reply; 10+ messages in thread From: Kumar Gala @ 2015-02-04 20:45 UTC (permalink / raw) To: linux-arm-kernel >>> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20) 2015-02-04 20:45 ` qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20) Kumar Gala @ 2015-02-04 20:49 ` Olof Johansson 0 siblings, 0 replies; 10+ messages in thread From: Olof Johansson @ 2015-02-04 20:49 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-02-04 20:49 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-01-19 18:27 [GIT PULL] qcom SoC changes for v3.20 Kumar Gala 2015-01-22 1:15 ` Olof Johansson 2015-01-22 17:02 ` Kumar Gala 2015-01-23 3:00 ` Olof Johansson 2015-01-23 16:22 ` Kumar Gala 2015-01-23 18:43 ` Olof Johansson 2015-01-25 16:03 ` Rob Clark 2015-01-25 16:11 ` Sean Paul 2015-02-04 20:45 ` qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20) Kumar Gala 2015-02-04 20:49 ` Olof Johansson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).