Re: [RFC v2 00/10] Freescale DPAA B/QMan drivers
On Feb 16, 2015, at 9:46 AM, Emil Medve wrote: > v2: Moved out of staging into soc/freescale > > Hello, > > > This is the se attempt to publish the . They are > not to be applied yet. > > These are the Freescale DPAA B/QMan drivers. At this stage, this is more or > less > the drivers from the Freescale PowerPC SDK roughly squashed and split in a > sequence of component patches. They still needs some work and cleanup before > we > expect to have them applied, but we appreciate early feedback > > To do:Add a maintainer(s) entry > Add module(s) support > Some important clean-ups > > Cheers, > > > Geoff Thorpe (8): > fsl_bman: Add drivers for the Freescale DPAA BMan > fsl_qman: Add drivers for the Freescale DPAA QMan > powerpc/mpc85xx: Add platform support for the Freescale DPAA BMan > powerpc/mpc85xx: Add platform support for the Freescale DPAA QMan > fsl_bman: Add self-tester > fsl_qman: Add self-tester > fsl_bman: Add debugfs support > fsl_qman: Add debugfs support > > Hai-Ying Wang (2): > fsl_bman: Add HOTPLUG_CPU support > fsl_qman: Add HOTPLUG_CPU support Really should look at using CMA for memory reservations used by q/bman backing store. - k-- 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: [RFC v2 01/10] fsl_bman: Add drivers for the Freescale DPAA BMan
On Feb 16, 2015, at 9:46 AM, Emil Medve wrote: > From: Geoff Thorpe > > Change-Id: I075944acf740dbaae861104c17a9ff7247dec1be > Signed-off-by: Geoff Thorpe > --- > drivers/soc/Kconfig |1 + > drivers/soc/Makefile |1 + > drivers/soc/freescale/Kconfig| 51 ++ > drivers/soc/freescale/Makefile |7 + > drivers/soc/freescale/bman.c | 611 > drivers/soc/freescale/bman.h | 524 + > drivers/soc/freescale/bman_api.c | 1033 ++ > drivers/soc/freescale/bman_portal.c | 330 +++ > drivers/soc/freescale/bman_priv.h| 149 + > drivers/soc/freescale/dpaa_alloc.c | 404 + > drivers/soc/freescale/dpaa_sys.h | 235 > drivers/soc/freescale/qbman_driver.c | 41 ++ > include/linux/fsl_bman.h | 511 + If you are using drivers/soc than the include should probably be include/soc/freescale/ Also, any reason you guys aren’t using drivers/soc/fsl ? - k-- 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: [RFC v2 01/10] fsl_bman: Add drivers for the Freescale DPAA BMan
On Feb 16, 2015, at 9:46 AM, Emil Medve emilian.me...@freescale.com wrote: From: Geoff Thorpe geoff.tho...@freescale.com Change-Id: I075944acf740dbaae861104c17a9ff7247dec1be Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com --- drivers/soc/Kconfig |1 + drivers/soc/Makefile |1 + drivers/soc/freescale/Kconfig| 51 ++ drivers/soc/freescale/Makefile |7 + drivers/soc/freescale/bman.c | 611 drivers/soc/freescale/bman.h | 524 + drivers/soc/freescale/bman_api.c | 1033 ++ drivers/soc/freescale/bman_portal.c | 330 +++ drivers/soc/freescale/bman_priv.h| 149 + drivers/soc/freescale/dpaa_alloc.c | 404 + drivers/soc/freescale/dpaa_sys.h | 235 drivers/soc/freescale/qbman_driver.c | 41 ++ include/linux/fsl_bman.h | 511 + If you are using drivers/soc than the include should probably be include/soc/freescale/ Also, any reason you guys aren’t using drivers/soc/fsl ? - k-- 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: [RFC v2 00/10] Freescale DPAA B/QMan drivers
On Feb 16, 2015, at 9:46 AM, Emil Medve emilian.me...@freescale.com wrote: v2: Moved out of staging into soc/freescale Hello, This is the se attempt to publish the . They are not to be applied yet. These are the Freescale DPAA B/QMan drivers. At this stage, this is more or less the drivers from the Freescale PowerPC SDK roughly squashed and split in a sequence of component patches. They still needs some work and cleanup before we expect to have them applied, but we appreciate early feedback To do:Add a maintainer(s) entry Add module(s) support Some important clean-ups Cheers, Geoff Thorpe (8): fsl_bman: Add drivers for the Freescale DPAA BMan fsl_qman: Add drivers for the Freescale DPAA QMan powerpc/mpc85xx: Add platform support for the Freescale DPAA BMan powerpc/mpc85xx: Add platform support for the Freescale DPAA QMan fsl_bman: Add self-tester fsl_qman: Add self-tester fsl_bman: Add debugfs support fsl_qman: Add debugfs support Hai-Ying Wang (2): fsl_bman: Add HOTPLUG_CPU support fsl_qman: Add HOTPLUG_CPU support Really should look at using CMA for memory reservations used by q/bman backing store. - k-- 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: [Patch v3 0/6] GSBI CRCI Autoconfiguration Support
On Feb 9, 2015, at 4:01 PM, Andy Gross wrote: > This patch set adds support for automatic configuration of GSBI DMA CRCI > values. > > DMA operations require that the ADM CRCI mux values be properly configured in > the TCSR (Top Control and Status Register) block. During probing of a GSBI > device, the client mode must be declared and this can be used to lookup the > correct TCSR ADM CRCI MUX settings and then program them so that they are > correct before any clients are populated. > > These patches add the TCSR as a syscon device and that allows the GSBI to > access and manipulate the ADM CRCI MUX registers to correctly configure the > values based on the GSBI port configuration. > > Changes since v2: > - Use cell-index instead of alias to denote GSBI instance > > Changes since v1: > - Fixed various review comments > > Andy Gross (6): > soc: qcom: gsbi: Add support for ADM CRCI muxing > mfd: qcom,tcsr: Add device tree binding for TCSR > ARM: DT: apq8064: Add TCSR support > ARM: DT: ipq8064: Add TCSR support > ARM: DT: msm8660: Add TCSR support > ARM: DT: msm8960: Add TCSR support > > .../devicetree/bindings/mfd/qcom,tcsr.txt | 22 +++ > .../devicetree/bindings/soc/qcom/qcom,gsbi.txt | 14 +- > arch/arm/boot/dts/qcom-apq8064.dtsi| 14 ++ > arch/arm/boot/dts/qcom-ipq8064.dtsi| 14 ++ > arch/arm/boot/dts/qcom-msm8660.dtsi|8 ++ > arch/arm/boot/dts/qcom-msm8960.dtsi|8 ++ > drivers/soc/qcom/Kconfig |1 + > drivers/soc/qcom/qcom_gsbi.c | 152 > 8 files changed, 232 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/mfd/qcom,tcsr.txt Series looks good, do we need a qcom_defconfig update to enable anything new for this? - 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: [Patch v3 0/6] GSBI CRCI Autoconfiguration Support
On Feb 9, 2015, at 4:01 PM, Andy Gross agr...@codeaurora.org wrote: This patch set adds support for automatic configuration of GSBI DMA CRCI values. DMA operations require that the ADM CRCI mux values be properly configured in the TCSR (Top Control and Status Register) block. During probing of a GSBI device, the client mode must be declared and this can be used to lookup the correct TCSR ADM CRCI MUX settings and then program them so that they are correct before any clients are populated. These patches add the TCSR as a syscon device and that allows the GSBI to access and manipulate the ADM CRCI MUX registers to correctly configure the values based on the GSBI port configuration. Changes since v2: - Use cell-index instead of alias to denote GSBI instance Changes since v1: - Fixed various review comments Andy Gross (6): soc: qcom: gsbi: Add support for ADM CRCI muxing mfd: qcom,tcsr: Add device tree binding for TCSR ARM: DT: apq8064: Add TCSR support ARM: DT: ipq8064: Add TCSR support ARM: DT: msm8660: Add TCSR support ARM: DT: msm8960: Add TCSR support .../devicetree/bindings/mfd/qcom,tcsr.txt | 22 +++ .../devicetree/bindings/soc/qcom/qcom,gsbi.txt | 14 +- arch/arm/boot/dts/qcom-apq8064.dtsi| 14 ++ arch/arm/boot/dts/qcom-ipq8064.dtsi| 14 ++ arch/arm/boot/dts/qcom-msm8660.dtsi|8 ++ arch/arm/boot/dts/qcom-msm8960.dtsi|8 ++ drivers/soc/qcom/Kconfig |1 + drivers/soc/qcom/qcom_gsbi.c | 152 8 files changed, 232 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mfd/qcom,tcsr.txt Series looks good, do we need a qcom_defconfig update to enable anything new for this? - 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/
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/
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: [Patch v2 1/6] soc: qcom: gsbi: Add support for ADM CRCI muxing
On Jan 30, 2015, at 3:37 PM, Stephen Boyd wrote:
> On 01/30/15 08:32, Kumar Gala wrote:
>> On Jan 30, 2015, at 12:25 AM, Andy Gross wrote:
>>
>>> Required properties if child node exists:
>>> - #address-cells: Must be 1
>>> - #size-cells: Must be 1
>>> - ranges: Must be present
>>>
>>> +Note: Each GSBI should have an alias correctly numbered in "aliases" node.
>>> +
>>> Properties for children:
>>>
>>> A GSBI controller node can contain 0 or more child nodes representing serial
>>> @@ -37,6 +41,10 @@ Example for APQ8064:
>>>
>>> #include
>>>
>>> + aliases {
>>> + gsbi4 = <>;
>>> + };
>> You appear to be using the alias name to determine a index number for the
>> gsbi, if that is the case, than you should probably just add a cell-index
>> node to the gsbi’s for this purpose.
>>
>
> I thought cell-index was "deprecated" and referred more to things like
> enumerating all the devices on a bus by assigning them a unique ID.
> Aliases, on the other hand, allow us to enumerate a subset of devices
> that share the same bus with other devices of different types. For
> example, how would I know that a device is gsbi1 vs serial1 if they both
> used cell-index and they both had the same parent node?
I think the problem was cell-index was never well understood and abused. For
the example you are giving you wouldn’t use cell-index because you are talking
about things that would have different compatibles. For what it appears we
really are enumerating the GSBI hardware to match some programming interface
convention. If that is the case than I think cell-index is proper.
- 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: [Patch v2 1/6] soc: qcom: gsbi: Add support for ADM CRCI muxing
On Jan 30, 2015, at 12:25 AM, Andy Gross wrote:
> This patch adds automatic configuration for the ADM CRCI muxing required to
> support DMA operations for GSBI clients. The GSBI mode and instance determine
> the correct TCSR ADM CRCI MUX value that must be programmed so that the DMA
> works properly.
>
> Signed-off-by: Andy Gross
> ---
> .../devicetree/bindings/soc/qcom/qcom,gsbi.txt | 18 ++-
> drivers/soc/qcom/Kconfig |1 +
> drivers/soc/qcom/qcom_gsbi.c | 153
> 3 files changed, 171 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
> b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
> index 4ce24d4..8fe7b37 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
> @@ -6,7 +6,7 @@ configuration settings. The mode setting will govern the
> input/output mode of
> the 4 GSBI IOs.
>
> Required properties:
> -- compatible: must contain "qcom,gsbi-v1.0.0" for APQ8064/IPQ8064
> +- compatible:Should contain "qcom,gsbi-v1.0.0"
> - reg: Address range for GSBI registers
> - clocks: required clock
> - clock-names: must contain "iface" entry
> @@ -16,12 +16,16 @@ Required properties:
> Optional properties:
> - qcom,crci : indicates CRCI MUX value for QUP CRCI ports. Please reference
> dt-bindings/soc/qcom,gsbi.h for valid CRCI mux values.
> +- syscon-tcsr: indicates phandle of TCSR syscon node. Required if child uses
> + dma.
>
> Required properties if child node exists:
> - #address-cells: Must be 1
> - #size-cells: Must be 1
> - ranges: Must be present
>
> +Note: Each GSBI should have an alias correctly numbered in "aliases" node.
> +
> Properties for children:
>
> A GSBI controller node can contain 0 or more child nodes representing serial
> @@ -37,6 +41,10 @@ Example for APQ8064:
>
> #include
>
> + aliases {
> + gsbi4 = <>;
> + };
You appear to be using the alias name to determine a index number for the gsbi,
if that is the case, than you should probably just add a cell-index node to the
gsbi’s for this purpose.
> +
> gsbi4@1630 {
> compatible = "qcom,gsbi-v1.0.0";
> reg = <0x1630 0x100>;
> @@ -48,6 +56,8 @@ Example for APQ8064:
> qcom,mode = ;
> qcom,crci = ;
>
> + syscon-tcsr = <>;
> +
> /* child nodes go under here */
>
> i2c_qup4: i2c@1638 {
> @@ -76,3 +86,9 @@ Example for APQ8064:
> };
> };
>
> + tcsr: syscon@1a40 {
> + compatible = "qcom,apq8064-tcsr", "syscon";
> + reg = <0x1a40 0x100>;
> + };
> +
> +
- 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: [Patch v2 1/6] soc: qcom: gsbi: Add support for ADM CRCI muxing
On Jan 30, 2015, at 12:25 AM, Andy Gross agr...@codeaurora.org wrote:
This patch adds automatic configuration for the ADM CRCI muxing required to
support DMA operations for GSBI clients. The GSBI mode and instance determine
the correct TCSR ADM CRCI MUX value that must be programmed so that the DMA
works properly.
Signed-off-by: Andy Gross agr...@codeaurora.org
---
.../devicetree/bindings/soc/qcom/qcom,gsbi.txt | 18 ++-
drivers/soc/qcom/Kconfig |1 +
drivers/soc/qcom/qcom_gsbi.c | 153
3 files changed, 171 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
index 4ce24d4..8fe7b37 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
@@ -6,7 +6,7 @@ configuration settings. The mode setting will govern the
input/output mode of
the 4 GSBI IOs.
Required properties:
-- compatible: must contain qcom,gsbi-v1.0.0 for APQ8064/IPQ8064
+- compatible:Should contain qcom,gsbi-v1.0.0
- reg: Address range for GSBI registers
- clocks: required clock
- clock-names: must contain iface entry
@@ -16,12 +16,16 @@ Required properties:
Optional properties:
- qcom,crci : indicates CRCI MUX value for QUP CRCI ports. Please reference
dt-bindings/soc/qcom,gsbi.h for valid CRCI mux values.
+- syscon-tcsr: indicates phandle of TCSR syscon node. Required if child uses
+ dma.
Required properties if child node exists:
- #address-cells: Must be 1
- #size-cells: Must be 1
- ranges: Must be present
+Note: Each GSBI should have an alias correctly numbered in aliases node.
+
Properties for children:
A GSBI controller node can contain 0 or more child nodes representing serial
@@ -37,6 +41,10 @@ Example for APQ8064:
#include dt-bindings/soc/qcom,gsbi.h
+ aliases {
+ gsbi4 = gsbi4;
+ };
You appear to be using the alias name to determine a index number for the gsbi,
if that is the case, than you should probably just add a cell-index node to the
gsbi’s for this purpose.
+
gsbi4@1630 {
compatible = qcom,gsbi-v1.0.0;
reg = 0x1630 0x100;
@@ -48,6 +56,8 @@ Example for APQ8064:
qcom,mode = GSBI_PROT_I2C_UART;
qcom,crci = GSBI_CRCI_QUP;
+ syscon-tcsr = tcsr;
+
/* child nodes go under here */
i2c_qup4: i2c@1638 {
@@ -76,3 +86,9 @@ Example for APQ8064:
};
};
+ tcsr: syscon@1a40 {
+ compatible = qcom,apq8064-tcsr, syscon;
+ reg = 0x1a40 0x100;
+ };
+
+
- 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: [Patch v2 1/6] soc: qcom: gsbi: Add support for ADM CRCI muxing
On Jan 30, 2015, at 3:37 PM, Stephen Boyd sb...@codeaurora.org wrote:
On 01/30/15 08:32, Kumar Gala wrote:
On Jan 30, 2015, at 12:25 AM, Andy Gross agr...@codeaurora.org wrote:
Required properties if child node exists:
- #address-cells: Must be 1
- #size-cells: Must be 1
- ranges: Must be present
+Note: Each GSBI should have an alias correctly numbered in aliases node.
+
Properties for children:
A GSBI controller node can contain 0 or more child nodes representing serial
@@ -37,6 +41,10 @@ Example for APQ8064:
#include dt-bindings/soc/qcom,gsbi.h
+ aliases {
+ gsbi4 = gsbi4;
+ };
You appear to be using the alias name to determine a index number for the
gsbi, if that is the case, than you should probably just add a cell-index
node to the gsbi’s for this purpose.
I thought cell-index was deprecated and referred more to things like
enumerating all the devices on a bus by assigning them a unique ID.
Aliases, on the other hand, allow us to enumerate a subset of devices
that share the same bus with other devices of different types. For
example, how would I know that a device is gsbi1 vs serial1 if they both
used cell-index and they both had the same parent node?
I think the problem was cell-index was never well understood and abused. For
the example you are giving you wouldn’t use cell-index because you are talking
about things that would have different compatibles. For what it appears we
really are enumerating the GSBI hardware to match some programming interface
convention. If that is the case than I think cell-index is proper.
- 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/
[GIT PULL] qcom SoC changes for v3.20-2
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) Qualcomm ARM Based SoC Updates for v3.20-2 * 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 * Cleaned up some Kconfig options associated with ARCH_QCOM * Added Andy Gross as co-maintainer Andy Gross (1): MAINTAINERS: Add co-maintainer for ARM/Qualcomm Support Lina Iyer (1): ARM: qcom: Add SCM warmboot flags for quad core targets. Olav Haugan (1): ARM: qcom: scm: Add logging of actual return code from scm call Stephen Boyd (8): 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: Clarify boot interface ARM: qcom: Fix SCM interface for big-endian kernels ARM: qcom: Drop unnecessary selects from ARCH_QCOM Vikram Mulukutla (1): ARM: qcom: scm: Flush the command buffer only instead of the entire cache MAINTAINERS | 3 ++ arch/arm/Kconfig.debug| 5 ++- arch/arm/include/debug/msm.S | 6 +++ arch/arm/mach-qcom/Kconfig| 3 +- arch/arm/mach-qcom/scm-boot.c | 10 ++--- arch/arm/mach-qcom/scm-boot.h | 4 +- arch/arm/mach-qcom/scm.c | 85 --- 7 files changed, 77 insertions(+), 39 deletions(-) -- 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: [PATCH] MAINTAINERS: update Qualcomm support entry
On Jan 22, 2015, at 3:46 PM, Andy Gross wrote: > On Wed, Jan 21, 2015 at 08:46:45PM -0800, Joe Perches wrote: >>> +L: linux-...@vger.kernel.org >>> S: Maintained >>> F: arch/arm/mach-qcom/ >>> +F: drivers/soc/qcom >> >> Please add a terminating / >> >> F: drivers/soc/qcom/ > > Noted, will fix. I’ll fix this up when I apply the patch. - 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 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/
[GIT PULL] qcom SoC changes for v3.20-2
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) Qualcomm ARM Based SoC Updates for v3.20-2 * 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 * Cleaned up some Kconfig options associated with ARCH_QCOM * Added Andy Gross as co-maintainer Andy Gross (1): MAINTAINERS: Add co-maintainer for ARM/Qualcomm Support Lina Iyer (1): ARM: qcom: Add SCM warmboot flags for quad core targets. Olav Haugan (1): ARM: qcom: scm: Add logging of actual return code from scm call Stephen Boyd (8): 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: Clarify boot interface ARM: qcom: Fix SCM interface for big-endian kernels ARM: qcom: Drop unnecessary selects from ARCH_QCOM Vikram Mulukutla (1): ARM: qcom: scm: Flush the command buffer only instead of the entire cache MAINTAINERS | 3 ++ arch/arm/Kconfig.debug| 5 ++- arch/arm/include/debug/msm.S | 6 +++ arch/arm/mach-qcom/Kconfig| 3 +- arch/arm/mach-qcom/scm-boot.c | 10 ++--- arch/arm/mach-qcom/scm-boot.h | 4 +- arch/arm/mach-qcom/scm.c | 85 --- 7 files changed, 77 insertions(+), 39 deletions(-) -- 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 Jan 22, 2015, at 9:00 PM, Olof Johansson o...@lixom.net wrote: On Thu, Jan 22, 2015 at 9:02 AM, Kumar Gala ga...@codeaurora.org wrote: On Jan 21, 2015, at 7:15 PM, Olof Johansson o...@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 -- 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: [PATCH] MAINTAINERS: update Qualcomm support entry
On Jan 22, 2015, at 3:46 PM, Andy Gross agr...@codeaurora.org wrote: On Wed, Jan 21, 2015 at 08:46:45PM -0800, Joe Perches wrote: +L: linux-...@vger.kernel.org S: Maintained F: arch/arm/mach-qcom/ +F: drivers/soc/qcom Please add a terminating / F: drivers/soc/qcom/ Noted, will fix. I’ll fix this up when I apply the patch. - 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: [PATCH v2] ARM: qcom: Fix SCM interface for big-endian kernels
On Jan 21, 2015, at 1:21 PM, Stephen Boyd wrote:
> The secure environment only runs in little-endian mode, so any
> buffers shared with the secure environment should have their
> contents converted to little-endian. We also mark such elements
> with __le32 to allow sparse to catch such problems.
>
> Signed-off-by: Stephen Boyd
> ---
>
> Changes since v1:
> * Rebased onto Kumar's qcom/soc branch
>
> drivers/soc/qcom/scm-boot.c | 8
> drivers/soc/qcom/scm.c | 30 --
> 2 files changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/soc/qcom/scm-boot.c b/drivers/soc/qcom/scm-boot.c
> index 1822b13bbc10..af16fcc8d5cb 100644
> --- a/drivers/soc/qcom/scm-boot.c
> +++ b/drivers/soc/qcom/scm-boot.c
> @@ -27,12 +27,12 @@
> int scm_set_boot_addr(u32 addr, int flags)
> {
> struct {
> - unsigned int flags;
> - phys_addr_t addr;
> + __le32 flags;
> + __le32 addr;
How does this work? How can we go from phys_addr_t back to __le32 on LPAE or
64-bit systems?
> } cmd;
>
> - cmd.addr = addr;
> - cmd.flags = flags;
> + cmd.addr = cpu_to_le32(addr);
> + cmd.flags = cpu_to_le32(flags);
> return scm_call(SCM_SVC_BOOT, SCM_BOOT_ADDR,
> , sizeof(cmd), NULL, 0);
> }
> diff --git a/drivers/soc/qcom/scm.c b/drivers/soc/qcom/scm.c
> index 2e98d80e2387..3e724b8af485 100644
> --- a/drivers/soc/qcom/scm.c
> +++ b/drivers/soc/qcom/scm.c
> @@ -62,11 +62,11 @@ static DEFINE_MUTEX(scm_lock);
> * to access the buffers in a safe manner.
> */
> struct scm_command {
> - u32 len;
> - u32 buf_offset;
> - u32 resp_hdr_offset;
> - u32 id;
> - u32 buf[0];
> + __le32 len;
> + __le32 buf_offset;
> + __le32 resp_hdr_offset;
> + __le32 id;
> + __le32 buf[0];
> };
>
> /**
> @@ -76,9 +76,9 @@ struct scm_command {
> * @is_complete: indicates if the command has finished processing
> */
> struct scm_response {
> - u32 len;
> - u32 buf_offset;
> - u32 is_complete;
> + __le32 len;
> + __le32 buf_offset;
> + __le32 is_complete;
> };
>
> /**
> @@ -96,12 +96,14 @@ static struct scm_command *alloc_scm_command(size_t
> cmd_size, size_t resp_size)
> struct scm_command *cmd;
> size_t len = sizeof(*cmd) + sizeof(struct scm_response) + cmd_size +
> resp_size;
> + u32 offset;
>
> cmd = kzalloc(PAGE_ALIGN(len), GFP_KERNEL);
> if (cmd) {
> - cmd->len = len;
> - cmd->buf_offset = offsetof(struct scm_command, buf);
> - cmd->resp_hdr_offset = cmd->buf_offset + cmd_size;
> + cmd->len = cpu_to_le32(len);
> + offset = offsetof(struct scm_command, buf);
> + cmd->buf_offset = cpu_to_le32(offset);
> + cmd->resp_hdr_offset = cpu_to_le32(offset + cmd_size);
> }
> return cmd;
> }
> @@ -126,7 +128,7 @@ static inline void free_scm_command(struct scm_command
> *cmd)
> static inline struct scm_response *scm_command_to_response(
> const struct scm_command *cmd)
> {
> - return (void *)cmd + cmd->resp_hdr_offset;
> + return (void *)cmd + le32_to_cpu(cmd->resp_hdr_offset);
> }
>
> /**
> @@ -148,7 +150,7 @@ static inline void *scm_get_command_buffer(const struct
> scm_command *cmd)
> */
> static inline void *scm_get_response_buffer(const struct scm_response *rsp)
> {
> - return (void *)rsp + rsp->buf_offset;
> + return (void *)rsp + le32_to_cpu(rsp->buf_offset);
> }
>
> static int scm_remap_error(int err)
> @@ -260,7 +262,7 @@ int scm_call(u32 svc_id, u32 cmd_id, const void *cmd_buf,
> size_t cmd_len,
> if (!cmd)
> return -ENOMEM;
>
> - cmd->id = (svc_id << 10) | cmd_id;
> + cmd->id = cpu_to_le32((svc_id << 10) | cmd_id);
> if (cmd_buf)
> memcpy(scm_get_command_buffer(cmd), cmd_buf, cmd_len);
>
> --
> 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-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 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: [PATCH 8/8] msm: scm: Move the scm driver to drivers/soc/qcom
On Jan 21, 2015, at 7:53 PM, Bjorn Andersson wrote: > On Wed, Jan 21, 2015 at 5:13 PM, Olof Johansson wrote: > [..] >> On Mon, Aug 4, 2014 at 6:31 PM, Stephen Boyd wrote: >>> Architectural changes in the ARM Linux kernel tree mandate >>> the eventual removal of the mach-* directories. Move the >>> scm driver to drivers/soc/qcom and the scm header to >>> include/soc/qcom to support that removal. >> >> The idea is not blindly move one dumping ground to a new place. >> >> I see only two exported functions from scm.c: >> >> scm_get_version: This is not used anywhere in the kernel and can just be >> removed >> scm_call: This is used by scm-boot, and would be better to translate >> over to firmware_ops in the first place. >> > > Hi Olof, > > I started this a while ago, as it felt like the right thing to do . > > The problem with this approach is that e.g. firmware loading is > partially handled through this interface. So implementing a remoteproc > driver for wifi etc required me to add 6 new ops to the struct, > loading the modem looks like it requires one more. HDMI requires one. > > Looking at the downstream branch there's a bunch more (20+), so we > would explode the firmware_ops struct with Qualcomm "specific" ops. > This is not necessarily a bad idea, but needs to be considered before > we jump the gun. > > > I haven't looked at the arm64 stuff in detail, but it looks to be > shared between the two platforms, so either way it seems like the > right approach to have this moved out to drivers/soc/qcom. As Bjorn says the scm interface ends up having a number of qcom specific calls that I don’t think the firmware ops should be implementing. I don’t see any value in adding qcom specific function pointers to the ops struct just to create another level of indirection. I’m fine with adding a firmware_ops implementation that uses scm for those things that firmware_ops has today. However, I’m not clear on what the view of extending firmware_ops to arm64 is. If we do this do we move the firmware_ops code into drivers/soc ? - 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: [PATCH v2] ARM: qcom: Fix SCM interface for big-endian kernels
On Jan 21, 2015, at 1:21 PM, Stephen Boyd sb...@codeaurora.org wrote:
The secure environment only runs in little-endian mode, so any
buffers shared with the secure environment should have their
contents converted to little-endian. We also mark such elements
with __le32 to allow sparse to catch such problems.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
Changes since v1:
* Rebased onto Kumar's qcom/soc branch
drivers/soc/qcom/scm-boot.c | 8
drivers/soc/qcom/scm.c | 30 --
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/soc/qcom/scm-boot.c b/drivers/soc/qcom/scm-boot.c
index 1822b13bbc10..af16fcc8d5cb 100644
--- a/drivers/soc/qcom/scm-boot.c
+++ b/drivers/soc/qcom/scm-boot.c
@@ -27,12 +27,12 @@
int scm_set_boot_addr(u32 addr, int flags)
{
struct {
- unsigned int flags;
- phys_addr_t addr;
+ __le32 flags;
+ __le32 addr;
How does this work? How can we go from phys_addr_t back to __le32 on LPAE or
64-bit systems?
} cmd;
- cmd.addr = addr;
- cmd.flags = flags;
+ cmd.addr = cpu_to_le32(addr);
+ cmd.flags = cpu_to_le32(flags);
return scm_call(SCM_SVC_BOOT, SCM_BOOT_ADDR,
cmd, sizeof(cmd), NULL, 0);
}
diff --git a/drivers/soc/qcom/scm.c b/drivers/soc/qcom/scm.c
index 2e98d80e2387..3e724b8af485 100644
--- a/drivers/soc/qcom/scm.c
+++ b/drivers/soc/qcom/scm.c
@@ -62,11 +62,11 @@ static DEFINE_MUTEX(scm_lock);
* to access the buffers in a safe manner.
*/
struct scm_command {
- u32 len;
- u32 buf_offset;
- u32 resp_hdr_offset;
- u32 id;
- u32 buf[0];
+ __le32 len;
+ __le32 buf_offset;
+ __le32 resp_hdr_offset;
+ __le32 id;
+ __le32 buf[0];
};
/**
@@ -76,9 +76,9 @@ struct scm_command {
* @is_complete: indicates if the command has finished processing
*/
struct scm_response {
- u32 len;
- u32 buf_offset;
- u32 is_complete;
+ __le32 len;
+ __le32 buf_offset;
+ __le32 is_complete;
};
/**
@@ -96,12 +96,14 @@ static struct scm_command *alloc_scm_command(size_t
cmd_size, size_t resp_size)
struct scm_command *cmd;
size_t len = sizeof(*cmd) + sizeof(struct scm_response) + cmd_size +
resp_size;
+ u32 offset;
cmd = kzalloc(PAGE_ALIGN(len), GFP_KERNEL);
if (cmd) {
- cmd-len = len;
- cmd-buf_offset = offsetof(struct scm_command, buf);
- cmd-resp_hdr_offset = cmd-buf_offset + cmd_size;
+ cmd-len = cpu_to_le32(len);
+ offset = offsetof(struct scm_command, buf);
+ cmd-buf_offset = cpu_to_le32(offset);
+ cmd-resp_hdr_offset = cpu_to_le32(offset + cmd_size);
}
return cmd;
}
@@ -126,7 +128,7 @@ static inline void free_scm_command(struct scm_command
*cmd)
static inline struct scm_response *scm_command_to_response(
const struct scm_command *cmd)
{
- return (void *)cmd + cmd-resp_hdr_offset;
+ return (void *)cmd + le32_to_cpu(cmd-resp_hdr_offset);
}
/**
@@ -148,7 +150,7 @@ static inline void *scm_get_command_buffer(const struct
scm_command *cmd)
*/
static inline void *scm_get_response_buffer(const struct scm_response *rsp)
{
- return (void *)rsp + rsp-buf_offset;
+ return (void *)rsp + le32_to_cpu(rsp-buf_offset);
}
static int scm_remap_error(int err)
@@ -260,7 +262,7 @@ int scm_call(u32 svc_id, u32 cmd_id, const void *cmd_buf,
size_t cmd_len,
if (!cmd)
return -ENOMEM;
- cmd-id = (svc_id 10) | cmd_id;
+ cmd-id = cpu_to_le32((svc_id 10) | cmd_id);
if (cmd_buf)
memcpy(scm_get_command_buffer(cmd), cmd_buf, cmd_len);
--
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-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 Jan 21, 2015, at 7:15 PM, Olof Johansson o...@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 -- 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: [PATCH 8/8] msm: scm: Move the scm driver to drivers/soc/qcom
On Jan 21, 2015, at 7:53 PM, Bjorn Andersson bj...@kryo.se wrote: On Wed, Jan 21, 2015 at 5:13 PM, Olof Johansson o...@lixom.net wrote: [..] On Mon, Aug 4, 2014 at 6:31 PM, Stephen Boyd sb...@codeaurora.org wrote: Architectural changes in the ARM Linux kernel tree mandate the eventual removal of the mach-* directories. Move the scm driver to drivers/soc/qcom and the scm header to include/soc/qcom to support that removal. The idea is not blindly move one dumping ground to a new place. I see only two exported functions from scm.c: scm_get_version: This is not used anywhere in the kernel and can just be removed scm_call: This is used by scm-boot, and would be better to translate over to firmware_ops in the first place. Hi Olof, I started this a while ago, as it felt like the right thing to do tm. The problem with this approach is that e.g. firmware loading is partially handled through this interface. So implementing a remoteproc driver for wifi etc required me to add 6 new ops to the struct, loading the modem looks like it requires one more. HDMI requires one. Looking at the downstream branch there's a bunch more (20+), so we would explode the firmware_ops struct with Qualcomm specific ops. This is not necessarily a bad idea, but needs to be considered before we jump the gun. I haven't looked at the arm64 stuff in detail, but it looks to be shared between the two platforms, so either way it seems like the right approach to have this moved out to drivers/soc/qcom. As Bjorn says the scm interface ends up having a number of qcom specific calls that I don’t think the firmware ops should be implementing. I don’t see any value in adding qcom specific function pointers to the ops struct just to create another level of indirection. I’m fine with adding a firmware_ops implementation that uses scm for those things that firmware_ops has today. However, I’m not clear on what the view of extending firmware_ops to arm64 is. If we do this do we move the firmware_ops code into drivers/soc ? - 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/
[GIT PULL] qcom SoC changes for v3.20
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
--
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/
[GIT PULL] qcom DT changes for v3.20
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-dt-for-3.20 for you to fetch changes up to bb901bd6596e93fc2e0fc6da2f367a651bd8d16e: ARM: dts: qcom: Correct IPQ8064 tlmm interrupt (2015-01-19 12:11:41 -0600) Qualcomm ARM Based Device Tree Updates for v3.20 * Correct IPQ8064 tlmm interrupt * Add Support for SD Card Detect for ifc6410 board Pramod Gurav (1): ARM: dts: qcom: Add Support for SD Card Detect for ifc6410 board Stephen Boyd (1): ARM: dts: qcom: Correct IPQ8064 tlmm interrupt arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 12 arch/arm/boot/dts/qcom-ipq8064.dtsi| 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) -- 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/
[GIT PULL] qcom DT changes for v3.20
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-dt-for-3.20 for you to fetch changes up to bb901bd6596e93fc2e0fc6da2f367a651bd8d16e: ARM: dts: qcom: Correct IPQ8064 tlmm interrupt (2015-01-19 12:11:41 -0600) Qualcomm ARM Based Device Tree Updates for v3.20 * Correct IPQ8064 tlmm interrupt * Add Support for SD Card Detect for ifc6410 board Pramod Gurav (1): ARM: dts: qcom: Add Support for SD Card Detect for ifc6410 board Stephen Boyd (1): ARM: dts: qcom: Correct IPQ8064 tlmm interrupt arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 12 arch/arm/boot/dts/qcom-ipq8064.dtsi| 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) -- 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/
[GIT PULL] qcom SoC changes for v3.20
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
--
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: [PATCH v5 1/4] phy: qcom-ufs: add support for 20nm phy
On Jan 7, 2015, at 9:43 AM, Yaniv Gardi wrote:
> This change adds a support for a 20nm qcom-ufs phy that is
> required in platforms that use ufs-qcom controller.
>
> Signed-off-by: Yaniv Gardi
>
> ---
> drivers/phy/Makefile| 2 +
> drivers/phy/phy-qcom-ufs-i.h| 167
Curious, if the ‘-i’ in name means anything, or if we could just call this
phy-qcom-ufs.h
> drivers/phy/phy-qcom-ufs-qmp-20nm.c | 257 +
> drivers/phy/phy-qcom-ufs-qmp-20nm.h | 235
> drivers/phy/phy-qcom-ufs.c | 745
> include/linux/phy/phy-qcom-ufs.h| 33 ++
> 6 files changed, 1439 insertions(+)
> create mode 100644 drivers/phy/phy-qcom-ufs-i.h
> create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.c
> create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.h
> create mode 100644 drivers/phy/phy-qcom-ufs.c
> create mode 100644 include/linux/phy/phy-qcom-ufs.h
>
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index aa74f96..ba94e85 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -34,3 +34,5 @@ obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)+=
> phy-spear1340-miphy.o
> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
> obj-$(CONFIG_PHY_STIH407_USB) += phy-stih407-usb.o
> obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
> +obj-$(CONFIG_SCSI_UFS_QCOM) += phy-qcom-ufs.o
> +obj-$(CONFIG_SCSI_UFS_QCOM) += phy-qcom-ufs-qmp-20nm.o
> diff --git a/drivers/phy/phy-qcom-ufs-i.h b/drivers/phy/phy-qcom-ufs-i.h
> new file mode 100644
> index 000..50f1fdc
> --- /dev/null
> +++ b/drivers/phy/phy-qcom-ufs-i.h
> @@ -0,0 +1,167 @@
> +/*
> + * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#ifndef UFS_QCOM_PHY_I_H_
> +#define UFS_QCOM_PHY_I_H_
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us) \
> +({ \
> + ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
> + might_sleep_if(timeout_us); \
> + for (;;) { \
> + (val) = readl(addr); \
> + if (cond) \
> + break; \
> + if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
> + (val) = readl(addr); \
> + break; \
> + } \
> + if (sleep_us) \
> + usleep_range(DIV_ROUND_UP(sleep_us, 4), sleep_us); \
> + } \
> + (cond) ? 0 : -ETIMEDOUT; \
> +})
We have a version of this in drivers/phy/phy-qcom-apq8064-sata.c, can we pull
them out into something like include/asm-generic/io.h
> +
> +#define UFS_QCOM_PHY_CAL_ENTRY(reg, val) \
> + { \
> + .reg_offset = reg, \
> + .cfg_value = val, \
> + }
> +
> +#define UFS_QCOM_PHY_NAME_LEN30
> +
> +enum {
> + MASK_SERDES_START = 0x1,
> + MASK_PCS_READY = 0x1,
> +};
> +
> +enum {
> + OFFSET_SERDES_START = 0x0,
> +};
Any reason these aren’t #defines?
> +
> +struct ufs_qcom_phy_stored_attributes {
> + u32 att;
> + u32 value;
> +};
> +
> +struct ufs_qcom_phy_calibration {
> + u32 reg_offset;
> + u32 cfg_value;
> +};
> +
> +struct ufs_qcom_phy_vreg {
> + const char *name;
> + struct regulator *reg;
> + int max_uA;
> + int min_uV;
> + int max_uV;
> + bool enabled;
> + bool is_always_on;
> +};
> +
> +struct ufs_qcom_phy {
> + struct list_head list;
> + struct device *dev;
> + void __iomem *mmio;
> + void __iomem *dev_ref_clk_ctrl_mmio;
> + struct clk *tx_iface_clk;
> + struct clk *rx_iface_clk;
> + bool is_iface_clk_enabled;
> + struct clk *ref_clk_src;
> + struct clk *ref_clk_parent;
> + struct clk *ref_clk;
> + bool is_ref_clk_enabled;
> + bool is_dev_ref_clk_enabled;
> + struct ufs_qcom_phy_vreg vdda_pll;
> + struct ufs_qcom_phy_vreg vdda_phy;
> + struct ufs_qcom_phy_vreg vddp_ref_clk;
> + unsigned int quirks;
> + u8 host_ctrl_rev_major;
> + u16 host_ctrl_rev_minor;
> + u16 host_ctrl_rev_step;
> +
> + /*
> + * If UFS PHY power down is deasserted and power is restored to analog
> + * circuits, the rx_sigdet can glitch. If the glitch is wide enough,
> + * it can trigger the digital logic to think it saw a DIF-N and cause
> + * it to exit Hibern8.
Re: [PATCH v5 1/4] phy: qcom-ufs: add support for 20nm phy
On Jan 7, 2015, at 9:43 AM, Yaniv Gardi yga...@qti.qualcomm.com wrote:
This change adds a support for a 20nm qcom-ufs phy that is
required in platforms that use ufs-qcom controller.
Signed-off-by: Yaniv Gardi yga...@codeaurora.org
---
drivers/phy/Makefile| 2 +
drivers/phy/phy-qcom-ufs-i.h| 167
Curious, if the ‘-i’ in name means anything, or if we could just call this
phy-qcom-ufs.h
drivers/phy/phy-qcom-ufs-qmp-20nm.c | 257 +
drivers/phy/phy-qcom-ufs-qmp-20nm.h | 235
drivers/phy/phy-qcom-ufs.c | 745
include/linux/phy/phy-qcom-ufs.h| 33 ++
6 files changed, 1439 insertions(+)
create mode 100644 drivers/phy/phy-qcom-ufs-i.h
create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.c
create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.h
create mode 100644 drivers/phy/phy-qcom-ufs.c
create mode 100644 include/linux/phy/phy-qcom-ufs.h
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index aa74f96..ba94e85 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -34,3 +34,5 @@ obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)+=
phy-spear1340-miphy.o
obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
obj-$(CONFIG_PHY_STIH407_USB) += phy-stih407-usb.o
obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
+obj-$(CONFIG_SCSI_UFS_QCOM) += phy-qcom-ufs.o
+obj-$(CONFIG_SCSI_UFS_QCOM) += phy-qcom-ufs-qmp-20nm.o
diff --git a/drivers/phy/phy-qcom-ufs-i.h b/drivers/phy/phy-qcom-ufs-i.h
new file mode 100644
index 000..50f1fdc
--- /dev/null
+++ b/drivers/phy/phy-qcom-ufs-i.h
@@ -0,0 +1,167 @@
+/*
+ * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef UFS_QCOM_PHY_I_H_
+#define UFS_QCOM_PHY_I_H_
+
+#include linux/module.h
+#include linux/clk.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+
+#include linux/phy/phy-qcom-ufs.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/delay.h
+
+#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us) \
+({ \
+ ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+ might_sleep_if(timeout_us); \
+ for (;;) { \
+ (val) = readl(addr); \
+ if (cond) \
+ break; \
+ if (timeout_us ktime_compare(ktime_get(), timeout) 0) { \
+ (val) = readl(addr); \
+ break; \
+ } \
+ if (sleep_us) \
+ usleep_range(DIV_ROUND_UP(sleep_us, 4), sleep_us); \
+ } \
+ (cond) ? 0 : -ETIMEDOUT; \
+})
We have a version of this in drivers/phy/phy-qcom-apq8064-sata.c, can we pull
them out into something like include/asm-generic/io.h
+
+#define UFS_QCOM_PHY_CAL_ENTRY(reg, val) \
+ { \
+ .reg_offset = reg, \
+ .cfg_value = val, \
+ }
+
+#define UFS_QCOM_PHY_NAME_LEN30
+
+enum {
+ MASK_SERDES_START = 0x1,
+ MASK_PCS_READY = 0x1,
+};
+
+enum {
+ OFFSET_SERDES_START = 0x0,
+};
Any reason these aren’t #defines?
+
+struct ufs_qcom_phy_stored_attributes {
+ u32 att;
+ u32 value;
+};
+
+struct ufs_qcom_phy_calibration {
+ u32 reg_offset;
+ u32 cfg_value;
+};
+
+struct ufs_qcom_phy_vreg {
+ const char *name;
+ struct regulator *reg;
+ int max_uA;
+ int min_uV;
+ int max_uV;
+ bool enabled;
+ bool is_always_on;
+};
+
+struct ufs_qcom_phy {
+ struct list_head list;
+ struct device *dev;
+ void __iomem *mmio;
+ void __iomem *dev_ref_clk_ctrl_mmio;
+ struct clk *tx_iface_clk;
+ struct clk *rx_iface_clk;
+ bool is_iface_clk_enabled;
+ struct clk *ref_clk_src;
+ struct clk *ref_clk_parent;
+ struct clk *ref_clk;
+ bool is_ref_clk_enabled;
+ bool is_dev_ref_clk_enabled;
+ struct ufs_qcom_phy_vreg vdda_pll;
+ struct ufs_qcom_phy_vreg vdda_phy;
+ struct ufs_qcom_phy_vreg vddp_ref_clk;
+ unsigned int quirks;
+ u8 host_ctrl_rev_major;
+ u16 host_ctrl_rev_minor;
+ u16 host_ctrl_rev_step;
+
+ /*
+ * If UFS PHY power down is deasserted and power is restored to analog
+ * circuits, the rx_sigdet can glitch. If the glitch is wide enough,
+ * it can trigger the digital logic to think it saw a DIF-N and
Re: [PATCH] soc: Include drivers/soc/Kconfig only once
Acked-by: Kumar Gala - k On Nov 5, 2014, at 9:32 AM, Andreas Larsson wrote: > Signed-off-by: Andreas Larsson > --- > drivers/Kconfig |2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/Kconfig b/drivers/Kconfig > index 1a693d3..622fa26 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -148,8 +148,6 @@ source "drivers/remoteproc/Kconfig" > > source "drivers/rpmsg/Kconfig" > > -source "drivers/soc/Kconfig" > - > source "drivers/devfreq/Kconfig" > > source "drivers/extcon/Kconfig" > -- > 1.7.10.4 > -- 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: [PATCH] soc: Include drivers/soc/Kconfig only once
Acked-by: Kumar Gala ga...@codeaurora.org - k On Nov 5, 2014, at 9:32 AM, Andreas Larsson andr...@gaisler.com wrote: Signed-off-by: Andreas Larsson andr...@gaisler.com --- drivers/Kconfig |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/Kconfig b/drivers/Kconfig index 1a693d3..622fa26 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -148,8 +148,6 @@ source drivers/remoteproc/Kconfig source drivers/rpmsg/Kconfig -source drivers/soc/Kconfig - source drivers/devfreq/Kconfig source drivers/extcon/Kconfig -- 1.7.10.4 -- 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: [PATCH v3 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions
On Nov 5, 2014, at 6:55 AM, Ankit Jindal wrote: > Hi Kumar, > > On 31 October 2014 19:09, Kumar Gala wrote: >> >> On Oct 31, 2014, at 4:30 AM, Ankit Jindal wrote: >> >>> Hi Kumar, >>> >>> On 21 October 2014 12:08, Kumar Gala wrote: >>>> >>>> On Oct 21, 2014, at 7:56 AM, Ankit Jindal wrote: >>>> >>>>> Currently, three types of mem regions are supported: UIO_MEM_PHYS, >>>>> UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps >>>>> UIO driver export physcial memory to user space as non-cacheable >>>>> user memory. Typcially memory-mapped registers of a device are exported >>>>> to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type >>>>> is not efficient if dma-capable devices are capable of maintaining >>>>> coherency >>>>> with CPU caches. >>>>> >>>>> This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable >>>>> cacheable access to physical memory from user space. >>>>> >>>>> Signed-off-by: Ankit Jindal >>>>> Signed-off-by: Tushar Jagad >>>>> --- >>>>> drivers/uio/uio.c | 11 --- >>>>> include/linux/uio_driver.h |1 + >>>>> 2 files changed, 9 insertions(+), 3 deletions(-) >>>> >>>> Rather than adding a new type, why not allow the driver to set the pgprot >>>> value, this way one has full control and we don’t need to keep adding >>>> types for various different cache attributions in the future. >>> >>> Do you mean to add a new field pgprot_t in the memtype structure and >>> uio_mmap_physical will set vma->vm_page_prot to this value provided by >>> driver ? If this is the case then we will need to change all the >>> current uio based drivers which was the reason I preferred to have a >>> new mem type. >>> >>> Please let me know if I have misunderstood anything. >> >> I’m suggeting in uio_mmap_physical to do something like: >> >> if (idev->info->set_pgprot) >>idev->info->set_pgprot(vma->vm_page_prot) >> else >>vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >> >> And add a set_prprot callback to 'struct uio_info’. >> >> Here’s patch from several years ago: >> >> http://patchwork.ozlabs.org/patch/119224/ > > The suggested solution looks okey but not sure whether there is any > available drivers using different combinations. Also, I looked at the > available pgprot routines, looks like only pgprot_noncached and > pgprot_writecombine are the available ones. So if we are not going to > use these pgprot routines then driver might have architecture > dependent switches, which we should avoid. There are cases that are arch/driver specific that do not fall into pgprot_noncached or pgprot_writecombine. So I don’t see why we should limit them. For example the Freescale networking guys need cacheable-noncoherent for some of their UIO work. We can deal with arch specific issues during review of the UIO driver themselves. - 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: [PATCH v3 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions
On Nov 5, 2014, at 6:55 AM, Ankit Jindal ankit.jin...@linaro.org wrote: Hi Kumar, On 31 October 2014 19:09, Kumar Gala ga...@codeaurora.org wrote: On Oct 31, 2014, at 4:30 AM, Ankit Jindal ankit.jin...@linaro.org wrote: Hi Kumar, On 21 October 2014 12:08, Kumar Gala ga...@codeaurora.org wrote: On Oct 21, 2014, at 7:56 AM, Ankit Jindal ankit.jin...@linaro.org wrote: Currently, three types of mem regions are supported: UIO_MEM_PHYS, UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps UIO driver export physcial memory to user space as non-cacheable user memory. Typcially memory-mapped registers of a device are exported to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type is not efficient if dma-capable devices are capable of maintaining coherency with CPU caches. This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable cacheable access to physical memory from user space. Signed-off-by: Ankit Jindal ankit.jin...@linaro.org Signed-off-by: Tushar Jagad tushar.ja...@linaro.org --- drivers/uio/uio.c | 11 --- include/linux/uio_driver.h |1 + 2 files changed, 9 insertions(+), 3 deletions(-) Rather than adding a new type, why not allow the driver to set the pgprot value, this way one has full control and we don’t need to keep adding types for various different cache attributions in the future. Do you mean to add a new field pgprot_t in the memtype structure and uio_mmap_physical will set vma-vm_page_prot to this value provided by driver ? If this is the case then we will need to change all the current uio based drivers which was the reason I preferred to have a new mem type. Please let me know if I have misunderstood anything. I’m suggeting in uio_mmap_physical to do something like: if (idev-info-set_pgprot) idev-info-set_pgprot(vma-vm_page_prot) else vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); And add a set_prprot callback to 'struct uio_info’. Here’s patch from several years ago: http://patchwork.ozlabs.org/patch/119224/ The suggested solution looks okey but not sure whether there is any available drivers using different combinations. Also, I looked at the available pgprot routines, looks like only pgprot_noncached and pgprot_writecombine are the available ones. So if we are not going to use these pgprot routines then driver might have architecture dependent switches, which we should avoid. There are cases that are arch/driver specific that do not fall into pgprot_noncached or pgprot_writecombine. So I don’t see why we should limit them. For example the Freescale networking guys need cacheable-noncoherent for some of their UIO work. We can deal with arch specific issues during review of the UIO driver themselves. - 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: [PATCH v3 1/3] QE: move qe code from arch/powerpc to drivers/soc
On Oct 31, 2014, at 2:24 AM, qiang.z...@freescale.com wrote:
> On Oct 30, 2014, at 9:37 AM, Kumar Gala wrote:
>
>
>> -Original Message-
>> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
>> Sent: Thursday, October 30, 2014 9:37 PM
>> To: Zhao Qiang-B45475
>> Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org; Wood
>> Scott-B07421; Xie Xiaobo-R63061
>> Subject: Re: [PATCH v3 1/3] QE: move qe code from arch/powerpc to
>> drivers/soc
>>
>>
>> On Oct 30, 2014, at 2:31 AM, Zhao Qiang wrote:
>>
>>> LS1 is arm cpu and it has qe ip block.
>>> move qe code from platform directory to public directory.
>>>
>>> QE is an IP block integrates several comunications peripheral
>>> controllers. It can implement a variety of applications, such as uart,
>>> usb and tdm and so on.
>>>
>>> Signed-off-by: Zhao Qiang
>>> ---
>>> Changes for v2:
>>> - move code to driver/soc
>>> Changes for v3:
>>> - change drivers/soc/qe to drivers/soc/fsl-qe
>>>
>>> arch/powerpc/Kconfig | 2 -
>>> arch/powerpc/platforms/83xx/km83xx.c | 4 +-
>>> arch/powerpc/platforms/83xx/misc.c | 2 +-
>>> arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 +-
>>> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 +-
>>> arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 +-
>>> arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 +-
>>> arch/powerpc/platforms/85xx/common.c | 2 +-
>>> arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
>>> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +-
>>> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +-
>>> arch/powerpc/platforms/85xx/twr_p102x.c| 4 +-
>>> arch/powerpc/platforms/Kconfig | 19 -
>>> arch/powerpc/sysdev/Makefile | 1 -
>>> arch/powerpc/sysdev/qe_lib/Kconfig | 27 -
>>> drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
>>> drivers/net/ethernet/freescale/ucc_geth.c | 8 ++--
>>> drivers/net/ethernet/freescale/ucc_geth.h | 8 ++--
>>> drivers/soc/Kconfig| 2 +
>>> drivers/soc/Makefile | 1 +
>>> drivers/soc/fsl-qe/Kconfig | 45
>> ++
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/Makefile | 0
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/gpio.c| 2 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe.c | 4 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.c | 2 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.h | 2 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_io.c | 2 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/ucc.c | 6 +--
>>> .../qe_lib => drivers/soc/fsl-qe}/ucc_fast.c | 8 ++--
>>> .../qe_lib => drivers/soc/fsl-qe}/ucc_slow.c | 8 ++--
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/usb.c | 4 +-
>>> drivers/spi/spi-fsl-cpm.c | 2 +-
>>> drivers/tty/serial/ucc_uart.c | 2 +-
>>> drivers/usb/gadget/fsl_qe_udc.c| 2 +-
>>> drivers/usb/host/fhci-hcd.c| 2 +-
>>> drivers/usb/host/fhci-hub.c| 2 +-
>>> drivers/usb/host/fhci-sched.c | 2 +-
>>> drivers/usb/host/fhci.h| 4 +-
>>> .../include/asm => include/linux/fsl}/immap_qe.h | 0
>>> .../powerpc/include/asm => include/linux/fsl}/qe.h | 2 +-
>>> .../include/asm => include/linux/fsl}/qe_ic.h | 0
>>> .../include/asm => include/linux/fsl}/ucc.h| 4 +-
>>> .../include/asm => include/linux/fsl}/ucc_fast.h | 6 +--
>>> .../include/asm => include/linux/fsl}/ucc_slow.h | 6 +--
>>> 44 files changed, 112 insertions(+), 113 deletions(-) delete mode
>>> 100644 arch/powerpc/sysdev/qe_lib/Kconfig
>>> create mode 100644 drivers/soc/fsl-qe/Kconfig rename
>>> {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/Makefile (100%)
>>> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/gpio.c (99%)
>>> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe.c (99%)
>>> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.c
>>
Re: [PATCH v3 1/3] QE: move qe code from arch/powerpc to drivers/soc
On Oct 31, 2014, at 2:24 AM, qiang.z...@freescale.com wrote:
On Oct 30, 2014, at 9:37 AM, Kumar Gala wrote:
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Thursday, October 30, 2014 9:37 PM
To: Zhao Qiang-B45475
Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org; Wood
Scott-B07421; Xie Xiaobo-R63061
Subject: Re: [PATCH v3 1/3] QE: move qe code from arch/powerpc to
drivers/soc
On Oct 30, 2014, at 2:31 AM, Zhao Qiang b45...@freescale.com wrote:
LS1 is arm cpu and it has qe ip block.
move qe code from platform directory to public directory.
QE is an IP block integrates several comunications peripheral
controllers. It can implement a variety of applications, such as uart,
usb and tdm and so on.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
Changes for v2:
- move code to driver/soc
Changes for v3:
- change drivers/soc/qe to drivers/soc/fsl-qe
arch/powerpc/Kconfig | 2 -
arch/powerpc/platforms/83xx/km83xx.c | 4 +-
arch/powerpc/platforms/83xx/misc.c | 2 +-
arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 +-
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 +-
arch/powerpc/platforms/85xx/common.c | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +-
arch/powerpc/platforms/85xx/twr_p102x.c| 4 +-
arch/powerpc/platforms/Kconfig | 19 -
arch/powerpc/sysdev/Makefile | 1 -
arch/powerpc/sysdev/qe_lib/Kconfig | 27 -
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 8 ++--
drivers/net/ethernet/freescale/ucc_geth.h | 8 ++--
drivers/soc/Kconfig| 2 +
drivers/soc/Makefile | 1 +
drivers/soc/fsl-qe/Kconfig | 45
++
.../sysdev/qe_lib = drivers/soc/fsl-qe}/Makefile | 0
.../sysdev/qe_lib = drivers/soc/fsl-qe}/gpio.c| 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe.c | 4 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.c | 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.h | 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe_io.c | 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/ucc.c | 6 +--
.../qe_lib = drivers/soc/fsl-qe}/ucc_fast.c | 8 ++--
.../qe_lib = drivers/soc/fsl-qe}/ucc_slow.c | 8 ++--
.../sysdev/qe_lib = drivers/soc/fsl-qe}/usb.c | 4 +-
drivers/spi/spi-fsl-cpm.c | 2 +-
drivers/tty/serial/ucc_uart.c | 2 +-
drivers/usb/gadget/fsl_qe_udc.c| 2 +-
drivers/usb/host/fhci-hcd.c| 2 +-
drivers/usb/host/fhci-hub.c| 2 +-
drivers/usb/host/fhci-sched.c | 2 +-
drivers/usb/host/fhci.h| 4 +-
.../include/asm = include/linux/fsl}/immap_qe.h | 0
.../powerpc/include/asm = include/linux/fsl}/qe.h | 2 +-
.../include/asm = include/linux/fsl}/qe_ic.h | 0
.../include/asm = include/linux/fsl}/ucc.h| 4 +-
.../include/asm = include/linux/fsl}/ucc_fast.h | 6 +--
.../include/asm = include/linux/fsl}/ucc_slow.h | 6 +--
44 files changed, 112 insertions(+), 113 deletions(-) delete mode
100644 arch/powerpc/sysdev/qe_lib/Kconfig
create mode 100644 drivers/soc/fsl-qe/Kconfig rename
{arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/Makefile (100%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/gpio.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.c
(99%) rename {arch/powerpc/sysdev/qe_lib =
drivers/soc/fsl-qe}/qe_ic.h (98%) rename {arch/powerpc/sysdev/qe_lib
= drivers/soc/fsl-qe}/qe_io.c (99%) rename
{arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/ucc.c (98%) rename
{arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/ucc_fast.c (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/ucc_slow.c
(98%) rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/usb.c
(96%) rename {arch/powerpc/include/asm =
include/linux/fsl}/immap_qe.h (100%) rename {arch/powerpc/include/asm
= include/linux/fsl}/qe.h (99%) rename {arch/powerpc/include/asm =
include/linux/fsl}/qe_ic.h (100%) rename {arch/powerpc/include/asm =
include/linux/fsl}/ucc.h (96%) rename {arch/powerpc/include/asm =
include/linux/fsl}/ucc_fast.h (98%) rename {arch/powerpc/include/asm
= include/linux/fsl}/ucc_slow.h (99%)
So you should be moving things to drivers/soc/fsl/qe/ not
drivers/soc/fsl-qe
Re: [PATCH v3 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions
On Oct 31, 2014, at 4:30 AM, Ankit Jindal wrote: > Hi Kumar, > > On 21 October 2014 12:08, Kumar Gala wrote: >> >> On Oct 21, 2014, at 7:56 AM, Ankit Jindal wrote: >> >>> Currently, three types of mem regions are supported: UIO_MEM_PHYS, >>> UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps >>> UIO driver export physcial memory to user space as non-cacheable >>> user memory. Typcially memory-mapped registers of a device are exported >>> to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type >>> is not efficient if dma-capable devices are capable of maintaining coherency >>> with CPU caches. >>> >>> This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable >>> cacheable access to physical memory from user space. >>> >>> Signed-off-by: Ankit Jindal >>> Signed-off-by: Tushar Jagad >>> --- >>> drivers/uio/uio.c | 11 --- >>> include/linux/uio_driver.h |1 + >>> 2 files changed, 9 insertions(+), 3 deletions(-) >> >> Rather than adding a new type, why not allow the driver to set the pgprot >> value, this way one has full control and we don’t need to keep adding types >> for various different cache attributions in the future. > > Do you mean to add a new field pgprot_t in the memtype structure and > uio_mmap_physical will set vma->vm_page_prot to this value provided by > driver ? If this is the case then we will need to change all the > current uio based drivers which was the reason I preferred to have a > new mem type. > > Please let me know if I have misunderstood anything. I’m suggeting in uio_mmap_physical to do something like: if (idev->info->set_pgprot) idev->info->set_pgprot(vma->vm_page_prot) else vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); And add a set_prprot callback to 'struct uio_info’. Here’s patch from several years ago: http://patchwork.ozlabs.org/patch/119224/ - 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: [PATCH v3 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions
On Oct 31, 2014, at 4:30 AM, Ankit Jindal ankit.jin...@linaro.org wrote: Hi Kumar, On 21 October 2014 12:08, Kumar Gala ga...@codeaurora.org wrote: On Oct 21, 2014, at 7:56 AM, Ankit Jindal ankit.jin...@linaro.org wrote: Currently, three types of mem regions are supported: UIO_MEM_PHYS, UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps UIO driver export physcial memory to user space as non-cacheable user memory. Typcially memory-mapped registers of a device are exported to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type is not efficient if dma-capable devices are capable of maintaining coherency with CPU caches. This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable cacheable access to physical memory from user space. Signed-off-by: Ankit Jindal ankit.jin...@linaro.org Signed-off-by: Tushar Jagad tushar.ja...@linaro.org --- drivers/uio/uio.c | 11 --- include/linux/uio_driver.h |1 + 2 files changed, 9 insertions(+), 3 deletions(-) Rather than adding a new type, why not allow the driver to set the pgprot value, this way one has full control and we don’t need to keep adding types for various different cache attributions in the future. Do you mean to add a new field pgprot_t in the memtype structure and uio_mmap_physical will set vma-vm_page_prot to this value provided by driver ? If this is the case then we will need to change all the current uio based drivers which was the reason I preferred to have a new mem type. Please let me know if I have misunderstood anything. I’m suggeting in uio_mmap_physical to do something like: if (idev-info-set_pgprot) idev-info-set_pgprot(vma-vm_page_prot) else vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); And add a set_prprot callback to 'struct uio_info’. Here’s patch from several years ago: http://patchwork.ozlabs.org/patch/119224/ - 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: [PATCH v3 1/3] QE: move qe code from arch/powerpc to drivers/soc
On Oct 30, 2014, at 2:31 AM, Zhao Qiang wrote:
> LS1 is arm cpu and it has qe ip block.
> move qe code from platform directory to public directory.
>
> QE is an IP block integrates several comunications peripheral
> controllers. It can implement a variety of applications, such
> as uart, usb and tdm and so on.
>
> Signed-off-by: Zhao Qiang
> ---
> Changes for v2:
> - move code to driver/soc
> Changes for v3:
> - change drivers/soc/qe to drivers/soc/fsl-qe
>
> arch/powerpc/Kconfig | 2 -
> arch/powerpc/platforms/83xx/km83xx.c | 4 +-
> arch/powerpc/platforms/83xx/misc.c | 2 +-
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 +-
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 +-
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 +-
> arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 +-
> arch/powerpc/platforms/85xx/common.c | 2 +-
> arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +-
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +-
> arch/powerpc/platforms/85xx/twr_p102x.c| 4 +-
> arch/powerpc/platforms/Kconfig | 19 -
> arch/powerpc/sysdev/Makefile | 1 -
> arch/powerpc/sysdev/qe_lib/Kconfig | 27 -
> drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
> drivers/net/ethernet/freescale/ucc_geth.c | 8 ++--
> drivers/net/ethernet/freescale/ucc_geth.h | 8 ++--
> drivers/soc/Kconfig| 2 +
> drivers/soc/Makefile | 1 +
> drivers/soc/fsl-qe/Kconfig | 45 ++
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/Makefile | 0
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/gpio.c| 2 +-
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe.c | 4 +-
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.c | 2 +-
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.h | 2 +-
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_io.c | 2 +-
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/ucc.c | 6 +--
> .../qe_lib => drivers/soc/fsl-qe}/ucc_fast.c | 8 ++--
> .../qe_lib => drivers/soc/fsl-qe}/ucc_slow.c | 8 ++--
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/usb.c | 4 +-
> drivers/spi/spi-fsl-cpm.c | 2 +-
> drivers/tty/serial/ucc_uart.c | 2 +-
> drivers/usb/gadget/fsl_qe_udc.c| 2 +-
> drivers/usb/host/fhci-hcd.c| 2 +-
> drivers/usb/host/fhci-hub.c| 2 +-
> drivers/usb/host/fhci-sched.c | 2 +-
> drivers/usb/host/fhci.h| 4 +-
> .../include/asm => include/linux/fsl}/immap_qe.h | 0
> .../powerpc/include/asm => include/linux/fsl}/qe.h | 2 +-
> .../include/asm => include/linux/fsl}/qe_ic.h | 0
> .../include/asm => include/linux/fsl}/ucc.h| 4 +-
> .../include/asm => include/linux/fsl}/ucc_fast.h | 6 +--
> .../include/asm => include/linux/fsl}/ucc_slow.h | 6 +--
> 44 files changed, 112 insertions(+), 113 deletions(-)
> delete mode 100644 arch/powerpc/sysdev/qe_lib/Kconfig
> create mode 100644 drivers/soc/fsl-qe/Kconfig
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/Makefile (100%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/gpio.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.h (98%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe_io.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/ucc.c (98%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/ucc_fast.c (98%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/ucc_slow.c (98%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/usb.c (96%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/immap_qe.h (100%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/qe.h (99%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/qe_ic.h (100%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/ucc.h (96%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/ucc_fast.h (98%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/ucc_slow.h (99%)
So you should be moving things to drivers/soc/fsl/qe/ not drivers/soc/fsl-qe/
The headers should be in include/soc/fsl, not include/linux/fsl
In addition before this move is accepted, other changes need to be made to
convert to using standard frameworks for various functionality in QE lib.
1. gpio.c -> needs to be converted to GPIO framework and placed in drivers/gpio
2. qe_ic* should probably move into drivers/irqchip
3. qe_io.c should be converted over
Re: [PATCH v3 3/3] rheap: move rheap.c from arch/powerpc/lib/ to lib/
On Oct 30, 2014, at 2:31 AM, Zhao Qiang wrote:
> qe need to use the rheap, so move it to public directory.
>
> Signed-off-by: Zhao Qiang
> ---
> arch/powerpc/Kconfig| 3 ---
> arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 2 +-
> arch/powerpc/lib/Makefile | 2 --
> arch/powerpc/platforms/44x/Kconfig | 2 +-
> arch/powerpc/platforms/85xx/Kconfig | 2 +-
> arch/powerpc/platforms/Kconfig | 2 +-
> arch/powerpc/platforms/Kconfig.cputype | 2 +-
> arch/powerpc/sysdev/cpm1.c | 2 +-
> arch/powerpc/sysdev/cpm2.c | 2 +-
> arch/powerpc/sysdev/cpm_common.c| 2 +-
> arch/powerpc/sysdev/ppc4xx_ocm.c| 2 +-
> drivers/dma/bestcomm/Kconfig| 2 +-
> drivers/soc/fsl-qe/Kconfig | 2 +-
> drivers/soc/fsl-qe/qe.c | 2 +-
> drivers/soc/fsl-qe/qe_common.c | 2 +-
> include/linux/fsl/bestcomm/sram.h | 2 +-
> {arch/powerpc/include/asm => include/linux/fsl}/rheap.h | 0
> lib/Kconfig | 3 +++
> lib/Makefile| 2 ++
> {arch/powerpc/lib => lib}/rheap.c | 2 +-
> 20 files changed, 20 insertions(+), 20 deletions(-)
> rename {arch/powerpc/include/asm => include/linux/fsl}/rheap.h (100%)
> rename {arch/powerpc/lib => lib}/rheap.c (99%)
NAK. As I stated before you need to convert rheap users to lib/genalloc.c
- k
--
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: [PATCH v3 3/3] rheap: move rheap.c from arch/powerpc/lib/ to lib/
On Oct 30, 2014, at 2:31 AM, Zhao Qiang b45...@freescale.com wrote:
qe need to use the rheap, so move it to public directory.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
arch/powerpc/Kconfig| 3 ---
arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 2 +-
arch/powerpc/lib/Makefile | 2 --
arch/powerpc/platforms/44x/Kconfig | 2 +-
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/powerpc/sysdev/cpm1.c | 2 +-
arch/powerpc/sysdev/cpm2.c | 2 +-
arch/powerpc/sysdev/cpm_common.c| 2 +-
arch/powerpc/sysdev/ppc4xx_ocm.c| 2 +-
drivers/dma/bestcomm/Kconfig| 2 +-
drivers/soc/fsl-qe/Kconfig | 2 +-
drivers/soc/fsl-qe/qe.c | 2 +-
drivers/soc/fsl-qe/qe_common.c | 2 +-
include/linux/fsl/bestcomm/sram.h | 2 +-
{arch/powerpc/include/asm = include/linux/fsl}/rheap.h | 0
lib/Kconfig | 3 +++
lib/Makefile| 2 ++
{arch/powerpc/lib = lib}/rheap.c | 2 +-
20 files changed, 20 insertions(+), 20 deletions(-)
rename {arch/powerpc/include/asm = include/linux/fsl}/rheap.h (100%)
rename {arch/powerpc/lib = lib}/rheap.c (99%)
NAK. As I stated before you need to convert rheap users to lib/genalloc.c
- k
--
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: [PATCH v3 1/3] QE: move qe code from arch/powerpc to drivers/soc
On Oct 30, 2014, at 2:31 AM, Zhao Qiang b45...@freescale.com wrote:
LS1 is arm cpu and it has qe ip block.
move qe code from platform directory to public directory.
QE is an IP block integrates several comunications peripheral
controllers. It can implement a variety of applications, such
as uart, usb and tdm and so on.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
Changes for v2:
- move code to driver/soc
Changes for v3:
- change drivers/soc/qe to drivers/soc/fsl-qe
arch/powerpc/Kconfig | 2 -
arch/powerpc/platforms/83xx/km83xx.c | 4 +-
arch/powerpc/platforms/83xx/misc.c | 2 +-
arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 +-
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 +-
arch/powerpc/platforms/85xx/common.c | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +-
arch/powerpc/platforms/85xx/twr_p102x.c| 4 +-
arch/powerpc/platforms/Kconfig | 19 -
arch/powerpc/sysdev/Makefile | 1 -
arch/powerpc/sysdev/qe_lib/Kconfig | 27 -
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 8 ++--
drivers/net/ethernet/freescale/ucc_geth.h | 8 ++--
drivers/soc/Kconfig| 2 +
drivers/soc/Makefile | 1 +
drivers/soc/fsl-qe/Kconfig | 45 ++
.../sysdev/qe_lib = drivers/soc/fsl-qe}/Makefile | 0
.../sysdev/qe_lib = drivers/soc/fsl-qe}/gpio.c| 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe.c | 4 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.c | 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.h | 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe_io.c | 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/ucc.c | 6 +--
.../qe_lib = drivers/soc/fsl-qe}/ucc_fast.c | 8 ++--
.../qe_lib = drivers/soc/fsl-qe}/ucc_slow.c | 8 ++--
.../sysdev/qe_lib = drivers/soc/fsl-qe}/usb.c | 4 +-
drivers/spi/spi-fsl-cpm.c | 2 +-
drivers/tty/serial/ucc_uart.c | 2 +-
drivers/usb/gadget/fsl_qe_udc.c| 2 +-
drivers/usb/host/fhci-hcd.c| 2 +-
drivers/usb/host/fhci-hub.c| 2 +-
drivers/usb/host/fhci-sched.c | 2 +-
drivers/usb/host/fhci.h| 4 +-
.../include/asm = include/linux/fsl}/immap_qe.h | 0
.../powerpc/include/asm = include/linux/fsl}/qe.h | 2 +-
.../include/asm = include/linux/fsl}/qe_ic.h | 0
.../include/asm = include/linux/fsl}/ucc.h| 4 +-
.../include/asm = include/linux/fsl}/ucc_fast.h | 6 +--
.../include/asm = include/linux/fsl}/ucc_slow.h | 6 +--
44 files changed, 112 insertions(+), 113 deletions(-)
delete mode 100644 arch/powerpc/sysdev/qe_lib/Kconfig
create mode 100644 drivers/soc/fsl-qe/Kconfig
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/Makefile (100%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/gpio.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.h (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe_io.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/ucc.c (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/ucc_fast.c (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/ucc_slow.c (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/usb.c (96%)
rename {arch/powerpc/include/asm = include/linux/fsl}/immap_qe.h (100%)
rename {arch/powerpc/include/asm = include/linux/fsl}/qe.h (99%)
rename {arch/powerpc/include/asm = include/linux/fsl}/qe_ic.h (100%)
rename {arch/powerpc/include/asm = include/linux/fsl}/ucc.h (96%)
rename {arch/powerpc/include/asm = include/linux/fsl}/ucc_fast.h (98%)
rename {arch/powerpc/include/asm = include/linux/fsl}/ucc_slow.h (99%)
So you should be moving things to drivers/soc/fsl/qe/ not drivers/soc/fsl-qe/
The headers should be in include/soc/fsl, not include/linux/fsl
In addition before this move is accepted, other changes need to be made to
convert to using standard frameworks for various functionality in QE lib.
1. gpio.c - needs to be converted to GPIO framework and placed in drivers/gpio
2. qe_ic* should probably move into drivers/irqchip
3. qe_io.c should be converted over to pinmux and put in drivers/pinctrl
4. Some of the clock could should
Re: [PATCH v3 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions
On Oct 21, 2014, at 7:56 AM, Ankit Jindal wrote:
> Currently, three types of mem regions are supported: UIO_MEM_PHYS,
> UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
> UIO driver export physcial memory to user space as non-cacheable
> user memory. Typcially memory-mapped registers of a device are exported
> to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
> is not efficient if dma-capable devices are capable of maintaining coherency
> with CPU caches.
>
> This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
> cacheable access to physical memory from user space.
>
> Signed-off-by: Ankit Jindal
> Signed-off-by: Tushar Jagad
> ---
> drivers/uio/uio.c | 11 ---
> include/linux/uio_driver.h |1 +
> 2 files changed, 9 insertions(+), 3 deletions(-)
Rather than adding a new type, why not allow the driver to set the pgprot
value, this way one has full control and we don’t need to keep adding types for
various different cache attributions in the future.
- k
>
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index 97e6444..120a84b 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -644,7 +644,7 @@ static const struct vm_operations_struct
> uio_physical_vm_ops = {
> #endif
> };
>
> -static int uio_mmap_physical(struct vm_area_struct *vma)
> +static int uio_mmap_physical(struct vm_area_struct *vma, bool cacheable)
> {
> struct uio_device *idev = vma->vm_private_data;
> int mi = uio_find_mem_index(vma);
> @@ -659,7 +659,9 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
> return -EINVAL;
>
> vma->vm_ops = _physical_vm_ops;
> - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> +
> + if (!cacheable)
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>
> /*
>* We cannot use the vm_iomap_memory() helper here,
> @@ -707,10 +709,13 @@ static int uio_mmap(struct file *filep, struct
> vm_area_struct *vma)
>
> switch (idev->info->mem[mi].memtype) {
> case UIO_MEM_PHYS:
> - return uio_mmap_physical(vma);
> + return uio_mmap_physical(vma, false);
> case UIO_MEM_LOGICAL:
> case UIO_MEM_VIRTUAL:
> return uio_mmap_logical(vma);
> + case UIO_MEM_PHYS_CACHE:
> + return uio_mmap_physical(vma, true);
> +
> default:
> return -EINVAL;
> }
> diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
> index 1ad4724..40ca3f3 100644
> --- a/include/linux/uio_driver.h
> +++ b/include/linux/uio_driver.h
> @@ -118,6 +118,7 @@ extern void uio_event_notify(struct uio_info *info);
> #define UIO_MEM_PHYS 1
> #define UIO_MEM_LOGICAL 2
> #define UIO_MEM_VIRTUAL 3
> +#define UIO_MEM_PHYS_CACHE 4
>
> /* defines for uio_port->porttype */
> #define UIO_PORT_NONE 0
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: [PATCH v3 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions
On Oct 21, 2014, at 7:56 AM, Ankit Jindal ankit.jin...@linaro.org wrote:
Currently, three types of mem regions are supported: UIO_MEM_PHYS,
UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
UIO driver export physcial memory to user space as non-cacheable
user memory. Typcially memory-mapped registers of a device are exported
to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
is not efficient if dma-capable devices are capable of maintaining coherency
with CPU caches.
This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
cacheable access to physical memory from user space.
Signed-off-by: Ankit Jindal ankit.jin...@linaro.org
Signed-off-by: Tushar Jagad tushar.ja...@linaro.org
---
drivers/uio/uio.c | 11 ---
include/linux/uio_driver.h |1 +
2 files changed, 9 insertions(+), 3 deletions(-)
Rather than adding a new type, why not allow the driver to set the pgprot
value, this way one has full control and we don’t need to keep adding types for
various different cache attributions in the future.
- k
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 97e6444..120a84b 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -644,7 +644,7 @@ static const struct vm_operations_struct
uio_physical_vm_ops = {
#endif
};
-static int uio_mmap_physical(struct vm_area_struct *vma)
+static int uio_mmap_physical(struct vm_area_struct *vma, bool cacheable)
{
struct uio_device *idev = vma-vm_private_data;
int mi = uio_find_mem_index(vma);
@@ -659,7 +659,9 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
return -EINVAL;
vma-vm_ops = uio_physical_vm_ops;
- vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
+
+ if (!cacheable)
+ vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
/*
* We cannot use the vm_iomap_memory() helper here,
@@ -707,10 +709,13 @@ static int uio_mmap(struct file *filep, struct
vm_area_struct *vma)
switch (idev-info-mem[mi].memtype) {
case UIO_MEM_PHYS:
- return uio_mmap_physical(vma);
+ return uio_mmap_physical(vma, false);
case UIO_MEM_LOGICAL:
case UIO_MEM_VIRTUAL:
return uio_mmap_logical(vma);
+ case UIO_MEM_PHYS_CACHE:
+ return uio_mmap_physical(vma, true);
+
default:
return -EINVAL;
}
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 1ad4724..40ca3f3 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -118,6 +118,7 @@ extern void uio_event_notify(struct uio_info *info);
#define UIO_MEM_PHYS 1
#define UIO_MEM_LOGICAL 2
#define UIO_MEM_VIRTUAL 3
+#define UIO_MEM_PHYS_CACHE 4
/* defines for uio_port-porttype */
#define UIO_PORT_NONE 0
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/
[PATCH] tty: serial: msm: Fix lock init issue with earlycon
With CONFIG_DEBUG_SPINLOCK enabled we see: BUG: spinlock bad magic on CPU#0, swapper/0 lock: early_console_dev+0x8/0x160, .magic: , .owner: /-1, .owner_cpu: 0 CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.0-09733-gb446b33-dirty #18 Call trace: [] dump_backtrace+0x0/0x140 [] show_stack+0x10/0x1c [] dump_stack+0x74/0xb8 [] spin_dump+0x78/0x88 [] spin_bug+0x24/0x34 [] do_raw_spin_lock+0x30/0x158 [] _raw_spin_lock+0x1c/0x2c [] __msm_console_write+0x68/0x154 [] msm_serial_early_write_dm+0x14/0x20 [] call_console_drivers.constprop.23+0xa4/0xc4 [] console_unlock+0x2a8/0x330 [] register_console+0x26c/0x338 [] setup_earlycon+0x2c0/0x300 [] msm_serial_dm_setup_earlycon+0x18/0x24 [] do_early_param+0x84/0xd0 [] parse_args+0x2b4/0x3ec [] parse_early_options+0x2c/0x38 [] parse_early_param+0x34/0x50 [] setup_arch+0x290/0x604 [] start_kernel+0x94/0x38c As the earlycon write function for msm requires a lock, we need to init it as part of the setup call. Signed-off-by: Kumar Gala --- drivers/tty/serial/msm_serial.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c index 4b6c783..8ab27c9 100644 --- a/drivers/tty/serial/msm_serial.c +++ b/drivers/tty/serial/msm_serial.c @@ -973,6 +973,8 @@ msm_serial_early_console_setup(struct earlycon_device *device, const char *opt) if (!device->port.membase) return -ENODEV; + spin_lock_init(>port.lock); + device->con->write = msm_serial_early_write; return 0; } @@ -995,6 +997,8 @@ msm_serial_early_console_setup_dm(struct earlycon_device *device, if (!device->port.membase) return -ENODEV; + spin_lock_init(>port.lock); + device->con->write = msm_serial_early_write_dm; return 0; } -- 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/
[PATCH] tty/serial: earlycon: Fix print for implied MMIO case
For the case in which we just provide an address as an argument to the
earlycon console type like:
earlycon=msm_serial_dm,0xf991e000
We would report this as an IO port based mapping and not as MMIO. Simple
fix to use the port->iotype to decide which message to print.
Signed-off-by: Kumar Gala
---
drivers/tty/serial/earlycon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index a514ee6..64fe25a 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -98,7 +98,7 @@ static int __init parse_options(struct earlycon_device
*device,
strlcpy(device->options, options, length);
}
- if (mmio || mmio32)
+ if (port->iotype == UPIO_MEM || port->iotype == UPIO_MEM32)
pr_info("Early serial console at MMIO%s 0x%llx (options
'%s')\n",
mmio32 ? "32" : "",
(unsigned long long)port->mapbase,
--
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: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ platforms
On Oct 17, 2014, at 5:13 AM, b29...@freescale.com wrote:
> From: Tang Yuantian
>
> Freescale introduced new ARM core-based SoCs which support dynamic
> frequency switch feature. DFS on new SoCs are compatible with current
> PowerPC CoreNet platforms. In order to support those new platforms,
> this driver needs to be slightly adjusted. The main changes include:
>
> 1. Changed the names of driver and functions in driver.
split the name changes/renaming into a separate patch from the other changes.
> 2. Added two new functions get_cpu_physical_id() and get_bus_freq().
> 3. Used a new way to get all the CPUs which sharing clock wire.
>
> Signed-off-by: Tang Yuantian
> ---
> drivers/cpufreq/Kconfig.arm| 8 ++
> drivers/cpufreq/Kconfig.powerpc| 11 +-
> drivers/cpufreq/Makefile | 2 +-
> .../{ppc-corenet-cpufreq.c => qoriq-cpufreq.c} | 150 ++---
> 4 files changed, 114 insertions(+), 57 deletions(-)
> rename drivers/cpufreq/{ppc-corenet-cpufreq.c => qoriq-cpufreq.c} (72%)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 83a75dc..1925ae94 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -247,3 +247,11 @@ config ARM_TEGRA_CPUFREQ
> default y
> help
> This adds the CPUFreq driver support for TEGRA SOCs.
> +
> +config QORIQ_CPUFREQ
> + tristate "CPU frequency scaling driver for Freescale QorIQ SoCs"
> + depends on OF && COMMON_CLK
> + select CLK_PPC_CORENET
Why are you not also renaming ‘CLK_PPC_CORENET’ to ‘CLK_QORIQ’ or something
like that? Seems rather odd to select a PPC CLK support on ARM ;)
> + help
> + This adds the CPUFreq driver support for Freescale QorIQ SoCs
> + which are capable of changing the CPU's frequency dynamically.
> diff --git a/drivers/cpufreq/Kconfig.powerpc b/drivers/cpufreq/Kconfig.powerpc
> index 72564b7..3a34248 100644
> --- a/drivers/cpufreq/Kconfig.powerpc
> +++ b/drivers/cpufreq/Kconfig.powerpc
> @@ -23,14 +23,13 @@ config CPU_FREQ_MAPLE
> This adds support for frequency switching on Maple 970FX
> Evaluation Board and compatible boards (IBM JS2x blades).
>
> -config PPC_CORENET_CPUFREQ
> - tristate "CPU frequency scaling driver for Freescale E500MC SoCs"
> - depends on PPC_E500MC && OF && COMMON_CLK
> +config QORIQ_CPUFREQ
> + tristate "CPU frequency scaling driver for Freescale QorIQ SoCs"
> + depends on OF && COMMON_CLK
> select CLK_PPC_CORENET
> help
> - This adds the CPUFreq driver support for Freescale e500mc,
> - e5500 and e6500 series SoCs which are capable of changing
> - the CPU's frequency dynamically.
> + This adds the CPUFreq driver support for Freescale QorIQ SoCs
> + which are capable of changing the CPU's frequency dynamically.
>
> config CPU_FREQ_PMAC
> bool "Support for Apple PowerBooks"
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 40c53dc..0020049 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -84,7 +84,7 @@ obj-$(CONFIG_CPU_FREQ_CBE) += ppc-cbe-cpufreq.o
> ppc-cbe-cpufreq-y += ppc_cbe_cpufreq_pervasive.o
> ppc_cbe_cpufreq.o
> obj-$(CONFIG_CPU_FREQ_CBE_PMI)+= ppc_cbe_cpufreq_pmi.o
> obj-$(CONFIG_CPU_FREQ_MAPLE) += maple-cpufreq.o
> -obj-$(CONFIG_PPC_CORENET_CPUFREQ) += ppc-corenet-cpufreq.o
> +obj-$(CONFIG_QORIQ_CPUFREQ) += qoriq-cpufreq.o
> obj-$(CONFIG_CPU_FREQ_PMAC) += pmac32-cpufreq.o
> obj-$(CONFIG_CPU_FREQ_PMAC64) += pmac64-cpufreq.o
> obj-$(CONFIG_PPC_PASEMI_CPUFREQ) += pasemi-cpufreq.o
> diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
> b/drivers/cpufreq/qoriq-cpufreq.c
> similarity index 72%
> rename from drivers/cpufreq/ppc-corenet-cpufreq.c
> rename to drivers/cpufreq/qoriq-cpufreq.c
> index bee5df7..80def0c 100644
> --- a/drivers/cpufreq/ppc-corenet-cpufreq.c
> +++ b/drivers/cpufreq/qoriq-cpufreq.c
> @@ -1,7 +1,7 @@
> /*
> * Copyright 2013 Freescale Semiconductor, Inc.
> *
> - * CPU Frequency Scaling driver for Freescale PowerPC corenet SoCs.
> + * CPU Frequency Scaling driver for Freescale QorIQ SoCs.
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> @@ -20,7 +20,6 @@
> #include
> #include
> #include
> -#include
>
> /**
> * struct cpu_data - per CPU data struct
> @@ -69,9 +68,6 @@ static const u32 *fmask;
>
> static DEFINE_PER_CPU(struct cpu_data *, cpu_data);
>
> -/* cpumask in a cluster */
> -static DEFINE_PER_CPU(cpumask_var_t, cpu_mask);
> -
> #ifndef CONFIG_SMP
> static inline const struct cpumask *cpu_core_mask(int cpu)
> {
> @@ -79,6 +75,79 @@ static inline const struct cpumask *cpu_core_mask(int cpu)
> }
> #endif
>
> +#if defined(CONFIG_PPC_E500MC)
Probably should just be
Re: [PATCH 3/3] rheap: move rheap.c from arch/powerpc/lib/ to lib/
On Sep 25, 2014, at 4:47 AM, Zhao Qiang wrote:
> qe need to use the rheap, so move it to public directory.
>
> Signed-off-by: Zhao Qiang
> ---
> arch/powerpc/Kconfig| 3 ---
> arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 2 +-
> arch/powerpc/lib/Makefile | 2 --
> arch/powerpc/platforms/44x/Kconfig | 2 +-
> arch/powerpc/platforms/85xx/Kconfig | 2 +-
> arch/powerpc/platforms/Kconfig | 2 +-
> arch/powerpc/platforms/Kconfig.cputype | 2 +-
> arch/powerpc/sysdev/cpm1.c | 2 +-
> arch/powerpc/sysdev/cpm2.c | 2 +-
> arch/powerpc/sysdev/cpm_common.c| 2 +-
> arch/powerpc/sysdev/ppc4xx_ocm.c| 2 +-
> drivers/dma/bestcomm/Kconfig| 2 +-
> drivers/soc/qe/Kconfig | 2 +-
> drivers/soc/qe/qe.c | 2 +-
> drivers/soc/qe/qe_common.c | 2 +-
> drivers/video/Kconfig | 2 +-
> include/linux/fsl/bestcomm/sram.h | 2 +-
> {arch/powerpc/include/asm => include/linux/fsl}/rheap.h | 0
> lib/Kconfig | 3 +++
> lib/Makefile| 2 ++
> {arch/powerpc/lib => lib}/rheap.c | 2 +-
> 21 files changed, 21 insertions(+), 21 deletions(-)
> rename {arch/powerpc/include/asm => include/linux/fsl}/rheap.h (100%)
> rename {arch/powerpc/lib => lib}/rheap.c (99%)
Have you guys looked at moving to lib/genalloc.c. If we are going to keep
rheap around the include should be just in include/linux/rheap.h not
include/linux/fsl/rheap.h
However, I think genalloc should be used and kill off rheap usage.
- k--
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: [PATCH 3/3] rheap: move rheap.c from arch/powerpc/lib/ to lib/
On Sep 25, 2014, at 4:47 AM, Zhao Qiang b45...@freescale.com wrote:
qe need to use the rheap, so move it to public directory.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
arch/powerpc/Kconfig| 3 ---
arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 2 +-
arch/powerpc/lib/Makefile | 2 --
arch/powerpc/platforms/44x/Kconfig | 2 +-
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/powerpc/sysdev/cpm1.c | 2 +-
arch/powerpc/sysdev/cpm2.c | 2 +-
arch/powerpc/sysdev/cpm_common.c| 2 +-
arch/powerpc/sysdev/ppc4xx_ocm.c| 2 +-
drivers/dma/bestcomm/Kconfig| 2 +-
drivers/soc/qe/Kconfig | 2 +-
drivers/soc/qe/qe.c | 2 +-
drivers/soc/qe/qe_common.c | 2 +-
drivers/video/Kconfig | 2 +-
include/linux/fsl/bestcomm/sram.h | 2 +-
{arch/powerpc/include/asm = include/linux/fsl}/rheap.h | 0
lib/Kconfig | 3 +++
lib/Makefile| 2 ++
{arch/powerpc/lib = lib}/rheap.c | 2 +-
21 files changed, 21 insertions(+), 21 deletions(-)
rename {arch/powerpc/include/asm = include/linux/fsl}/rheap.h (100%)
rename {arch/powerpc/lib = lib}/rheap.c (99%)
Have you guys looked at moving to lib/genalloc.c. If we are going to keep
rheap around the include should be just in include/linux/rheap.h not
include/linux/fsl/rheap.h
However, I think genalloc should be used and kill off rheap usage.
- k--
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: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ platforms
On Oct 17, 2014, at 5:13 AM, b29...@freescale.com wrote:
From: Tang Yuantian yuantian.t...@freescale.com
Freescale introduced new ARM core-based SoCs which support dynamic
frequency switch feature. DFS on new SoCs are compatible with current
PowerPC CoreNet platforms. In order to support those new platforms,
this driver needs to be slightly adjusted. The main changes include:
1. Changed the names of driver and functions in driver.
split the name changes/renaming into a separate patch from the other changes.
2. Added two new functions get_cpu_physical_id() and get_bus_freq().
3. Used a new way to get all the CPUs which sharing clock wire.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
drivers/cpufreq/Kconfig.arm| 8 ++
drivers/cpufreq/Kconfig.powerpc| 11 +-
drivers/cpufreq/Makefile | 2 +-
.../{ppc-corenet-cpufreq.c = qoriq-cpufreq.c} | 150 ++---
4 files changed, 114 insertions(+), 57 deletions(-)
rename drivers/cpufreq/{ppc-corenet-cpufreq.c = qoriq-cpufreq.c} (72%)
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 83a75dc..1925ae94 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -247,3 +247,11 @@ config ARM_TEGRA_CPUFREQ
default y
help
This adds the CPUFreq driver support for TEGRA SOCs.
+
+config QORIQ_CPUFREQ
+ tristate CPU frequency scaling driver for Freescale QorIQ SoCs
+ depends on OF COMMON_CLK
+ select CLK_PPC_CORENET
Why are you not also renaming ‘CLK_PPC_CORENET’ to ‘CLK_QORIQ’ or something
like that? Seems rather odd to select a PPC CLK support on ARM ;)
+ help
+ This adds the CPUFreq driver support for Freescale QorIQ SoCs
+ which are capable of changing the CPU's frequency dynamically.
diff --git a/drivers/cpufreq/Kconfig.powerpc b/drivers/cpufreq/Kconfig.powerpc
index 72564b7..3a34248 100644
--- a/drivers/cpufreq/Kconfig.powerpc
+++ b/drivers/cpufreq/Kconfig.powerpc
@@ -23,14 +23,13 @@ config CPU_FREQ_MAPLE
This adds support for frequency switching on Maple 970FX
Evaluation Board and compatible boards (IBM JS2x blades).
-config PPC_CORENET_CPUFREQ
- tristate CPU frequency scaling driver for Freescale E500MC SoCs
- depends on PPC_E500MC OF COMMON_CLK
+config QORIQ_CPUFREQ
+ tristate CPU frequency scaling driver for Freescale QorIQ SoCs
+ depends on OF COMMON_CLK
select CLK_PPC_CORENET
help
- This adds the CPUFreq driver support for Freescale e500mc,
- e5500 and e6500 series SoCs which are capable of changing
- the CPU's frequency dynamically.
+ This adds the CPUFreq driver support for Freescale QorIQ SoCs
+ which are capable of changing the CPU's frequency dynamically.
config CPU_FREQ_PMAC
bool Support for Apple PowerBooks
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 40c53dc..0020049 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -84,7 +84,7 @@ obj-$(CONFIG_CPU_FREQ_CBE) += ppc-cbe-cpufreq.o
ppc-cbe-cpufreq-y += ppc_cbe_cpufreq_pervasive.o
ppc_cbe_cpufreq.o
obj-$(CONFIG_CPU_FREQ_CBE_PMI)+= ppc_cbe_cpufreq_pmi.o
obj-$(CONFIG_CPU_FREQ_MAPLE) += maple-cpufreq.o
-obj-$(CONFIG_PPC_CORENET_CPUFREQ) += ppc-corenet-cpufreq.o
+obj-$(CONFIG_QORIQ_CPUFREQ) += qoriq-cpufreq.o
obj-$(CONFIG_CPU_FREQ_PMAC) += pmac32-cpufreq.o
obj-$(CONFIG_CPU_FREQ_PMAC64) += pmac64-cpufreq.o
obj-$(CONFIG_PPC_PASEMI_CPUFREQ) += pasemi-cpufreq.o
diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
b/drivers/cpufreq/qoriq-cpufreq.c
similarity index 72%
rename from drivers/cpufreq/ppc-corenet-cpufreq.c
rename to drivers/cpufreq/qoriq-cpufreq.c
index bee5df7..80def0c 100644
--- a/drivers/cpufreq/ppc-corenet-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -1,7 +1,7 @@
/*
* Copyright 2013 Freescale Semiconductor, Inc.
*
- * CPU Frequency Scaling driver for Freescale PowerPC corenet SoCs.
+ * CPU Frequency Scaling driver for Freescale QorIQ SoCs.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -20,7 +20,6 @@
#include linux/of.h
#include linux/slab.h
#include linux/smp.h
-#include sysdev/fsl_soc.h
/**
* struct cpu_data - per CPU data struct
@@ -69,9 +68,6 @@ static const u32 *fmask;
static DEFINE_PER_CPU(struct cpu_data *, cpu_data);
-/* cpumask in a cluster */
-static DEFINE_PER_CPU(cpumask_var_t, cpu_mask);
-
#ifndef CONFIG_SMP
static inline const struct cpumask *cpu_core_mask(int cpu)
{
@@ -79,6 +75,79 @@ static inline const struct cpumask *cpu_core_mask(int cpu)
}
#endif
+#if defined(CONFIG_PPC_E500MC)
Probably should just be CONFIG_PPC, but do we need this at
[PATCH] tty/serial: earlycon: Fix print for implied MMIO case
For the case in which we just provide an address as an argument to the earlycon console type like: earlycon=msm_serial_dm,0xf991e000 We would report this as an IO port based mapping and not as MMIO. Simple fix to use the port-iotype to decide which message to print. Signed-off-by: Kumar Gala ga...@codeaurora.org --- drivers/tty/serial/earlycon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c index a514ee6..64fe25a 100644 --- a/drivers/tty/serial/earlycon.c +++ b/drivers/tty/serial/earlycon.c @@ -98,7 +98,7 @@ static int __init parse_options(struct earlycon_device *device, strlcpy(device-options, options, length); } - if (mmio || mmio32) + if (port-iotype == UPIO_MEM || port-iotype == UPIO_MEM32) pr_info(Early serial console at MMIO%s 0x%llx (options '%s')\n, mmio32 ? 32 : , (unsigned long long)port-mapbase, -- 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/
[PATCH] tty: serial: msm: Fix lock init issue with earlycon
With CONFIG_DEBUG_SPINLOCK enabled we see: BUG: spinlock bad magic on CPU#0, swapper/0 lock: early_console_dev+0x8/0x160, .magic: , .owner: none/-1, .owner_cpu: 0 CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.0-09733-gb446b33-dirty #18 Call trace: [c0087ba0] dump_backtrace+0x0/0x140 [c0087cf0] show_stack+0x10/0x1c [c0598be0] dump_stack+0x74/0xb8 [c00cb720] spin_dump+0x78/0x88 [c00cb754] spin_bug+0x24/0x34 [c00cb7e4] do_raw_spin_lock+0x30/0x158 [c059ea2c] _raw_spin_lock+0x1c/0x2c [c02e0e30] __msm_console_write+0x68/0x154 [c02e0f50] msm_serial_early_write_dm+0x14/0x20 [c00cf040] call_console_drivers.constprop.23+0xa4/0xc4 [c00d00c4] console_unlock+0x2a8/0x330 [c00d121c] register_console+0x26c/0x338 [c0805af4] setup_earlycon+0x2c0/0x300 [c0805c48] msm_serial_dm_setup_earlycon+0x18/0x24 [c07ed158] do_early_param+0x84/0xd0 [c00aec18] parse_args+0x2b4/0x3ec [c07ed588] parse_early_options+0x2c/0x38 [c07ed5c8] parse_early_param+0x34/0x50 [c07f03c0] setup_arch+0x290/0x604 [c07ed67c] start_kernel+0x94/0x38c As the earlycon write function for msm requires a lock, we need to init it as part of the setup call. Signed-off-by: Kumar Gala ga...@codeaurora.org --- drivers/tty/serial/msm_serial.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c index 4b6c783..8ab27c9 100644 --- a/drivers/tty/serial/msm_serial.c +++ b/drivers/tty/serial/msm_serial.c @@ -973,6 +973,8 @@ msm_serial_early_console_setup(struct earlycon_device *device, const char *opt) if (!device-port.membase) return -ENODEV; + spin_lock_init(device-port.lock); + device-con-write = msm_serial_early_write; return 0; } @@ -995,6 +997,8 @@ msm_serial_early_console_setup_dm(struct earlycon_device *device, if (!device-port.membase) return -ENODEV; + spin_lock_init(device-port.lock); + device-con-write = msm_serial_early_write_dm; return 0; } -- 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/
[GIT PULL] qcom DT changes for v3.18-3
The following changes since commit aabff7bfe55afd01d71a5f11d4a84bd873c20f5e: ARM: DT: msm8960: Add sdcc nodes (2014-09-22 13:49:43 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-dt-for-3.18-3 for you to fetch changes up to 7dac24bdc1dd561573cd8ce534a63dc975f51ca8: ARM: dts: qcom: add CM-QS600 board (2014-10-16 02:48:36 -0500) Qualcomm ARM Based Device Tree Updates for v3.18-3 * Added Board support for CM-QS600 and Sony Xperia Z1 phone * Added SATA support on IPQ8064/AP148 Kumar Gala (1): ARM: dts: qcom: Add SATA support on IPQ8064/AP148 Mike Rapoport (1): ARM: dts: qcom: add CM-QS600 board Tim Bird (1): ARM: dts: qcom: Add initial DTS file for Sony Xperia Z1 phone Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + arch/arm/boot/dts/Makefile| 4 ++- arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 59 arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 8 ++ arch/arm/boot/dts/qcom-ipq8064.dtsi | 33 ++ arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts | 17 6 files changed, 121 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts create mode 100644 arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts -- 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/
[GIT PULL] qcom DT changes for v3.18-3
The following changes since commit aabff7bfe55afd01d71a5f11d4a84bd873c20f5e: ARM: DT: msm8960: Add sdcc nodes (2014-09-22 13:49:43 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-dt-for-3.18-3 for you to fetch changes up to 7dac24bdc1dd561573cd8ce534a63dc975f51ca8: ARM: dts: qcom: add CM-QS600 board (2014-10-16 02:48:36 -0500) Qualcomm ARM Based Device Tree Updates for v3.18-3 * Added Board support for CM-QS600 and Sony Xperia Z1 phone * Added SATA support on IPQ8064/AP148 Kumar Gala (1): ARM: dts: qcom: Add SATA support on IPQ8064/AP148 Mike Rapoport (1): ARM: dts: qcom: add CM-QS600 board Tim Bird (1): ARM: dts: qcom: Add initial DTS file for Sony Xperia Z1 phone Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + arch/arm/boot/dts/Makefile| 4 ++- arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 59 arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 8 ++ arch/arm/boot/dts/qcom-ipq8064.dtsi | 33 ++ arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts | 17 6 files changed, 121 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts create mode 100644 arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts -- 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.18
On Oct 1, 2014, at 4:41 PM, Arnd Bergmann wrote: > On Monday 22 September 2014, Kumar Gala wrote: >> The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: >> >> Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) >> >> 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.18 >> >> for you to fetch changes up to 525fbb55947177cdae507b0d292f43c2c9a75a47: >> >> ARM: qcom: Move scm-boot files to drivers/soc and include/soc (2014-09-18 >> 18:14:01 -0500) >> >> >> Qualcomm ARM Based SoC Updates for v3.18 >> >> * 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 > > Pulled it into next/late now. This means we're not sending it together with > the > other pull requests to Linus. We'll see how things go during the first week > and may or may not send it in the second week of the merge window depending > on that. > > Arnd Any update if you guys will end up sending this to linus for 3.18 or not? - 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: [PATCH v2 3/3] ARM: dts: qcom: Add SDHC nodes for APQ8084 platform
On Oct 14, 2014, at 6:17 PM, Georgi Djakov wrote:
> On 10/10/2014 08:14 PM, Bjorn Andersson wrote:
>> On Tue, Sep 2, 2014 at 8:40 AM, Georgi Djakov wrote:
>>> Enable support for the two SD host controllers on the APQ8084 platform
>>> by adding the required nodes to the DT files.
>>> On the IFC6540 board, the first controller is connected to the onboard
>>> eMMC and the second is connected to a micro-SD card slot.
>>>
>>> Signed-off-by: Georgi Djakov
>>
>> Hi Georgi,
>>
>> This looks sane, but...
>>
>>> ---
>>> arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 11 +++
>>> arch/arm/boot/dts/qcom-apq8084.dtsi| 23 +++
>>> 2 files changed, 34 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
>>> b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
>>> index e41cb8a..c9ff108 100644
>>> --- a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
>>> +++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
>> [..]
>>> + sdhci@f98a4900 {
>>> + cd-gpios = < 122 GPIO_ACTIVE_LOW>;
>>> + bus-width = <4>;
>>
>> ...why do you add this node and leave it disabled in the dts?
>>
>
> Hi Bjorn,
> Currently only the eMMC is functional on this board, so now we
> have just the board specific configuration under this node.
> More patches are forthcoming.
Can we add something in the commit message to denote this.
- 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: [PATCH v2 3/3] ARM: dts: qcom: Add SDHC nodes for APQ8084 platform
On Oct 14, 2014, at 6:17 PM, Georgi Djakov gdja...@mm-sol.com wrote:
On 10/10/2014 08:14 PM, Bjorn Andersson wrote:
On Tue, Sep 2, 2014 at 8:40 AM, Georgi Djakov gdja...@mm-sol.com wrote:
Enable support for the two SD host controllers on the APQ8084 platform
by adding the required nodes to the DT files.
On the IFC6540 board, the first controller is connected to the onboard
eMMC and the second is connected to a micro-SD card slot.
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
Hi Georgi,
This looks sane, but...
---
arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 11 +++
arch/arm/boot/dts/qcom-apq8084.dtsi| 23 +++
2 files changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
index e41cb8a..c9ff108 100644
--- a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
+++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
[..]
+ sdhci@f98a4900 {
+ cd-gpios = tlmm 122 GPIO_ACTIVE_LOW;
+ bus-width = 4;
...why do you add this node and leave it disabled in the dts?
Hi Bjorn,
Currently only the eMMC is functional on this board, so now we
have just the board specific configuration under this node.
More patches are forthcoming.
Can we add something in the commit message to denote this.
- 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.18
On Oct 1, 2014, at 4:41 PM, Arnd Bergmann a...@arndb.de wrote: On Monday 22 September 2014, Kumar Gala wrote: The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) 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.18 for you to fetch changes up to 525fbb55947177cdae507b0d292f43c2c9a75a47: ARM: qcom: Move scm-boot files to drivers/soc and include/soc (2014-09-18 18:14:01 -0500) Qualcomm ARM Based SoC Updates for v3.18 * 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 Pulled it into next/late now. This means we're not sending it together with the other pull requests to Linus. We'll see how things go during the first week and may or may not send it in the second week of the merge window depending on that. Arnd Any update if you guys will end up sending this to linus for 3.18 or not? - 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: [PATCH v3] ARM: dts: Add initial DTS file for Sony Xperia Z1 phone
Will not make the 3.18 merge window. I will queue it up for 3.19.
- k
On Oct 9, 2014, at 11:55 AM, Tim Bird wrote:
> Kumar,
>
> Any chance this could make the 3.18 merge window? Have you had time to take
> a look at it?
> -- Tim
>
>
> On Tue, Sep 30, 2014 at 3:49 PM, Tim Bird wrote:
> This DTS has support for the Sony Xperia Z1 phone (codenamed Honami).
> This first version of the DTS supports just a serial console.
>
> changes from V2
> - fixed dtb name in Makefile
>
> changes from v1
> - removed qcom,msm-id attribute
> - removed mis-capitalized Qualcomm word
> - changed dts file name
> - added board-specific compatible-string
>
> Signed-off-by: Tim Bird
> Tested-by: Kevin Hilman
> ---
>
> This version fixes the dtb name. I asked previously about adding to
> qcom_dt_match,
> but apparently board compatibles are being removed from that list in
> mach_qcom/board.c
> See https://lkml.org/lkml/2014/9/24/952
>
> Kevin tested this (modulu re-adding back the qcom,msm-id). I have a new
> mkqcdtbootimg which works without requiring the qcom,msm-id attribute,
> that I'll send to Kevin shortly (and publish on github).
>
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> arch/arm/boot/dts/Makefile| 3 ++-
> arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts | 17 +
> 3 files changed, 20 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index ac7269f..d3a4579 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -128,6 +128,7 @@ sirfSiRF Technology, Inc.
> smsc Standard Microsystems Corporation
> snps Synopsys, Inc.
> solidrun SolidRun
> +sony Sony Corporation
> spansion Spansion Inc.
> st STMicroelectronics
> steST-Ericsson
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b8c5cd3..cf58321 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -343,7 +343,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
> qcom-apq8074-dragonboard.dtb \
> qcom-apq8084-mtp.dtb \
> qcom-msm8660-surf.dtb \
> - qcom-msm8960-cdp.dtb
> + qcom-msm8960-cdp.dtb \
> + qcom-msm8974-sony-xperia-honami.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> rk3066a-bqcurie2.dtb \
> rk3188-radxarock.dtb \
> diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
> b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
> new file mode 100644
> index 000..21b
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
> @@ -0,0 +1,17 @@
> +#include "qcom-msm8974.dtsi"
> +
> +/ {
> + model = "Sony Xperia Z1";
> + compatible = "sony,xperia-honami", "qcom,msm8974";
> +
> + memory@0 {
> + reg = <0 0x4000>, <0x4000 0x4000>;
> + device_type = "memory";
> + };
> +};
> +
> + {
> + serial@f991e000 {
> + status = "ok";
> + };
> +};
> --
> 1.8.2.2
>
--
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: [PATCH v3] ARM: dts: Add initial DTS file for Sony Xperia Z1 phone
Will not make the 3.18 merge window. I will queue it up for 3.19.
- k
On Oct 9, 2014, at 11:55 AM, Tim Bird tbird...@gmail.com wrote:
Kumar,
Any chance this could make the 3.18 merge window? Have you had time to take
a look at it?
-- Tim
On Tue, Sep 30, 2014 at 3:49 PM, Tim Bird tim.b...@sonymobile.com wrote:
This DTS has support for the Sony Xperia Z1 phone (codenamed Honami).
This first version of the DTS supports just a serial console.
changes from V2
- fixed dtb name in Makefile
changes from v1
- removed qcom,msm-id attribute
- removed mis-capitalized Qualcomm word
- changed dts file name
- added board-specific compatible-string
Signed-off-by: Tim Bird tim.b...@sonymobile.com
Tested-by: Kevin Hilman khil...@linaro.org
---
This version fixes the dtb name. I asked previously about adding to
qcom_dt_match,
but apparently board compatibles are being removed from that list in
mach_qcom/board.c
See https://lkml.org/lkml/2014/9/24/952
Kevin tested this (modulu re-adding back the qcom,msm-id). I have a new
mkqcdtbootimg which works without requiring the qcom,msm-id attribute,
that I'll send to Kevin shortly (and publish on github).
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile| 3 ++-
arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts | 17 +
3 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ac7269f..d3a4579 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -128,6 +128,7 @@ sirfSiRF Technology, Inc.
smsc Standard Microsystems Corporation
snps Synopsys, Inc.
solidrun SolidRun
+sony Sony Corporation
spansion Spansion Inc.
st STMicroelectronics
steST-Ericsson
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b8c5cd3..cf58321 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -343,7 +343,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8074-dragonboard.dtb \
qcom-apq8084-mtp.dtb \
qcom-msm8660-surf.dtb \
- qcom-msm8960-cdp.dtb
+ qcom-msm8960-cdp.dtb \
+ qcom-msm8974-sony-xperia-honami.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-bqcurie2.dtb \
rk3188-radxarock.dtb \
diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
new file mode 100644
index 000..21b
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -0,0 +1,17 @@
+#include qcom-msm8974.dtsi
+
+/ {
+ model = Sony Xperia Z1;
+ compatible = sony,xperia-honami, qcom,msm8974;
+
+ memory@0 {
+ reg = 0 0x4000, 0x4000 0x4000;
+ device_type = memory;
+ };
+};
+
+soc {
+ serial@f991e000 {
+ status = ok;
+ };
+};
--
1.8.2.2
--
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: [PATCH 2/2] input: pm8941-pwrkey: Add DT binding documentation
On Oct 6, 2014, at 8:12 PM, Bjorn Andersson
wrote:
> From: Courtney Cavin
>
> Signed-off-by: Courtney Cavin
> Signed-off-by: Bjorn Andersson
> ---
> .../bindings/input/qcom,pm8941-pwrkey.txt | 43
> 1 file changed, 43 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
>
> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> new file mode 100644
> index 000..4d75e2c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> @@ -0,0 +1,43 @@
> +Qualcomm PM8941 PMIC Power Key
> +
> +PROPERTIES
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be one of:
> + "qcom,pm8941-pwrkey"
> +
> +- reg:
> + Usage: required
> + Value type:
> + Definition: base address of registers for block
> +
> +- interrupts:
> + Usage: required
> + Value type:
> + Definition: key change interrupt; The format of the specifier is
> + defined by the binding document describing the node's
> + interrupt parent.
> +
> +- debounce:
> + Usage: optional
> + Value type:
> + Definition: time in microseconds that key must be pressed or released
> + for state change interrupt to trigger.
> +
> +- bias-pull-up:
> + Usage: optional
> + Value type:
boolean, is probably better than here.
> + Definition: presence of this property indicates that the KPDPWR_N pin
> + should be configured for pull up.
> +
> +EXAMPLE
> +
> + pwrkey@800 {
> + compatible = "qcom,pm8941-pwrkey";
> + reg = <0x800>;
> + interrupts = <0x0 0x8 0 0>;
> + debounce = <15625>;
> + bias-pull-up;
> + };
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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: [PATCH 2/2] input: pm8941-pwrkey: Add DT binding documentation
On Oct 6, 2014, at 8:12 PM, Bjorn Andersson bjorn.anders...@sonymobile.com
wrote:
From: Courtney Cavin courtney.ca...@sonymobile.com
Signed-off-by: Courtney Cavin courtney.ca...@sonymobile.com
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
.../bindings/input/qcom,pm8941-pwrkey.txt | 43
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
new file mode 100644
index 000..4d75e2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
@@ -0,0 +1,43 @@
+Qualcomm PM8941 PMIC Power Key
+
+PROPERTIES
+
+- compatible:
+ Usage: required
+ Value type: string
+ Definition: must be one of:
+ qcom,pm8941-pwrkey
+
+- reg:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: base address of registers for block
+
+- interrupts:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: key change interrupt; The format of the specifier is
+ defined by the binding document describing the node's
+ interrupt parent.
+
+- debounce:
+ Usage: optional
+ Value type: u32
+ Definition: time in microseconds that key must be pressed or released
+ for state change interrupt to trigger.
+
+- bias-pull-up:
+ Usage: optional
+ Value type: empty
boolean, is probably better than empty here.
+ Definition: presence of this property indicates that the KPDPWR_N pin
+ should be configured for pull up.
+
+EXAMPLE
+
+ pwrkey@800 {
+ compatible = qcom,pm8941-pwrkey;
+ reg = 0x800;
+ interrupts = 0x0 0x8 0 0;
+ debounce = 15625;
+ bias-pull-up;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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: [PATCH v1] clk: qcom: Add support for regmap clock dividers
On Oct 2, 2014, at 1:11 PM, Stephen Boyd wrote: > On 09/30/14 10:20, Georgi Djakov wrote: >> This patch expands the regmap support to allow registration of clock >> dividers. It just prepares for the introduction of a clkdiv driver, >> that will be in a separate patch. >> Such dividers are found in the Qualcomm PMIC chips such as PM8941, >> PMA8084 and others. > > We're going to need to rework the Makefile in clk/qcom so that we only > build certain pieces of the "library" when we need them. Right now the > directory is focused entirely on mmio clock controllers and if we put > the pmic clocks in there then we need to figure out a way to only build > the pmic pieces if only the pmic driver is selected and only build the > mmio pieces if the mmio drivers are selected. Would we ever not build the mmio drivers or do you mean something else? - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCH v1] clk: qcom: Add support for regmap clock dividers
On Oct 2, 2014, at 1:11 PM, Stephen Boyd sb...@codeaurora.org wrote: On 09/30/14 10:20, Georgi Djakov wrote: This patch expands the regmap support to allow registration of clock dividers. It just prepares for the introduction of a clkdiv driver, that will be in a separate patch. Such dividers are found in the Qualcomm PMIC chips such as PM8941, PMA8084 and others. We're going to need to rework the Makefile in clk/qcom so that we only build certain pieces of the library when we need them. Right now the directory is focused entirely on mmio clock controllers and if we put the pmic clocks in there then we need to figure out a way to only build the pmic pieces if only the pmic driver is selected and only build the mmio pieces if the mmio drivers are selected. Would we ever not build the mmio drivers or do you mean something else? - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCH v7 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On Sep 30, 2014, at 10:28 AM, Bjorn Andersson wrote: > On Wed 24 Sep 09:39 PDT 2014, Kumar Gala wrote: > >> >> On Sep 22, 2014, at 6:25 PM, Bjorn Andersson >> wrote: >> > > [..] > >>> diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt >>> b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt > > [..] > >>> +- qcom,ipc: >>> + Usage: required >>> + Value type: >>> + >>> + Definition: three entries specifying the outgoing ipc bit used for >>> + signaling the RPM: >>> + - phandle to a syscon node representing the apcs registers >>> + - u32 representing offset to the register within the >>> syscon >>> + - u32 representing the ipc bit within the register >>> + >> >> Does this really ever differ for the SoCs, and even if it does why do we need >> to encode it in DT. Can’t we determine it via the compatible setting? >> > > The two offsets could be hard coded, especially based on the compatible. > > But I don't know if it's worth respinning this just to get those two number > out > of here. Also this is now "symmetric" with the smd use cases, where it > shouldn't be hard coded. I do think its worth respinning until the DT is agreed to as we shouldn’t be changing the binding. I’m not sure how being ‘symmetric’ with the smd use case maters if we are treating this RPM support vs RPM-SMD as two different things. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [RFC 3/7] mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding
On Sep 29, 2014, at 7:34 PM, Bjorn Andersson
wrote:
> Add binding documentation for the Qualcomm Resource Power Manager (RPM)
> using shared memory (Qualcomm SMD) as transport mechanism. This is found
> in 8974 and newer based devices.
>
> The binding currently describes the rpm itself and the regulator
> subnodes.
>
> Signed-off-by: Bjorn Andersson
> ---
>
> Note that this patch extends the rpm dt-bindings header from [1].
>
> [1] https://lkml.org/lkml/2014/9/22/733
>
> .../devicetree/bindings/mfd/qcom-rpm-smd.txt | 122
> include/dt-bindings/mfd/qcom-rpm.h | 36 ++
> 2 files changed, 158 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> new file mode 100644
> index 000..a846101
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> @@ -0,0 +1,122 @@
> +Qualcomm Resource Power Manager (RPM) over SMD
> +
> +This driver is used to interface with the Resource Power Manager (RPM) found
> in
> +various Qualcomm platforms. The RPM allows each component in the system to
> vote
> +for state of the system resources, such as clocks, regulators and bus
> +frequencies.
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be one of:
> + "qcom,rpm-msm8974”
Why not “qcom,rpm-smd”. I’d like to get Jeff H’s input on how what we do here
for compat and distinguish the A-family RPM support vs B-family/RPM-SMD support.
> +
> +- qcom,smd-channels:
> + Usage: required
> + Value type:
> + Definition: Shared Memory Channel used for communication with the RPM
> +
This needs more details.
> +- #address-cells:
> + Usage: required
> + Value type:
> + Definition: must be 1
> +
> +- #size-cells:
> + Usage: required
> + Value type:
> + Definition: must be 0
> +
> += SUBDEVICES
As I mentioned for the the RPM binding on a-family, we should split out the
devices into their own binding specs.
> +
> +The RPM exposes resources to its subnodes. The below bindings specify the set
> +of valid subnodes that can operate on these resources.
> +
> +== Switch-mode Power Supply regulator
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be one of:
> + "qcom,rpm-pm8841-smps"
> + "qcom,rpm-pm8941-smps"
> +
> +
> +- reg:
> + Usage: required
> + Value type:
> + Definition: resource as defined in
> + must be one of:
> + QCOM_RPM_PM8841_SMPS1 - QCOM_RPM_PM8841_SMPS4,
> + QCOM_RPM_PM8941_SMPS1 - QCOM_RPM_PM8941_SMPS3
> +
> +Standard regulator bindings are used inside switch mode power supply
> subnodes.
> +Check Documentation/devicetree/bindings/regulator/regulator.txt for more
> +details.
> +
> +== Low-dropout regulator
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be one of:
> + "qcom,rpm-pm8941-ldo"
> +
> +- reg:
> + Usage: required
> + Value type:
> + Definition: resource as defined in
> + must be one of:
> + QCOM_RPM_PM8941_LDO1 - QCOM_RPM_PM8941_LDO24
> +
> +Standard regulator bindings are used inside switch low-dropout regulator
> +subnodes. Check Documentation/devicetree/bindings/regulator/regulator.txt
> for
> +more details.
> +
> +== Switch
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be one of:
> + "qcom,rpm-pm8941-switch"
> +
> +- reg:
> + Usage: required
> + Value type:
> + Definition: resource as defined in
> + must be one of:
> + QCOM_RPM_PM8941_LVS1 - QCOM_RPM_PM8941_LVS3,
> + QCOM_RPM_PM8941_MVS1 - QCOM_RPM_PM8941_MVS2
> +
> +Standard regulator bindings are used inside switch regulator subnodes. Check
> +Documentation/devicetree/bindings/regulator/regulator.txt for more details.
> +
> += EXAMPLE
> +
> + #include
> +
> + rpm@108000 {
> + compatible = "qcom,rpm-msm8960";
> + qcom,smd-channels = "rpm_requests";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pm8941_s1: regulator-s1 {
> + compatible = "qcom,rpm-pm8941-smps";
> + reg = ;
> +
> + regulator-min-microvolt = <130>;
> + regulator-max-microvolt = <130>;
> + };
> +
> + pm8941_l3: pm8941-l3 {
> + compatible = "qcom,rpm-pm8941-ldo";
> + reg = ;
> +
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + };
> +
> + };
> +
- k
--
Employee of Qualcomm
Re: [RFC 1/7] soc: qcom: Add device tree binding for SMEM
On Sep 29, 2014, at 7:34 PM, Bjorn Andersson
wrote:
> Add device tree binding documentation for the Qualcom Shared Memory
> manager.
>
> Signed-off-by: Bjorn Andersson
> ---
>
> Exposed by this node is a set of items of different sizes. For many things a
> standard of_xlate method of referencing the individual nodes would be
> preferable, so a #something-cells would make sense. We do however also needs
> access to these items without explicitly stating the references in devicetree
> (e.g. SMD references 257 of these). I haven't found any good example of how to
> implement this, so suggestions are welcome.
>
> Note that the hwspinlock reference is not yet supported in the mainline, but
> this will likely need a few iterations so I wanted to get this out.
>
> .../devicetree/bindings/soc/qcom/qcom,smem.txt | 34
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
> b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
> new file mode 100644
> index 000..ddd58c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
> @@ -0,0 +1,34 @@
> +Qualcomm Shared Memory binding
> +
> +This binding describes the Qualcomm Shared Memory, used to share data between
> +various subsystems and OSes in Qualcomm platforms.
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be:
> + "qcom,smem"
> +
> +- reg:
> + Usage: required
> + Value type:
> + Definition: base address and size pair for each area representing the
> + shared memory. The first pair will must represent the "main"
> + area, where the shared memory header and table-of-content
> + can be found.
> +
> +- hwspinlocks:
> + Usage: required
> + Value type:
> + Definition: reference to a hwspinlock used to protect allocations from
> + the shared memory
> +
> += EXAMPLE
> +
> +smem: smem@fa0 {
> +compatible = "qcom,smem";
> +reg = <0x0fa0 0x20>,
> + <0xfc428000 0x4000>;
> +
> +hwspinlocks = <_mutex 3>;
> +};
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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: [RFC 0/7] Qualcomm SMEM, SMD, RPM and regulators
On Sep 29, 2014, at 7:34 PM, Bjorn Andersson wrote: > All Qualcomm platforms implements a shared heap among the processors in the > SoC, used for sharing data with other parts of the system. > > One consumer of items from this heap is the "Shared Memory Driver", a ring > buffer based point-to-point communication mechanism used to send either stream > or packet based data to remote processors. > > Starting with 8x74 this system is used to talk to the Resource Power Manager > (RPM), a power efficient "coprocessor" with responsibility of aggregate votes > from the various systems in the SoC related to regulators, clocks and bus > frequencies. > > The PMIC regulators and root clocks in these platforms are only accessible via > the RPM, so to get access to these we need the full chain of smem, smd, rpm > and > a regulator driver implemented. And that is exactly what this series provides. > > > A key outstanding question is where in the tree we should put the > implementation, for now I dropped them in drivers/soc/qcom but that's only > because I don't know where to put it otherwise. I have not found any > equivalent > of the SMEM driver, SMD resembles mailbox and rpmsg - but comments in that > patch on why it's neither. > > RPM is a mfd and regulator is a regulator :) I still don’t see why RPM support for either A-family or B-family should exist in MFD vis drivers/soc/qcom. What benefit is there in putting this in MFD? I think both A and B-family support should be in drivers/soc/qcom for the current time being until we determine there is some framework that makes more sense in the future. I almost see RPM more like a bus controller than anything else. Something like an I2C bus controller that than has some set of devices off of that bus. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [RFC 3/7] mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding
On Sep 29, 2014, at 7:34 PM, Bjorn Andersson bjorn.anders...@sonymobile.com
wrote:
Add binding documentation for the Qualcomm Resource Power Manager (RPM)
using shared memory (Qualcomm SMD) as transport mechanism. This is found
in 8974 and newer based devices.
The binding currently describes the rpm itself and the regulator
subnodes.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
Note that this patch extends the rpm dt-bindings header from [1].
[1] https://lkml.org/lkml/2014/9/22/733
.../devicetree/bindings/mfd/qcom-rpm-smd.txt | 122
include/dt-bindings/mfd/qcom-rpm.h | 36 ++
2 files changed, 158 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
new file mode 100644
index 000..a846101
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
@@ -0,0 +1,122 @@
+Qualcomm Resource Power Manager (RPM) over SMD
+
+This driver is used to interface with the Resource Power Manager (RPM) found
in
+various Qualcomm platforms. The RPM allows each component in the system to
vote
+for state of the system resources, such as clocks, regulators and bus
+frequencies.
+
+- compatible:
+ Usage: required
+ Value type: string
+ Definition: must be one of:
+ qcom,rpm-msm8974”
Why not “qcom,rpm-smd”. I’d like to get Jeff H’s input on how what we do here
for compat and distinguish the A-family RPM support vs B-family/RPM-SMD support.
+
+- qcom,smd-channels:
+ Usage: required
+ Value type: stringlist
+ Definition: Shared Memory Channel used for communication with the RPM
+
This needs more details.
+- #address-cells:
+ Usage: required
+ Value type: u32
+ Definition: must be 1
+
+- #size-cells:
+ Usage: required
+ Value type: u32
+ Definition: must be 0
+
+= SUBDEVICES
As I mentioned for the the RPM binding on a-family, we should split out the
devices into their own binding specs.
+
+The RPM exposes resources to its subnodes. The below bindings specify the set
+of valid subnodes that can operate on these resources.
+
+== Switch-mode Power Supply regulator
+
+- compatible:
+ Usage: required
+ Value type: string
+ Definition: must be one of:
+ qcom,rpm-pm8841-smps
+ qcom,rpm-pm8941-smps
+
+
+- reg:
+ Usage: required
+ Value type: u32
+ Definition: resource as defined in dt-bindings/mfd/qcom-rpm.h
+ must be one of:
+ QCOM_RPM_PM8841_SMPS1 - QCOM_RPM_PM8841_SMPS4,
+ QCOM_RPM_PM8941_SMPS1 - QCOM_RPM_PM8941_SMPS3
+
+Standard regulator bindings are used inside switch mode power supply
subnodes.
+Check Documentation/devicetree/bindings/regulator/regulator.txt for more
+details.
+
+== Low-dropout regulator
+
+- compatible:
+ Usage: required
+ Value type: string
+ Definition: must be one of:
+ qcom,rpm-pm8941-ldo
+
+- reg:
+ Usage: required
+ Value type: u32
+ Definition: resource as defined in dt-bindings/mfd/qcom-rpm.h
+ must be one of:
+ QCOM_RPM_PM8941_LDO1 - QCOM_RPM_PM8941_LDO24
+
+Standard regulator bindings are used inside switch low-dropout regulator
+subnodes. Check Documentation/devicetree/bindings/regulator/regulator.txt
for
+more details.
+
+== Switch
+
+- compatible:
+ Usage: required
+ Value type: string
+ Definition: must be one of:
+ qcom,rpm-pm8941-switch
+
+- reg:
+ Usage: required
+ Value type: u32
+ Definition: resource as defined in dt-bindings/mfd/qcom/qcom-rpm.h
+ must be one of:
+ QCOM_RPM_PM8941_LVS1 - QCOM_RPM_PM8941_LVS3,
+ QCOM_RPM_PM8941_MVS1 - QCOM_RPM_PM8941_MVS2
+
+Standard regulator bindings are used inside switch regulator subnodes. Check
+Documentation/devicetree/bindings/regulator/regulator.txt for more details.
+
+= EXAMPLE
+
+ #include dt-bindings/mfd/qcom-rpm.h
+
+ rpm@108000 {
+ compatible = qcom,rpm-msm8960;
+ qcom,smd-channels = rpm_requests;
+
+ #address-cells = 1;
+ #size-cells = 0;
+
+ pm8941_s1: regulator-s1 {
+ compatible = qcom,rpm-pm8941-smps;
+ reg = QCOM_RPM_PM8941_SMPS1;
+
+ regulator-min-microvolt = 130;
+ regulator-max-microvolt = 130;
+ };
+
+ pm8941_l3: pm8941-l3 {
+ compatible = qcom,rpm-pm8941-ldo;
+ reg = QCOM_RPM_PM8941_LDO3;
+
+ regulator-min-microvolt = 120;
+
Re: [RFC 0/7] Qualcomm SMEM, SMD, RPM and regulators
On Sep 29, 2014, at 7:34 PM, Bjorn Andersson bjorn.anders...@sonymobile.com wrote: All Qualcomm platforms implements a shared heap among the processors in the SoC, used for sharing data with other parts of the system. One consumer of items from this heap is the Shared Memory Driver, a ring buffer based point-to-point communication mechanism used to send either stream or packet based data to remote processors. Starting with 8x74 this system is used to talk to the Resource Power Manager (RPM), a power efficient coprocessor with responsibility of aggregate votes from the various systems in the SoC related to regulators, clocks and bus frequencies. The PMIC regulators and root clocks in these platforms are only accessible via the RPM, so to get access to these we need the full chain of smem, smd, rpm and a regulator driver implemented. And that is exactly what this series provides. A key outstanding question is where in the tree we should put the implementation, for now I dropped them in drivers/soc/qcom but that's only because I don't know where to put it otherwise. I have not found any equivalent of the SMEM driver, SMD resembles mailbox and rpmsg - but comments in that patch on why it's neither. RPM is a mfd and regulator is a regulator :) I still don’t see why RPM support for either A-family or B-family should exist in MFD vis drivers/soc/qcom. What benefit is there in putting this in MFD? I think both A and B-family support should be in drivers/soc/qcom for the current time being until we determine there is some framework that makes more sense in the future. I almost see RPM more like a bus controller than anything else. Something like an I2C bus controller that than has some set of devices off of that bus. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [RFC 1/7] soc: qcom: Add device tree binding for SMEM
On Sep 29, 2014, at 7:34 PM, Bjorn Andersson bjorn.anders...@sonymobile.com
wrote:
Add device tree binding documentation for the Qualcom Shared Memory
manager.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
Exposed by this node is a set of items of different sizes. For many things a
standard of_xlate method of referencing the individual nodes would be
preferable, so a #something-cells would make sense. We do however also needs
access to these items without explicitly stating the references in devicetree
(e.g. SMD references 257 of these). I haven't found any good example of how to
implement this, so suggestions are welcome.
Note that the hwspinlock reference is not yet supported in the mainline, but
this will likely need a few iterations so I wanted to get this out.
.../devicetree/bindings/soc/qcom/qcom,smem.txt | 34
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
new file mode 100644
index 000..ddd58c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
@@ -0,0 +1,34 @@
+Qualcomm Shared Memory binding
+
+This binding describes the Qualcomm Shared Memory, used to share data between
+various subsystems and OSes in Qualcomm platforms.
+
+- compatible:
+ Usage: required
+ Value type: stringlist
+ Definition: must be:
+ qcom,smem
+
+- reg:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: base address and size pair for each area representing the
+ shared memory. The first pair will must represent the main
+ area, where the shared memory header and table-of-content
+ can be found.
+
+- hwspinlocks:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: reference to a hwspinlock used to protect allocations from
+ the shared memory
+
+= EXAMPLE
+
+smem: smem@fa0 {
+compatible = qcom,smem;
+reg = 0x0fa0 0x20,
+ 0xfc428000 0x4000;
+
+hwspinlocks = tcsr_mutex 3;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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: [PATCH v7 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On Sep 30, 2014, at 10:28 AM, Bjorn Andersson bjorn.anders...@sonymobile.com wrote: On Wed 24 Sep 09:39 PDT 2014, Kumar Gala wrote: On Sep 22, 2014, at 6:25 PM, Bjorn Andersson bjorn.anders...@sonymobile.com wrote: [..] diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt [..] +- qcom,ipc: + Usage: required + Value type: prop-encoded-array + + Definition: three entries specifying the outgoing ipc bit used for + signaling the RPM: + - phandle to a syscon node representing the apcs registers + - u32 representing offset to the register within the syscon + - u32 representing the ipc bit within the register + Does this really ever differ for the SoCs, and even if it does why do we need to encode it in DT. Can’t we determine it via the compatible setting? The two offsets could be hard coded, especially based on the compatible. But I don't know if it's worth respinning this just to get those two number out of here. Also this is now symmetric with the smd use cases, where it shouldn't be hard coded. I do think its worth respinning until the DT is agreed to as we shouldn’t be changing the binding. I’m not sure how being ‘symmetric’ with the smd use case maters if we are treating this RPM support vs RPM-SMD as two different things. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCH 2/2] soc/fsl: add ftm alarm driver for ls1021a platform
On Sep 26, 2014, at 1:48 AM, Dongsheng Wang wrote: > From: Wang Dongsheng > > Only Ftm0 can be used when system going to deep sleep. So this driver > to support ftm0 as a wakeup source. > > Signed-off-by: Wang Dongsheng How does this differ from drivers/clocksource/fsl_ftm_timer.c Why not extend that with the alarm functionality you need? Also, where is the DT binding spec for this (if you plan on having a separate driver)? - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCH 2/2] soc/fsl: add ftm alarm driver for ls1021a platform
On Sep 26, 2014, at 1:48 AM, Dongsheng Wang dongsheng.w...@freescale.com wrote: From: Wang Dongsheng dongsheng.w...@freescale.com Only Ftm0 can be used when system going to deep sleep. So this driver to support ftm0 as a wakeup source. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com How does this differ from drivers/clocksource/fsl_ftm_timer.c Why not extend that with the alarm functionality you need? Also, where is the DT binding spec for this (if you plan on having a separate driver)? - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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 defconfig changes for v3.18
On Sep 22, 2014, at 3:14 PM, Kumar Gala wrote: > The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: > > Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git > tags/qcom-defconfig-for-3.18 > > for you to fetch changes up to 3b6357a79b7b0a2c3b31c5c92d5dd0c51cda0391: > > ARM: qcom: Update defconfig (2014-09-22 13:59:08 -0500) > > > Qualcomm ARM Based defconfig Updates for v3.18 > > * General defconfig update to match upstream changes > * Enable IPQ806x & APQ8084 clk support > * Enable pinctrl on MSM8960 & APQ8084 > * Enable CPU_IDLE to get basic wfi support > * Enable SPI NOR and MTD M25P80 support (used on AP148 board) > * Enable SATA PHY support on IPQ806x and APQ8064 > * Enable Fixed regulator and ARM MMCI support (mmc support on APQ8064) > > > Kumar Gala (2): > ARM: qcom: Update defconfig > ARM: qcom: Update defconfig > > arch/arm/configs/qcom_defconfig | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) ping. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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.18 (updated)
On Sep 22, 2014, at 4:54 PM, Kumar Gala wrote:
> [ some how scm-boot.c got dropped, fixed now ]
>
> The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
>
> Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
>
> 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.18
>
> for you to fetch changes up to 6d42c5c5ce79b20139eec15dc359dfbcda3b3557:
>
> ARM: qcom: Move scm-boot files to drivers/soc and include/soc (2014-09-22
> 16:49:13 -0500)
>
>
> Qualcomm ARM Based SoC Updates for v3.18
>
> * 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
>
>
> Lina Iyer (2):
> ARM: qcom: Add SCM warmboot flags for quad core targets.
> ARM: qcom: 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
>
> Stephen Boyd (6):
> ARM: debug: Update MSM and QCOM DEBUG_LL help
> ARM: debug: msm: Support big-endian CPUs
> ARM: qcom: scm: Fix incorrect cache invalidation
> ARM: qcom: scm: Get cacheline size from CTR
> ARM: qcom: scm: Move the scm driver to drivers/soc/qcom
> ARM: qcom: scm: Add atomic SCM APIs
>
> 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 | 3 -
> 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 | 4 +-
> {arch/arm/mach-qcom => drivers/soc/qcom}/scm.c | 131 ++---
> .../arm/mach-qcom => include/soc/qcom}/scm-boot.h | 2 +
> {arch/arm/mach-qcom => include/soc/qcom}/scm.h | 5 +-
> 11 files changed, 137 insertions(+), 28 deletions(-)
> rename {arch/arm/mach-qcom => drivers/soc/qcom}/scm-boot.c (95%)
> rename {arch/arm/mach-qcom => drivers/soc/qcom}/scm.c (67%)
> rename {arch/arm/mach-qcom => include/soc/qcom}/scm-boot.h (92%)
> rename {arch/arm/mach-qcom => include/soc/qcom}/scm.h (80%)
> —
ping.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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.18 (updated)
On Sep 22, 2014, at 4:54 PM, Kumar Gala ga...@codeaurora.org wrote:
[ some how scm-boot.c got dropped, fixed now ]
The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
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.18
for you to fetch changes up to 6d42c5c5ce79b20139eec15dc359dfbcda3b3557:
ARM: qcom: Move scm-boot files to drivers/soc and include/soc (2014-09-22
16:49:13 -0500)
Qualcomm ARM Based SoC Updates for v3.18
* 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
Lina Iyer (2):
ARM: qcom: Add SCM warmboot flags for quad core targets.
ARM: qcom: 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
Stephen Boyd (6):
ARM: debug: Update MSM and QCOM DEBUG_LL help
ARM: debug: msm: Support big-endian CPUs
ARM: qcom: scm: Fix incorrect cache invalidation
ARM: qcom: scm: Get cacheline size from CTR
ARM: qcom: scm: Move the scm driver to drivers/soc/qcom
ARM: qcom: scm: Add atomic SCM APIs
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 | 3 -
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 | 4 +-
{arch/arm/mach-qcom = drivers/soc/qcom}/scm.c | 131 ++---
.../arm/mach-qcom = include/soc/qcom}/scm-boot.h | 2 +
{arch/arm/mach-qcom = include/soc/qcom}/scm.h | 5 +-
11 files changed, 137 insertions(+), 28 deletions(-)
rename {arch/arm/mach-qcom = drivers/soc/qcom}/scm-boot.c (95%)
rename {arch/arm/mach-qcom = drivers/soc/qcom}/scm.c (67%)
rename {arch/arm/mach-qcom = include/soc/qcom}/scm-boot.h (92%)
rename {arch/arm/mach-qcom = include/soc/qcom}/scm.h (80%)
—
ping.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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 defconfig changes for v3.18
On Sep 22, 2014, at 3:14 PM, Kumar Gala ga...@codeaurora.org wrote: The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-defconfig-for-3.18 for you to fetch changes up to 3b6357a79b7b0a2c3b31c5c92d5dd0c51cda0391: ARM: qcom: Update defconfig (2014-09-22 13:59:08 -0500) Qualcomm ARM Based defconfig Updates for v3.18 * General defconfig update to match upstream changes * Enable IPQ806x APQ8084 clk support * Enable pinctrl on MSM8960 APQ8084 * Enable CPU_IDLE to get basic wfi support * Enable SPI NOR and MTD M25P80 support (used on AP148 board) * Enable SATA PHY support on IPQ806x and APQ8064 * Enable Fixed regulator and ARM MMCI support (mmc support on APQ8064) Kumar Gala (2): ARM: qcom: Update defconfig ARM: qcom: Update defconfig arch/arm/configs/qcom_defconfig | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) ping. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCH] ARM: qcom: Update SoC compatibles we support
On Sep 24, 2014, at 1:34 PM, Stephen Boyd wrote: > On 09/24/14 11:20, Kumar Gala wrote: >> Move to just using the SoC name in the compatible list so we don't need >> to update this for every board going forward. Also added "qcom,msm8974" >> to the list as we support "qcom,apq8074" already (the modemless version >> of "qcom,msm8974"). >> >> Signed-off-by: Kumar Gala >> --- > > Or just remove the file entirely. Things work without having to add > anything here anyway. I’d prefer there to be some filter, but maybe you are right. I doubt we’ll add too many other platforms to this going forward. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCH v2] ARM: dts: Add initial DTS file for Sony Xperia Z1
On Sep 24, 2014, at 10:12 AM, Tim Bird wrote:
> This DTS has support for the Sony Xperia Z1 phone (codenamed Honami).
> This first version of the DTS supports just a serial console.
>
> changes from v1
> - removed qcom,msm-id attribute
> - removed mis-capitalized Qualcomm word
> - changed dts file name
> - added board-specific compatible-string
>
> Signed-off-by: Tim Bird
> —
Does this actually boot? I’d be surprised since “qcom,msm8974” isn’t in the
match table (just sent a patch for that).
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> arch/arm/boot/dts/Makefile| 3 ++-
> arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts | 17 +
> 3 files changed, 20 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index ac7269f..d3a4579 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -128,6 +128,7 @@ sirf SiRF Technology, Inc.
> smsc Standard Microsystems Corporation
> snps Synopsys, Inc.
> solidrun SolidRun
> +sony Sony Corporation
> spansion Spansion Inc.
> stSTMicroelectronics
> ste ST-Ericsson
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b8c5cd3..0c2702e 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -343,7 +343,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
> qcom-apq8074-dragonboard.dtb \
> qcom-apq8084-mtp.dtb \
> qcom-msm8660-surf.dtb \
> - qcom-msm8960-cdp.dtb
> + qcom-msm8960-cdp.dtb \
> + qcom-msm8974-sony-honami-xperia.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> rk3066a-bqcurie2.dtb \
> rk3188-radxarock.dtb \
> diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
> b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
> new file mode 100644
> index 000..21b
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
> @@ -0,0 +1,17 @@
> +#include "qcom-msm8974.dtsi"
> +
> +/ {
> + model = "Sony Xperia Z1";
> + compatible = "sony,xperia-honami", "qcom,msm8974";
> +
> + memory@0 {
> + reg = <0 0x4000>, <0x4000 0x4000>;
> + device_type = "memory";
> + };
> +};
> +
> + {
> + serial@f991e000 {
> + status = "ok";
> + };
> +};
> --
> 1.8.2.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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/
[PATCH] ARM: qcom: Update SoC compatibles we support
Move to just using the SoC name in the compatible list so we don't need
to update this for every board going forward. Also added "qcom,msm8974"
to the list as we support "qcom,apq8074" already (the modemless version
of "qcom,msm8974").
Signed-off-by: Kumar Gala
---
arch/arm/mach-qcom/board.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-qcom/board.c b/arch/arm/mach-qcom/board.c
index 6d8bbf7..e3e44aa 100644
--- a/arch/arm/mach-qcom/board.c
+++ b/arch/arm/mach-qcom/board.c
@@ -16,12 +16,13 @@
static const char * const qcom_dt_match[] __initconst = {
"qcom,apq8064",
- "qcom,apq8074-dragonboard",
+ "qcom,apq8074",
"qcom,apq8084",
"qcom,ipq8062",
"qcom,ipq8064",
- "qcom,msm8660-surf",
- "qcom,msm8960-cdp",
+ "qcom,msm8660",
+ "qcom,msm8960",
+ "qcom,msm8974",
NULL
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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: [PATCH v7 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On Sep 22, 2014, at 6:25 PM, Bjorn Andersson wrote: > Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660, > 8960 and 8064 based devices. The binding currently describes the rpm > itself and the regulator subnodes. > > Signed-off-by: Bjorn Andersson > --- > Documentation/devicetree/bindings/mfd/qcom-rpm.txt | 246 > include/dt-bindings/mfd/qcom-rpm.h | 154 > 2 files changed, 400 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/qcom-rpm.txt > create mode 100644 include/dt-bindings/mfd/qcom-rpm.h > > diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt > b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt > new file mode 100644 > index 000..4264021 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt > @@ -0,0 +1,246 @@ > +Qualcomm Resource Power Manager (RPM) > + > +This driver is used to interface with the Resource Power Manager (RPM) found > in > +various Qualcomm platforms. The RPM allows each component in the system to > vote > +for state of the system resources, such as clocks, regulators and bus > +frequencies. > + > +- compatible: > + Usage: required > + Value type: > + Definition: must be one of: > + "qcom,rpm-apq8064" > + "qcom,rpm-msm8660" > + "qcom,rpm-msm8960" > + > +- reg: > + Usage: required > + Value type: > + Definition: base address and size of the RPM's message ram > + > +- interrupts: > + Usage: required > + Value type: > + Definition: three entries specifying the RPM's: > + 1. acknowledgement interrupt > + 2. error interrupt > + 3. wakeup interrupt > + > +- interrupt-names: > + Usage: required > + Value type: > + Definition: must be the three strings "ack", "err" and "wakeup", in > order > + > +- #address-cells: > + Usage: required > + Value type: > + Definition: must be 1 > + > +- #size-cells: > + Usage: required > + Value type: > + Definition: must be 0 > + > +- qcom,ipc: > + Usage: required > + Value type: > + > + Definition: three entries specifying the outgoing ipc bit used for > + signaling the RPM: > + - phandle to a syscon node representing the apcs registers > + - u32 representing offset to the register within the syscon > + - u32 representing the ipc bit within the register > + Does this really ever differ for the SoCs, and even if it does why do we need to encode it in DT. Can’t we determine it via the compatible setting? > + > += SUBDEVICES These should be split out into their own specs/patches. > + > +The RPM exposes resources to its subnodes. The below bindings specify the set > +of valid subnodes that can operate on these resources. > + > +== Switch-mode Power Supply regulator > + > +- compatible: > + Usage: required > + Value type: > + Definition: must be one of: > + "qcom,rpm-pm8058-smps" > + "qcom,rpm-pm8901-ftsmps" > + "qcom,rpm-pm8921-smps" > + "qcom,rpm-pm8921-ftsmps" > + > +- reg: > + Usage: required > + Value type: > + Definition: resource as defined in > + must be one of: > + QCOM_RPM_PM8058_SMPS0 - QCOM_RPM_PM8058_SMPS4, > + QCOM_RPM_PM8821_SMPS1 - QCOM_RPM_PM8821_SMPS2, > + QCOM_RPM_PM8901_SMPS0 - QCOM_RPM_PM8901_SMPS4, > + QCOM_RPM_PM8921_SMPS1 - QCOM_RPM_PM8921_SMPS8 > + > +- bias-pull-down: > + Usage: optional > + Value type: > + Definition: enable pull down of the regulator when inactive > + > +- qcom,switch-mode-frequency: > + Usage: required > + Value type: > + Definition: Frequency (Hz) of the switch-mode power supply; > + must be one of: > + 1920, 960, 640, 480, 384, 320, > + 274, 240, 213, 192, 175, 160, > + 148, 137, 128, 120 > + > +- qcom,force-mode: > + Usage: optional (default if no other qcom,force-mode is specified) > + Value type: > + Defintion: indicates that the regulator should be forced to a > +particular mode, valid values are: > +QCOM_RPM_FORCE_MODE_NONE - do not force any mode > +QCOM_RPM_FORCE_MODE_LPM - force into low power mode > +QCOM_RPM_FORCE_MODE_HPM - force into high power mode > +QCOM_RPM_FORCE_MODE_AUTO - allow regulator to automatically > + select its own mode based on > + realtime current draw, only for: > + qcom,rpm-pm8921-smps, > + qcom,rpm-pm8921-ftsmps >
Re: [PATCH v7 3/3] regulator: qcom-rpm: Regulator driver for the Qualcomm RPM
On Sep 24, 2014, at 3:35 AM, Mark Brown wrote: > On Mon, Sep 22, 2014 at 04:25:29PM -0700, Bjorn Andersson wrote: >> Driver for regulators exposed by the Resource Power Manager (RPM) found >> in Qualcomm 8660, 8960 and 8064 based devices. > > Applied, thanks. Mark, can you drop this until we see at least an RFC patch for the RPM support for b-family SoCs (8074, 8084, etc) chips. The regulator could should either be the same or highly similar for b-family, but until we see the core RPM driver on the b-family SoCs we will not know that. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCH v7 0/3] Qualcomm Resource Power Manager driver
On Sep 23, 2014, at 11:27 PM, Bjorn Andersson wrote: > On Tue 23 Sep 01:17 PDT 2014, Srinivas Kandagatla wrote: > >> Hi Bjorn, >> >> Thankyou for the new patchset. >> >> I got few device-tree patches for apq8064 usb, sata, phy and hdmi which >> depend on rpm header file. It will be nice to get this functionality >> into 3.18. >> > > We should be able to send out the dts patches separate of these. > >> Do you think we should take these patches via arm-soc tree? >> > > Both Lee and Mark indicated that they will pull the parts individually. > However > both of the patches depend on the header file created in patch 1, someone > needs > to take both for it to work out? I wish we would wait to merge until we see support for b-family or at least an RFC patch for the b-family RPM support. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCH v7 0/3] Qualcomm Resource Power Manager driver
On Sep 23, 2014, at 11:27 PM, Bjorn Andersson bjorn.anders...@sonymobile.com wrote: On Tue 23 Sep 01:17 PDT 2014, Srinivas Kandagatla wrote: Hi Bjorn, Thankyou for the new patchset. I got few device-tree patches for apq8064 usb, sata, phy and hdmi which depend on rpm header file. It will be nice to get this functionality into 3.18. We should be able to send out the dts patches separate of these. Do you think we should take these patches via arm-soc tree? Both Lee and Mark indicated that they will pull the parts individually. However both of the patches depend on the header file created in patch 1, someone needs to take both for it to work out? I wish we would wait to merge until we see support for b-family or at least an RFC patch for the b-family RPM support. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCH v7 3/3] regulator: qcom-rpm: Regulator driver for the Qualcomm RPM
On Sep 24, 2014, at 3:35 AM, Mark Brown broo...@kernel.org wrote: On Mon, Sep 22, 2014 at 04:25:29PM -0700, Bjorn Andersson wrote: Driver for regulators exposed by the Resource Power Manager (RPM) found in Qualcomm 8660, 8960 and 8064 based devices. Applied, thanks. Mark, can you drop this until we see at least an RFC patch for the RPM support for b-family SoCs (8074, 8084, etc) chips. The regulator could should either be the same or highly similar for b-family, but until we see the core RPM driver on the b-family SoCs we will not know that. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCH v7 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On Sep 22, 2014, at 6:25 PM, Bjorn Andersson bjorn.anders...@sonymobile.com wrote: Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660, 8960 and 8064 based devices. The binding currently describes the rpm itself and the regulator subnodes. Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com --- Documentation/devicetree/bindings/mfd/qcom-rpm.txt | 246 include/dt-bindings/mfd/qcom-rpm.h | 154 2 files changed, 400 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/qcom-rpm.txt create mode 100644 include/dt-bindings/mfd/qcom-rpm.h diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt new file mode 100644 index 000..4264021 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt @@ -0,0 +1,246 @@ +Qualcomm Resource Power Manager (RPM) + +This driver is used to interface with the Resource Power Manager (RPM) found in +various Qualcomm platforms. The RPM allows each component in the system to vote +for state of the system resources, such as clocks, regulators and bus +frequencies. + +- compatible: + Usage: required + Value type: string + Definition: must be one of: + qcom,rpm-apq8064 + qcom,rpm-msm8660 + qcom,rpm-msm8960 + +- reg: + Usage: required + Value type: prop-encoded-array + Definition: base address and size of the RPM's message ram + +- interrupts: + Usage: required + Value type: prop-encoded-array + Definition: three entries specifying the RPM's: + 1. acknowledgement interrupt + 2. error interrupt + 3. wakeup interrupt + +- interrupt-names: + Usage: required + Value type: string-array + Definition: must be the three strings ack, err and wakeup, in order + +- #address-cells: + Usage: required + Value type: u32 + Definition: must be 1 + +- #size-cells: + Usage: required + Value type: u32 + Definition: must be 0 + +- qcom,ipc: + Usage: required + Value type: prop-encoded-array + + Definition: three entries specifying the outgoing ipc bit used for + signaling the RPM: + - phandle to a syscon node representing the apcs registers + - u32 representing offset to the register within the syscon + - u32 representing the ipc bit within the register + Does this really ever differ for the SoCs, and even if it does why do we need to encode it in DT. Can’t we determine it via the compatible setting? + += SUBDEVICES These should be split out into their own specs/patches. + +The RPM exposes resources to its subnodes. The below bindings specify the set +of valid subnodes that can operate on these resources. + +== Switch-mode Power Supply regulator + +- compatible: + Usage: required + Value type: string + Definition: must be one of: + qcom,rpm-pm8058-smps + qcom,rpm-pm8901-ftsmps + qcom,rpm-pm8921-smps + qcom,rpm-pm8921-ftsmps + +- reg: + Usage: required + Value type: u32 + Definition: resource as defined in dt-bindings/mfd/qcom-rpm.h + must be one of: + QCOM_RPM_PM8058_SMPS0 - QCOM_RPM_PM8058_SMPS4, + QCOM_RPM_PM8821_SMPS1 - QCOM_RPM_PM8821_SMPS2, + QCOM_RPM_PM8901_SMPS0 - QCOM_RPM_PM8901_SMPS4, + QCOM_RPM_PM8921_SMPS1 - QCOM_RPM_PM8921_SMPS8 + +- bias-pull-down: + Usage: optional + Value type: empty + Definition: enable pull down of the regulator when inactive + +- qcom,switch-mode-frequency: + Usage: required + Value type: u32 + Definition: Frequency (Hz) of the switch-mode power supply; + must be one of: + 1920, 960, 640, 480, 384, 320, + 274, 240, 213, 192, 175, 160, + 148, 137, 128, 120 + +- qcom,force-mode: + Usage: optional (default if no other qcom,force-mode is specified) + Value type: u32 + Defintion: indicates that the regulator should be forced to a +particular mode, valid values are: +QCOM_RPM_FORCE_MODE_NONE - do not force any mode +QCOM_RPM_FORCE_MODE_LPM - force into low power mode +QCOM_RPM_FORCE_MODE_HPM - force into high power mode +QCOM_RPM_FORCE_MODE_AUTO - allow regulator to automatically + select its own mode based on + realtime current draw, only for: + qcom,rpm-pm8921-smps, +
[PATCH] ARM: qcom: Update SoC compatibles we support
Move to just using the SoC name in the compatible list so we don't need
to update this for every board going forward. Also added qcom,msm8974
to the list as we support qcom,apq8074 already (the modemless version
of qcom,msm8974).
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
arch/arm/mach-qcom/board.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-qcom/board.c b/arch/arm/mach-qcom/board.c
index 6d8bbf7..e3e44aa 100644
--- a/arch/arm/mach-qcom/board.c
+++ b/arch/arm/mach-qcom/board.c
@@ -16,12 +16,13 @@
static const char * const qcom_dt_match[] __initconst = {
qcom,apq8064,
- qcom,apq8074-dragonboard,
+ qcom,apq8074,
qcom,apq8084,
qcom,ipq8062,
qcom,ipq8064,
- qcom,msm8660-surf,
- qcom,msm8960-cdp,
+ qcom,msm8660,
+ qcom,msm8960,
+ qcom,msm8974,
NULL
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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: [PATCH v2] ARM: dts: Add initial DTS file for Sony Xperia Z1
On Sep 24, 2014, at 10:12 AM, Tim Bird tim.b...@sonymobile.com wrote:
This DTS has support for the Sony Xperia Z1 phone (codenamed Honami).
This first version of the DTS supports just a serial console.
changes from v1
- removed qcom,msm-id attribute
- removed mis-capitalized Qualcomm word
- changed dts file name
- added board-specific compatible-string
Signed-off-by: Tim Bird tim.b...@sonymobile.com
—
Does this actually boot? I’d be surprised since “qcom,msm8974” isn’t in the
match table (just sent a patch for that).
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile| 3 ++-
arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts | 17 +
3 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ac7269f..d3a4579 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -128,6 +128,7 @@ sirf SiRF Technology, Inc.
smsc Standard Microsystems Corporation
snps Synopsys, Inc.
solidrun SolidRun
+sony Sony Corporation
spansion Spansion Inc.
stSTMicroelectronics
ste ST-Ericsson
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b8c5cd3..0c2702e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -343,7 +343,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8074-dragonboard.dtb \
qcom-apq8084-mtp.dtb \
qcom-msm8660-surf.dtb \
- qcom-msm8960-cdp.dtb
+ qcom-msm8960-cdp.dtb \
+ qcom-msm8974-sony-honami-xperia.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-bqcurie2.dtb \
rk3188-radxarock.dtb \
diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
new file mode 100644
index 000..21b
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -0,0 +1,17 @@
+#include qcom-msm8974.dtsi
+
+/ {
+ model = Sony Xperia Z1;
+ compatible = sony,xperia-honami, qcom,msm8974;
+
+ memory@0 {
+ reg = 0 0x4000, 0x4000 0x4000;
+ device_type = memory;
+ };
+};
+
+soc {
+ serial@f991e000 {
+ status = ok;
+ };
+};
--
1.8.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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: [PATCH] ARM: qcom: Update SoC compatibles we support
On Sep 24, 2014, at 1:34 PM, Stephen Boyd sb...@codeaurora.org wrote: On 09/24/14 11:20, Kumar Gala wrote: Move to just using the SoC name in the compatible list so we don't need to update this for every board going forward. Also added qcom,msm8974 to the list as we support qcom,apq8074 already (the modemless version of qcom,msm8974). Signed-off-by: Kumar Gala ga...@codeaurora.org --- Or just remove the file entirely. Things work without having to add anything here anyway. I’d prefer there to be some filter, but maybe you are right. I doubt we’ll add too many other platforms to this going forward. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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/
[PATCH 2/2] ARM: dts: qcom: Add SATA support on IPQ8064/AP148
Add SATA PHY and SATA AHCI controller nodes to device tree to enable
generic ahci support on the IPQ8064/AP148 board.
Signed-off-by: Kumar Gala
---
arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 8
arch/arm/boot/dts/qcom-ipq8064.dtsi | 33
2 files changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index 95e6495..55b2910 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -81,5 +81,13 @@
};
};
};
+
+ sata-phy@1b40 {
+ status = "ok";
+ };
+
+ sata@2900 {
+ status = "ok";
+ };
};
};
diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 244f857..63b2146 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -234,6 +234,39 @@
};
};
+ sata_phy: sata-phy@1b40 {
+ compatible = "qcom,ipq806x-sata-phy";
+ reg = <0x1b40 0x200>;
+
+ clocks = < SATA_PHY_CFG_CLK>;
+ clock-names = "cfg";
+
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ sata@2900 {
+ compatible = "qcom,ipq806x-ahci", "generic-ahci";
+ reg = <0x2900 0x180>;
+
+ interrupts = <0 209 0x0>;
+
+ clocks = < SFAB_SATA_S_H_CLK>,
+< SATA_H_CLK>,
+< SATA_A_CLK>,
+< SATA_RXOOB_CLK>,
+< SATA_PMALIVE_CLK>;
+ clock-names = "slave_face", "iface", "core",
+ "rxoob", "pmalive";
+
+ assigned-clocks = < SATA_RXOOB_CLK>, <
SATA_PMALIVE_CLK>;
+ assigned-clock-rates = <1>, <1>;
+
+ phys = <_phy>;
+ phy-names = "sata-phy";
+ status = "disabled";
+ };
+
qcom,ssbi@50 {
compatible = "qcom,ssbi";
reg = <0x0050 0x1000>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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/
[PATCH 1/2] ARM: qcom: Update defconfig
* Enable ATA & AHCI platform support to get SATA on IPQ806x platforms Signed-off-by: Kumar Gala --- arch/arm/configs/qcom_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig index 8c7da33..05372f1 100644 --- a/arch/arm/configs/qcom_defconfig +++ b/arch/arm/configs/qcom_defconfig @@ -57,13 +57,14 @@ CONFIG_MTD_M25P80=y CONFIG_MTD_SPI_NOR=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y -CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_SG=y CONFIG_CHR_DEV_SCH=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y +CONFIG_ATA=y +CONFIG_SATA_AHCI_PLATFORM=y CONFIG_NETDEVICES=y CONFIG_DUMMY=y CONFIG_MDIO_BITBANG=y -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCH v3] power: reset: use restart_notifier mechanism for msm-poweroff
On Sep 23, 2014, at 12:55 PM, Josh Cartwright wrote: > On Tue, Sep 23, 2014 at 12:48:42PM -0500, Kumar Gala wrote: >> >> On Sep 23, 2014, at 1:28 AM, Pramod Gurav >> wrote: >> >>> +linux-arm-msm >>> On Tuesday 23 September 2014 11:38 AM, Pramod Gurav wrote: >>>> This change replaces use of arm_pm_restart with recently introduced >>>> reset mechanism in Linux kernel called restart_notifier. >> >> Can you update the commit message to include details about the priority >> level we are setting it to. >> >> Probably something like Josh had: >> >> Choose priority 128, as according to documentation, this mechanism "is >> sufficient to restart the entire system?. >> >> Hmm, what happens if we have ps_hold restart and msm-poweroff enabled. >> Which one should have priority? > > I would hope we would avoid a situation where both this driver is > probed, and the pinctrl-msm driver has registered a restart handler? > > That is, we wouldn't ever mix the pinctrl-msm ps_hold mechanism (for > MSM8660/MSM8960/APQ8064, etc) and msm-poweroff (APQ8074 and later). Is > this a case you're worried about? Yes, I’m worried about possibly case of having both solutions on a device. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCH v3] power: reset: use restart_notifier mechanism for msm-poweroff
On Sep 23, 2014, at 1:28 AM, Pramod Gurav wrote:
> +linux-arm-msm
> On Tuesday 23 September 2014 11:38 AM, Pramod Gurav wrote:
>> This change replaces use of arm_pm_restart with recently introduced
>> reset mechanism in Linux kernel called restart_notifier.
Can you update the commit message to include details about the priority level
we are setting it to.
Probably something like Josh had:
Choose priority 128, as according to documentation, this mechanism "is
sufficient to restart the entire system”.
Hmm, what happens if we have ps_hold restart and msm-poweroff enabled. Which
one should have priority?
>>
>> Reviewed-by: Guenter Roeck
>> Cc: Guenter Roeck
>> Cc: Josh Cartwright
>> Cc: Sebastian Reichel
>> Cc: Dmitry Eremin-Solenikov
>> Cc: David Woodhouse
>> Cc: Stephen Boyd
>> Cc: linux...@vger.kernel.org
>>
>> Signed-off-by: Pramod Gurav
>> ---
>> Tested on Dragonboard APQ8074
>>
>> Changes since v2:
>> - Removed unwanted header file and added linux/pm.h
>>
>> Changes since v1:
>> - Initialized restart_nb with its declaration
>> - Removed return check for register_restart_handler as it always
>> returns 0 as per Guenter's suggestion to Josh's similar patch.
>> This takes care of Guenter's comments on error logs and NULL
>> initialization of restart_nb.notifier_call.
>> ---
>> drivers/power/reset/msm-poweroff.c | 20 ++--
>> 1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/power/reset/msm-poweroff.c
>> b/drivers/power/reset/msm-poweroff.c
>> index 774f9a3..4702efd 100644
>> --- a/drivers/power/reset/msm-poweroff.c
>> +++ b/drivers/power/reset/msm-poweroff.c
>> @@ -20,21 +20,27 @@
>> #include
>> #include
>> #include
>> -
>> -#include
>> +#include
>>
>> static void __iomem *msm_ps_hold;
>> -
>> -static void do_msm_restart(enum reboot_mode reboot_mode, const char *cmd)
>> +static int do_msm_restart(struct notifier_block *nb, unsigned long action,
>> + void *data)
>> {
>> writel(0, msm_ps_hold);
>> mdelay(1);
>> +
>> +return NOTIFY_DONE;
>> }
>>
>> +static struct notifier_block restart_nb = {
>> +.notifier_call = do_msm_restart,
>> +.priority = 128,
>> +};
>> +
>> static void do_msm_poweroff(void)
>> {
>> /* TODO: Add poweroff capability */
>> -do_msm_restart(REBOOT_HARD, NULL);
>> +do_msm_restart(_nb, 0, NULL);
>> }
>>
>> static int msm_restart_probe(struct platform_device *pdev)
>> @@ -47,8 +53,10 @@ static int msm_restart_probe(struct platform_device *pdev)
>> if (IS_ERR(msm_ps_hold))
>> return PTR_ERR(msm_ps_hold);
>>
>> +register_restart_handler(_nb);
>> +
>> pm_power_off = do_msm_poweroff;
>> -arm_pm_restart = do_msm_restart;
>> +
>> return 0;
>> }
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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: [PATCH] ARM: qcom: Fix SCM interface for big-endian kernels
On Sep 23, 2014, at 12:42 PM, Stephen Boyd wrote:
> On 09/23/14 09:47, Kumar Gala wrote:
>> On Sep 22, 2014, at 5:36 PM, Stephen Boyd wrote:
>>
>>> The secure environment only runs in little-endian mode, so any
>>> buffers shared with the secure environment should have their
>>> contents converted to little-endian. We also mark such elements
>>> with __le32 to allow sparse to catch such problems.
>>>
>>> Signed-off-by: Stephen Boyd
>>> ---
>>> drivers/soc/qcom/scm-boot.c | 8
>>> drivers/soc/qcom/scm.c | 34 ++
>>> 2 files changed, 22 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/drivers/soc/qcom/scm-boot.c b/drivers/soc/qcom/scm-boot.c
>>> index 60ff7b482141..3e4d77b371c6 100644
>>> --- a/drivers/soc/qcom/scm-boot.c
>>> +++ b/drivers/soc/qcom/scm-boot.c
>>> @@ -27,12 +27,12 @@
>>> int scm_set_boot_addr(phys_addr_t addr, int flags)
>>> {
>>> struct {
>>> - unsigned int flags;
>>> - phys_addr_t addr;
>>> + __le32 flags;
>>> + __le32 addr;
>> Hmm, was phys_addr_t wrong here before? I ask because don’t we support LPAE
>> on some systems?
>
> Yes it was wrong. It is exactly 32 bits wide.
So we should probably have a patch to fix the interface scm_set_boot_addr() to
take a u32 addr instead of a phys_addr_t
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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: [PATCH] ARM: qcom: Fix SCM interface for big-endian kernels
On Sep 22, 2014, at 5:36 PM, Stephen Boyd wrote:
> The secure environment only runs in little-endian mode, so any
> buffers shared with the secure environment should have their
> contents converted to little-endian. We also mark such elements
> with __le32 to allow sparse to catch such problems.
>
> Signed-off-by: Stephen Boyd
> ---
> drivers/soc/qcom/scm-boot.c | 8
> drivers/soc/qcom/scm.c | 34 ++
> 2 files changed, 22 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/soc/qcom/scm-boot.c b/drivers/soc/qcom/scm-boot.c
> index 60ff7b482141..3e4d77b371c6 100644
> --- a/drivers/soc/qcom/scm-boot.c
> +++ b/drivers/soc/qcom/scm-boot.c
> @@ -27,12 +27,12 @@
> int scm_set_boot_addr(phys_addr_t addr, int flags)
> {
> struct {
> - unsigned int flags;
> - phys_addr_t addr;
> + __le32 flags;
> + __le32 addr;
Hmm, was phys_addr_t wrong here before? I ask because don’t we support LPAE on
some systems?
> } cmd;
>
> - cmd.addr = addr;
> - cmd.flags = flags;
> + cmd.addr = cpu_to_le32(addr);
> + cmd.flags = cpu_to_le32(flags);
> return scm_call(SCM_SVC_BOOT, SCM_BOOT_ADDR,
> , sizeof(cmd), NULL, 0);
> }
> diff --git a/drivers/soc/qcom/scm.c b/drivers/soc/qcom/scm.c
> index be1e2beec796..feeb4e4bb22d 100644
> --- a/drivers/soc/qcom/scm.c
> +++ b/drivers/soc/qcom/scm.c
> @@ -62,11 +62,11 @@ static DEFINE_MUTEX(scm_lock);
> * to access the buffers in a safe manner.
> */
> struct scm_command {
> - u32 len;
> - u32 buf_offset;
> - u32 resp_hdr_offset;
> - u32 id;
> - u32 buf[0];
> + __le32 len;
> + __le32 buf_offset;
> + __le32 resp_hdr_offset;
> + __le32 id;
> + __le32 buf[0];
> };
>
> /**
> @@ -76,9 +76,9 @@ struct scm_command {
> * @is_complete: indicates if the command has finished processing
> */
> struct scm_response {
> - u32 len;
> - u32 buf_offset;
> - u32 is_complete;
> + __le32 len;
> + __le32 buf_offset;
> + __le32 is_complete;
> };
>
> /**
> @@ -96,12 +96,14 @@ static struct scm_command *alloc_scm_command(size_t
> cmd_size, size_t resp_size)
> struct scm_command *cmd;
> size_t len = sizeof(*cmd) + sizeof(struct scm_response) + cmd_size +
> resp_size;
> + u32 offset;
>
> cmd = kzalloc(PAGE_ALIGN(len), GFP_KERNEL);
> if (cmd) {
> - cmd->len = len;
> - cmd->buf_offset = offsetof(struct scm_command, buf);
> - cmd->resp_hdr_offset = cmd->buf_offset + cmd_size;
> + cmd->len = cpu_to_le32(len);
> + offset = offsetof(struct scm_command, buf);
> + cmd->buf_offset = cpu_to_le32(offset);
> + cmd->resp_hdr_offset = cpu_to_le32(offset + cmd_size);
> }
> return cmd;
> }
> @@ -126,7 +128,7 @@ static inline void free_scm_command(struct scm_command
> *cmd)
> static inline struct scm_response *scm_command_to_response(
> const struct scm_command *cmd)
> {
> - return (void *)cmd + cmd->resp_hdr_offset;
> + return (void *)cmd + le32_to_cpu(cmd->resp_hdr_offset);
> }
>
> /**
> @@ -148,7 +150,7 @@ static inline void *scm_get_command_buffer(const struct
> scm_command *cmd)
> */
> static inline void *scm_get_response_buffer(const struct scm_response *rsp)
> {
> - return (void *)rsp + rsp->buf_offset;
> + return (void *)rsp + le32_to_cpu(rsp->buf_offset);
> }
>
> static int scm_remap_error(int err)
> @@ -201,8 +203,8 @@ static int __scm_call(const struct scm_command *cmd)
>* Flush the command buffer so that the secure world sees
>* the correct data.
>*/
> - __cpuc_flush_dcache_area((void *)cmd, cmd->len);
> - outer_flush_range(cmd_addr, cmd_addr + cmd->len);
> + __cpuc_flush_dcache_area((void *)cmd, le32_to_cpu(cmd->len));
> + outer_flush_range(cmd_addr, cmd_addr + le32_to_cpu(cmd->len));
>
> ret = smc(cmd_addr);
> if (ret < 0)
> @@ -260,7 +262,7 @@ int scm_call(u32 svc_id, u32 cmd_id, const void *cmd_buf,
> size_t cmd_len,
> if (!cmd)
> return -ENOMEM;
>
> - cmd->id = (svc_id << 10) | cmd_id;
> + cmd->id = cpu_to_le32((svc_id << 10) | cmd_id);
> if (cmd_buf)
> memcpy(scm_get_command_buffer(cmd), cmd_buf, cmd_len);
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH] ARM: qcom: Fix SCM interface for big-endian kernels
On Sep 22, 2014, at 5:36 PM, Stephen Boyd sb...@codeaurora.org wrote:
The secure environment only runs in little-endian mode, so any
buffers shared with the secure environment should have their
contents converted to little-endian. We also mark such elements
with __le32 to allow sparse to catch such problems.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/soc/qcom/scm-boot.c | 8
drivers/soc/qcom/scm.c | 34 ++
2 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/drivers/soc/qcom/scm-boot.c b/drivers/soc/qcom/scm-boot.c
index 60ff7b482141..3e4d77b371c6 100644
--- a/drivers/soc/qcom/scm-boot.c
+++ b/drivers/soc/qcom/scm-boot.c
@@ -27,12 +27,12 @@
int scm_set_boot_addr(phys_addr_t addr, int flags)
{
struct {
- unsigned int flags;
- phys_addr_t addr;
+ __le32 flags;
+ __le32 addr;
Hmm, was phys_addr_t wrong here before? I ask because don’t we support LPAE on
some systems?
} cmd;
- cmd.addr = addr;
- cmd.flags = flags;
+ cmd.addr = cpu_to_le32(addr);
+ cmd.flags = cpu_to_le32(flags);
return scm_call(SCM_SVC_BOOT, SCM_BOOT_ADDR,
cmd, sizeof(cmd), NULL, 0);
}
diff --git a/drivers/soc/qcom/scm.c b/drivers/soc/qcom/scm.c
index be1e2beec796..feeb4e4bb22d 100644
--- a/drivers/soc/qcom/scm.c
+++ b/drivers/soc/qcom/scm.c
@@ -62,11 +62,11 @@ static DEFINE_MUTEX(scm_lock);
* to access the buffers in a safe manner.
*/
struct scm_command {
- u32 len;
- u32 buf_offset;
- u32 resp_hdr_offset;
- u32 id;
- u32 buf[0];
+ __le32 len;
+ __le32 buf_offset;
+ __le32 resp_hdr_offset;
+ __le32 id;
+ __le32 buf[0];
};
/**
@@ -76,9 +76,9 @@ struct scm_command {
* @is_complete: indicates if the command has finished processing
*/
struct scm_response {
- u32 len;
- u32 buf_offset;
- u32 is_complete;
+ __le32 len;
+ __le32 buf_offset;
+ __le32 is_complete;
};
/**
@@ -96,12 +96,14 @@ static struct scm_command *alloc_scm_command(size_t
cmd_size, size_t resp_size)
struct scm_command *cmd;
size_t len = sizeof(*cmd) + sizeof(struct scm_response) + cmd_size +
resp_size;
+ u32 offset;
cmd = kzalloc(PAGE_ALIGN(len), GFP_KERNEL);
if (cmd) {
- cmd-len = len;
- cmd-buf_offset = offsetof(struct scm_command, buf);
- cmd-resp_hdr_offset = cmd-buf_offset + cmd_size;
+ cmd-len = cpu_to_le32(len);
+ offset = offsetof(struct scm_command, buf);
+ cmd-buf_offset = cpu_to_le32(offset);
+ cmd-resp_hdr_offset = cpu_to_le32(offset + cmd_size);
}
return cmd;
}
@@ -126,7 +128,7 @@ static inline void free_scm_command(struct scm_command
*cmd)
static inline struct scm_response *scm_command_to_response(
const struct scm_command *cmd)
{
- return (void *)cmd + cmd-resp_hdr_offset;
+ return (void *)cmd + le32_to_cpu(cmd-resp_hdr_offset);
}
/**
@@ -148,7 +150,7 @@ static inline void *scm_get_command_buffer(const struct
scm_command *cmd)
*/
static inline void *scm_get_response_buffer(const struct scm_response *rsp)
{
- return (void *)rsp + rsp-buf_offset;
+ return (void *)rsp + le32_to_cpu(rsp-buf_offset);
}
static int scm_remap_error(int err)
@@ -201,8 +203,8 @@ static int __scm_call(const struct scm_command *cmd)
* Flush the command buffer so that the secure world sees
* the correct data.
*/
- __cpuc_flush_dcache_area((void *)cmd, cmd-len);
- outer_flush_range(cmd_addr, cmd_addr + cmd-len);
+ __cpuc_flush_dcache_area((void *)cmd, le32_to_cpu(cmd-len));
+ outer_flush_range(cmd_addr, cmd_addr + le32_to_cpu(cmd-len));
ret = smc(cmd_addr);
if (ret 0)
@@ -260,7 +262,7 @@ int scm_call(u32 svc_id, u32 cmd_id, const void *cmd_buf,
size_t cmd_len,
if (!cmd)
return -ENOMEM;
- cmd-id = (svc_id 10) | cmd_id;
+ cmd-id = cpu_to_le32((svc_id 10) | cmd_id);
if (cmd_buf)
memcpy(scm_get_command_buffer(cmd), cmd_buf, cmd_len);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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
Re: [PATCH] ARM: qcom: Fix SCM interface for big-endian kernels
On Sep 23, 2014, at 12:42 PM, Stephen Boyd sb...@codeaurora.org wrote:
On 09/23/14 09:47, Kumar Gala wrote:
On Sep 22, 2014, at 5:36 PM, Stephen Boyd sb...@codeaurora.org wrote:
The secure environment only runs in little-endian mode, so any
buffers shared with the secure environment should have their
contents converted to little-endian. We also mark such elements
with __le32 to allow sparse to catch such problems.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/soc/qcom/scm-boot.c | 8
drivers/soc/qcom/scm.c | 34 ++
2 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/drivers/soc/qcom/scm-boot.c b/drivers/soc/qcom/scm-boot.c
index 60ff7b482141..3e4d77b371c6 100644
--- a/drivers/soc/qcom/scm-boot.c
+++ b/drivers/soc/qcom/scm-boot.c
@@ -27,12 +27,12 @@
int scm_set_boot_addr(phys_addr_t addr, int flags)
{
struct {
- unsigned int flags;
- phys_addr_t addr;
+ __le32 flags;
+ __le32 addr;
Hmm, was phys_addr_t wrong here before? I ask because don’t we support LPAE
on some systems?
Yes it was wrong. It is exactly 32 bits wide.
So we should probably have a patch to fix the interface scm_set_boot_addr() to
take a u32 addr instead of a phys_addr_t
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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: [PATCH v3] power: reset: use restart_notifier mechanism for msm-poweroff
On Sep 23, 2014, at 1:28 AM, Pramod Gurav pramod.gu...@smartplayin.com wrote:
+linux-arm-msm
On Tuesday 23 September 2014 11:38 AM, Pramod Gurav wrote:
This change replaces use of arm_pm_restart with recently introduced
reset mechanism in Linux kernel called restart_notifier.
Can you update the commit message to include details about the priority level
we are setting it to.
Probably something like Josh had:
Choose priority 128, as according to documentation, this mechanism is
sufficient to restart the entire system”.
Hmm, what happens if we have ps_hold restart and msm-poweroff enabled. Which
one should have priority?
Reviewed-by: Guenter Roeck li...@roeck-us.net
Cc: Guenter Roeck li...@roeck-us.net
Cc: Josh Cartwright jo...@codeaurora.org
Cc: Sebastian Reichel s...@kernel.org
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: David Woodhouse dw...@infradead.org
Cc: Stephen Boyd sb...@codeaurora.org
Cc: linux...@vger.kernel.org
Signed-off-by: Pramod Gurav pramod.gu...@smartplayin.com
---
Tested on Dragonboard APQ8074
Changes since v2:
- Removed unwanted header file and added linux/pm.h
Changes since v1:
- Initialized restart_nb with its declaration
- Removed return check for register_restart_handler as it always
returns 0 as per Guenter's suggestion to Josh's similar patch.
This takes care of Guenter's comments on error logs and NULL
initialization of restart_nb.notifier_call.
---
drivers/power/reset/msm-poweroff.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/power/reset/msm-poweroff.c
b/drivers/power/reset/msm-poweroff.c
index 774f9a3..4702efd 100644
--- a/drivers/power/reset/msm-poweroff.c
+++ b/drivers/power/reset/msm-poweroff.c
@@ -20,21 +20,27 @@
#include linux/platform_device.h
#include linux/module.h
#include linux/reboot.h
-
-#include asm/system_misc.h
+#include linux/pm.h
static void __iomem *msm_ps_hold;
-
-static void do_msm_restart(enum reboot_mode reboot_mode, const char *cmd)
+static int do_msm_restart(struct notifier_block *nb, unsigned long action,
+ void *data)
{
writel(0, msm_ps_hold);
mdelay(1);
+
+return NOTIFY_DONE;
}
+static struct notifier_block restart_nb = {
+.notifier_call = do_msm_restart,
+.priority = 128,
+};
+
static void do_msm_poweroff(void)
{
/* TODO: Add poweroff capability */
-do_msm_restart(REBOOT_HARD, NULL);
+do_msm_restart(restart_nb, 0, NULL);
}
static int msm_restart_probe(struct platform_device *pdev)
@@ -47,8 +53,10 @@ static int msm_restart_probe(struct platform_device *pdev)
if (IS_ERR(msm_ps_hold))
return PTR_ERR(msm_ps_hold);
+register_restart_handler(restart_nb);
+
pm_power_off = do_msm_poweroff;
-arm_pm_restart = do_msm_restart;
+
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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: [PATCH v3] power: reset: use restart_notifier mechanism for msm-poweroff
On Sep 23, 2014, at 12:55 PM, Josh Cartwright jo...@codeaurora.org wrote: On Tue, Sep 23, 2014 at 12:48:42PM -0500, Kumar Gala wrote: On Sep 23, 2014, at 1:28 AM, Pramod Gurav pramod.gu...@smartplayin.com wrote: +linux-arm-msm On Tuesday 23 September 2014 11:38 AM, Pramod Gurav wrote: This change replaces use of arm_pm_restart with recently introduced reset mechanism in Linux kernel called restart_notifier. Can you update the commit message to include details about the priority level we are setting it to. Probably something like Josh had: Choose priority 128, as according to documentation, this mechanism is sufficient to restart the entire system?. Hmm, what happens if we have ps_hold restart and msm-poweroff enabled. Which one should have priority? I would hope we would avoid a situation where both this driver is probed, and the pinctrl-msm driver has registered a restart handler? That is, we wouldn't ever mix the pinctrl-msm ps_hold mechanism (for MSM8660/MSM8960/APQ8064, etc) and msm-poweroff (APQ8074 and later). Is this a case you're worried about? Yes, I’m worried about possibly case of having both solutions on a device. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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/
