Re: qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20)
On Wed, Feb 4, 2015 at 12:45 PM, Kumar Gala 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20)
>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom SoC changes for v3.20
On Sun, Jan 25, 2015 at 11:03 AM, Rob Clark wrote: > On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom SoC changes for v3.20
On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom SoC changes for v3.20-2
On Fri, Jan 23, 2015 at 10:37:37AM -0600, Kumar Gala wrote: > Updated from the tags/qcom-soc-for-3.20, dropped the movement of scm > code into drivers/soc/qcom, added a few other minor scm bug fixes, > and Andy Gross as co-maintainer. > > 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-2 > > for you to fetch changes up to f5d3af9d21f9790ac078276e6c103871c12a3daa: > > MAINTAINERS: Add co-maintainer for ARM/Qualcomm Support (2015-01-23 > 10:29:21 -0600) Merged, thanks. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom SoC changes for v3.20
On Fri, Jan 23, 2015 at 8:22 AM, Kumar Gala wrote: > > On Jan 22, 2015, at 9:00 PM, Olof Johansson wrote: > >> On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala wrote: >>> >>> On Jan 21, 2015, at 7:15 PM, Olof Johansson 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom SoC changes for v3.20
On Jan 22, 2015, at 9:00 PM, Olof Johansson wrote: > On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala wrote: >> >> On Jan 21, 2015, at 7:15 PM, Olof Johansson 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom SoC changes for v3.20
On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala wrote: > > On Jan 21, 2015, at 7:15 PM, Olof Johansson 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom SoC changes for v3.20
On Jan 21, 2015, at 7:15 PM, Olof Johansson 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom SoC changes for v3.20
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
