Re: [PATCH 5/9] clk: qcom: gcc-msm8960: add child devices support.
On 09/09/2015 09:03 AM, Rajendra Nayak wrote: On 09/09/2015 12:51 AM, Stephen Boyd wrote: On 09/07, Rajendra Nayak wrote: Yeah this might happen though because we've assigned the of_node pointer to the tsens device before we register it on the platform bus. The other way to pass that data down from gcc to tsens would be to not have an of_node assigned to the tsens device, and check for that case in the tsens driver. If there isn't an of_node, then we look at the parent device's of_node to figure out which gcc it is (if this even matters) and parse DT properties. Parsing DT properties from parent (in the tsens driver) is fine, but the nvmem apis still expect an of_node for the tsens device and hence fail. So pass the parent device to the nvmem APIs? Or adjust the nvmem APIs to look for a parent of_node if there isn't an of_node for the device being passed? Or make the nvmem APIs work without using DT, and copy over the nvmem information from the gcc node to the virtual tsens child device? Srini, you being the nvmem maintainer, any thoughts? passing the parent device to nvmem APIs seems the cleanest to me, without having to change much with the nvmem APIs itself. -- 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-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] clk: qcom: gcc-msm8960: add child devices support.
On 09/09/2015 12:51 AM, Stephen Boyd wrote: On 09/07, Rajendra Nayak wrote: Yeah this might happen though because we've assigned the of_node pointer to the tsens device before we register it on the platform bus. The other way to pass that data down from gcc to tsens would be to not have an of_node assigned to the tsens device, and check for that case in the tsens driver. If there isn't an of_node, then we look at the parent device's of_node to figure out which gcc it is (if this even matters) and parse DT properties. Parsing DT properties from parent (in the tsens driver) is fine, but the nvmem apis still expect an of_node for the tsens device and hence fail. So pass the parent device to the nvmem APIs? Or adjust the nvmem APIs to look for a parent of_node if there isn't an of_node for the device being passed? Or make the nvmem APIs work without using DT, and copy over the nvmem information from the gcc node to the virtual tsens child device? Srini, you being the nvmem maintainer, any thoughts? -- 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-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc: qcom: smem: Move RPM message ram out of smem DT node
On 09/08/2015 04:18 PM, Bjorn Andersson wrote: > On Tue 08 Sep 15:20 PDT 2015, Stephen Boyd wrote: > >> SMEM is a software construct built on top of a DDR carveout and >> sometimes a device memory called RPM message ram. Having the RPM >> message ram in the smem DT node's reg property leads to the smem >> node being located in different places depending on if the >> message ram is being used or not. Let's add a qcom specific >> property, qcom,rpm-msg-ram, and point to the device memory from >> the SMEM node via a phandle. This allows us to always have the >> SMEM node at the root of the DT regardless of whether it's using >> the message ram or not. >> > Based on the codeaurora limit of 99 aux-mem regions I figured this had > to be more generic. But I think this makes sense and we can easily > extend it with other specific regions (if we ever find any of those > other 98 supported aux-mems). Great. > > > Can you update the dt binding document as well? > > Sure. Is there a binding document? I couldn't find one. -- Qualcomm Innovation Center, Inc. is a member of 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
Re: [PATCH] soc: qcom: smem: Move RPM message ram out of smem DT node
On Tue 08 Sep 15:20 PDT 2015, Stephen Boyd wrote: > SMEM is a software construct built on top of a DDR carveout and > sometimes a device memory called RPM message ram. Having the RPM > message ram in the smem DT node's reg property leads to the smem > node being located in different places depending on if the > message ram is being used or not. Let's add a qcom specific > property, qcom,rpm-msg-ram, and point to the device memory from > the SMEM node via a phandle. This allows us to always have the > SMEM node at the root of the DT regardless of whether it's using > the message ram or not. > Based on the codeaurora limit of 99 aux-mem regions I figured this had to be more generic. But I think this makes sense and we can easily extend it with other specific regions (if we ever find any of those other 98 supported aux-mems). Can you update the dt binding document as well? Regards, Bjorn -- 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
Re: [PATCH 10/11] regulator: qcom-smd: Add support for PMA8084
On Tue 08 Sep 14:35 PDT 2015, Andy Gross wrote: > This patch adds support and documentation for the PMA8084 regulators > found on APQ8084 platforms. > > Signed-off-by: Andy Gross > --- > .../bindings/soc/qcom/qcom,smd-rpm-regulator.txt | 35 > drivers/regulator/qcom_smd-regulator.c | 95 > > 2 files changed, 130 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt > b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt [..] > +- vdd_s1: > +- vdd_s2: > +- vdd_s3: > +- vdd_s4: > +- vdd_s5: > +- vdd_s6: > +- vdd_s7: > +- vdd_s8: > +- vdd_s9: > +- vdd_s10: > +- vdd_s11: > +- vdd_s12: > +- vdd_l1_l11: > +- vdd_l2_l3_l4_l27: > +- vdd_l5_l7: > +- vdd_l6_l12_l14_l15_l26: > +- vdd_l8: > +- vdd_l9_l10_l13_l20_l23_l24: > +- vdd_l16_l25: > +- vdd_l17: > +- vdd_l18: > +- vdd_l19: > +- vdd_l21: > +- vdd_l22: -supply > + Usage: optional (pma8084 only) > + Value type: > + Definition: reference to regulator supplying the input pin, as > + described in the data sheet > + Otherwise it looks good. Regards, Bjorn -- 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
Re: [PATCH 06/11] regulator: qcom-smd: Add PM8916 support
On Tue 08 Sep 14:35 PDT 2015, Andy Gross wrote:
> This patch adds support and documentation for the PM8916 regulators
> found on MSM8916 platforms.
>
> Signed-off-by: Andy Gross
> ---
> .../bindings/soc/qcom/qcom,smd-rpm-regulator.txt | 18 ++
> drivers/regulator/qcom_smd-regulator.c | 64
>
> 2 files changed, 82 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
> b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
> index 7084474..5c867e9 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
> @@ -18,6 +18,7 @@ Regulator nodes are identified by their compatible:
> Definition: must be one of:
> "qcom,rpm-pm8841-regulators"
> "qcom,rpm-pm8941-regulators"
> + "qcom,rpm-pm8916-regulators"
>
> - vdd_s1-supply:
> - vdd_s2-supply:
> @@ -50,6 +51,19 @@ Regulator nodes are identified by their compatible:
> Definition: reference to regulator supplying the input pin, as
> described in the data sheet
>
> +- vdd_s1:
> +- vdd_s2:
> +- vdd_s3:
> +- vdd_s4:
These should end with "-supply"
> +- vdd_l1_l2_l3-supply
> +- vdd_l4_l5_l6-supply
> +- vdd_l7-supply
> +- vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18:
Same here
> + Usage: optional (pm8916 only)
> + Value type:
> + Definition: reference to regulator supplying the input pin, as
> + described in the data sheet
> +
> The regulator node houses sub-nodes for each regulator within the device.
> Each
> sub-node is identified using the node's name, with valid values listed for
> each
> of the pmics below.
> @@ -62,6 +76,10 @@ pm8941:
> l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
> lvs3, 5vs1, 5vs2
>
> +pm8916:
> + s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
> + l14, l15, l16, l17, l18
> +
> The content of each sub-node is defined by the standard binding for
> regulators -
> see regulator.txt.
>
> diff --git a/drivers/regulator/qcom_smd-regulator.c
> b/drivers/regulator/qcom_smd-regulator.c
[..]
> struct rpm_regulator_data {
> const char *name;
> u32 type;
> @@ -272,9 +309,36 @@ static const struct rpm_regulator_data
> rpm_pm8941_regulators[] = {
> {}
> };
>
> +static const struct rpm_regulator_data rpm_pm8916_regulators[] = {
As I hope we can re-use this driver for a bunch of different platforms I
think we should keep these arrays in alphabetical order - i.e. above
8941 even if there's a logical connection between the two 8x41.
> + { "s1", QCOM_SMD_RPM_SMPA, 1, &pm8916_buck_lvo_smps, "vdd_s1" },
> + { "s2", QCOM_SMD_RPM_SMPA, 2, &pm8916_buck_lvo_smps, "vdd_s2" },
> + { "s3", QCOM_SMD_RPM_SMPA, 3, &pm8916_buck_lvo_smps, "vdd_s3" },
> + { "s4", QCOM_SMD_RPM_SMPA, 4, &pm8916_buck_hvo_smps, "vdd_s4" },
> + { "l1", QCOM_SMD_RPM_LDOA, 1, &pm8916_nldo, "vdd_l1_l2_l3" },
> + { "l2", QCOM_SMD_RPM_LDOA, 2, &pm8916_nldo, "vdd_l1_l2_l3" },
> + { "l3", QCOM_SMD_RPM_LDOA, 3, &pm8916_nldo, "vdd_l1_l2_l3" },
> + { "l4", QCOM_SMD_RPM_LDOA, 4, &pm8916_pldo, "vdd_l4_l5_l6" },
> + { "l5", QCOM_SMD_RPM_LDOA, 5, &pm8916_pldo, "vdd_l4_l5_l6" },
> + { "l6", QCOM_SMD_RPM_LDOA, 6, &pm8916_pldo, "vdd_l4_l5_l6" },
> + { "l7", QCOM_SMD_RPM_LDOA, 7, &pm8916_pldo, "vdd_l7" },
> + { "l8", QCOM_SMD_RPM_LDOA, 8, &pm8916_pldo,
> "vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18" },
> + { "l9", QCOM_SMD_RPM_LDOA, 9, &pm8916_pldo,
> "vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18" },
> + { "l10", QCOM_SMD_RPM_LDOA, 10, &pm8916_pldo,
> "vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
> + { "l11", QCOM_SMD_RPM_LDOA, 11, &pm8916_pldo,
> "vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
> + { "l12", QCOM_SMD_RPM_LDOA, 12, &pm8916_pldo,
> "vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
> + { "l13", QCOM_SMD_RPM_LDOA, 13, &pm8916_pldo,
> "vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
> + { "l14", QCOM_SMD_RPM_LDOA, 14, &pm8916_pldo,
> "vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
> + { "l15", QCOM_SMD_RPM_LDOA, 15, &pm8916_pldo,
> "vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
> + { "l16", QCOM_SMD_RPM_LDOA, 16, &pm8916_pldo,
> "vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
> + { "l17", QCOM_SMD_RPM_LDOA, 17, &pm8916_pldo,
> "vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
> + { "l18", QCOM_SMD_RPM_LDOA, 18, &pm8916_pldo,
> "vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
> + {}
> +};
> +
> static const struct of_device_id rpm_of_match[] = {
> { .compatible = "qcom,rpm-pm8841-regulators", .data =
> &rpm_pm8841_regulators },
> { .compatible = "qcom,rpm-pm8941-regulators", .data =
> &rpm_pm8941_regulators },
> + { .compatible = "q
Re: [PATCH 0/4] Qualcomm Shared Memory State Machines
On Tue 08 Sep 05:20 PDT 2015, Linus Walleij wrote: > On Thu, Aug 27, 2015 at 7:37 PM, Bjorn Andersson > wrote: > > Let's discuss this a bit, looping in Mark Brown. > > > As some of these states on some platforms are passed as physical signals > > instead, the two drivers are modelled as gpio- and interrupt-controllers - > > providing a nice abstraction both in device tree sense and Linux > > implementation > > sense. > > I have unfortunately repeatedly encountered an argument of the type > "GPIO has nice infrastructure so let's call X 'a kind of GPIO' so > we can use that nice infrastructure". > I guess that's what you get for maintaining a subsystem with "general purpose" in the name ;) Sorry for adding one more item to your list. > I'm not pleased with something that is not really general purpose > input/output being called GPIO. It fits badly with the GPIO subsystem > when we support things like open drain and cross-mappings to > the pin control subsystem that will never be applicable to these > new users. It's more like "special purpose input/output" or > something. > Right, this doesn't match at all with the electrical properties. What it does give is the nice symmetry with the irq bits and existing apis for poking and peeking. > This happened with syscon LEDs for example, and was the reason > I implemented syscon-leds. The original proposal was to say the LEDs > register was "a kind of GPIO" on top of regmap and then use gpio-leds > on top of that. Instead I insisted it was a syscon/regmap and the > LEDs go directly to that, bypassing one layer of abstraction. > > I also imagine creating syscon-keys.c for input from arbitrary keys > in a syscon register actually. Just didn't get around to that yet. > The difference with those two cases is that the pieces didn't fit together, so we tried to use the gpio framework as an adaptor to make it work. I picked the gpio framework because: * the DT nicely represent the structure of the memory and relationship between the individual components. * the implementation needs to be able to set and clear individual bits, as well as register handlers for state changes. * I'm told the SMP2P entries are on some platform (I've never seen) actual gpio lines. > I also see some of the stuff GPIO does out-of-the-box being useful, > for example in MFD: some of these are interrupt controllers and > basically duplicate the kind of code I have in gpiolib for > GPIOLIB_IRQCHIP. > I do learn about new helper functions every time I touch these things. > So we need to figure out what is really needed. > > While sparsely documented: what about regmap (maybe in the > form of syscon) and drivers/base/regmap/regmap-irq.c for the > interrupt handling? > regmap-irq looks good and reasonable. The problem is that for SMSM I need custom masking operations and on SMP2P I have multiple regmaps sharing one incoming IRQ. So it doesn't look applicable for my use cases. > I cannot claim to understand regmap-irq.c, but I just intuitively > think it deserves consideration, such that drivers who need one > of these misc registers can read/write their bits with regmap > accessors and also get IRQs by way of regmap-irq. > I was expecting some push back from you, but as it was the cleanest abstraction I would come up with I gave it a shot :) I'll rewrite the outgoing part based on regmaps instead. Thanks for reviewing. Regards, Bjorn -- 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
[PATCH] soc: qcom: smem: Move RPM message ram out of smem DT node
SMEM is a software construct built on top of a DDR carveout and
sometimes a device memory called RPM message ram. Having the RPM
message ram in the smem DT node's reg property leads to the smem
node being located in different places depending on if the
message ram is being used or not. Let's add a qcom specific
property, qcom,rpm-msg-ram, and point to the device memory from
the SMEM node via a phandle. This allows us to always have the
SMEM node at the root of the DT regardless of whether it's using
the message ram or not.
Cc: Bjorn Andersson
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 17 ++---
drivers/soc/qcom/smem.c | 73 +++--
2 files changed, 41 insertions(+), 49 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 71e146de4fe4..16dfae8feece 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -20,6 +20,15 @@
};
};
+ smem {
+ compatible = "qcom,smem";
+
+ memory-region = <&smem_region>;
+ qcom,rpm-msg-ram = <&rpm_msg_ram>;
+
+ hwlocks = <&tcsr_mutex 3>;
+ };
+
smd {
compatible = "qcom,smd";
@@ -300,13 +309,9 @@
#hwlock-cells = <1>;
};
- smem@fa0 {
- compatible = "qcom,smem";
-
- memory-region = <&smem_region>;
+ rpm_msg_ram: memory@fc428000 {
+ compatible = "qcom,rpm-msg-ram";
reg = <0xfc428000 0x4000>;
-
- hwlocks = <&tcsr_mutex 3>;
};
blsp1_uart2: serial@f991e000 {
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 74017114ce6e..19019aa092e8 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -664,37 +664,47 @@ static int qcom_smem_enumerate_partitions(struct
qcom_smem *smem,
return 0;
}
-static int qcom_smem_count_mem_regions(struct platform_device *pdev)
+static int qcom_smem_map_memory(struct qcom_smem *smem, struct device *dev,
+ const char *name, int i)
{
- struct resource *res;
- int num_regions = 0;
- int i;
-
- for (i = 0; i < pdev->num_resources; i++) {
- res = &pdev->resource[i];
+ struct device_node *np;
+ struct resource r;
+ int ret;
- if (resource_type(res) == IORESOURCE_MEM)
- num_regions++;
+ np = of_parse_phandle(dev->of_node, name, 0);
+ if (!np) {
+ dev_err(dev, "No %s specified\n", name);
+ return -EINVAL;
}
- return num_regions;
+ ret = of_address_to_resource(np, 0, &r);
+ of_node_put(np);
+ if (ret)
+ return ret;
+
+ smem->regions[i].aux_base = (u32)r.start;
+ smem->regions[i].size = resource_size(&r);
+ smem->regions[i].virt_base = devm_ioremap_nocache(dev, r.start,
+ resource_size(&r));
+ if (!smem->regions[i].virt_base)
+ return -ENOMEM;
+
+ return 0;
}
static int qcom_smem_probe(struct platform_device *pdev)
{
struct smem_header *header;
- struct device_node *np;
struct qcom_smem *smem;
- struct resource *res;
- struct resource r;
size_t array_size;
- int num_regions = 0;
+ int num_regions;
int hwlock_id;
u32 version;
int ret;
- int i;
- num_regions = qcom_smem_count_mem_regions(pdev) + 1;
+ num_regions = 1;
+ if (of_find_property(pdev->dev.of_node, "qcom,rpm-msg-ram", NULL))
+ num_regions++;
array_size = num_regions * sizeof(struct smem_region);
smem = devm_kzalloc(&pdev->dev, sizeof(*smem) + array_size, GFP_KERNEL);
@@ -704,36 +714,13 @@ static int qcom_smem_probe(struct platform_device *pdev)
smem->dev = &pdev->dev;
smem->num_regions = num_regions;
- np = of_parse_phandle(pdev->dev.of_node, "memory-region", 0);
- if (!np) {
- dev_err(&pdev->dev, "No memory-region specified\n");
- return -EINVAL;
- }
-
- ret = of_address_to_resource(np, 0, &r);
- of_node_put(np);
+ ret = qcom_smem_map_memory(smem, &pdev->dev, "memory-region", 0);
if (ret)
return ret;
- smem->regions[0].aux_base = (u32)r.start;
- smem->regions[0].size = resource_size(&r);
- smem->regions[0].virt_base = devm_ioremap_nocache(&pdev->dev,
- r.start,
- resource_size(&r));
- if (!smem->regions[0].virt_base)
- return -ENOMEM;
-
- for (i = 1; i < num_regions;
[PATCH] ARM: multi_v7_defconfig: Enable QCOM SMD/RPM
This patch enables all of the options necessary to support the Qualcomm SMD RPM regulator driver. Signed-off-by: Andy Gross --- arch/arm/configs/multi_v7_defconfig |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 824a0cf..0a21629 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -412,6 +412,7 @@ CONFIG_REGULATOR_MAX77686=y CONFIG_REGULATOR_MAX77693=m CONFIG_REGULATOR_PALMAS=y CONFIG_REGULATOR_PWM=m +CONFIG_REGULATOR_QCOM_SMD_RPM=y CONFIG_REGULATOR_S2MPS11=y CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS51632=y @@ -616,6 +617,9 @@ CONFIG_NVEC_POWER=y CONFIG_NVEC_PAZ00=y CONFIG_QCOM_GSBI=y CONFIG_QCOM_PM=y +CONFIG_QCOM_SMD=y +CONFIG_QCOM_SMD_RPM=y +CONFIG_QCOM_SMEM=y CONFIG_COMMON_CLK_QCOM=y CONFIG_CHROME_PLATFORMS=y CONFIG_CROS_EC_CHARDEV=m @@ -626,6 +630,7 @@ CONFIG_APQ_MMCC_8084=y CONFIG_MSM_GCC_8660=y CONFIG_MSM_MMCC_8960=y CONFIG_MSM_MMCC_8974=y +CONFIG_HWSPINLOCK_QCOM=y CONFIG_TEGRA_IOMMU_GART=y CONFIG_TEGRA_IOMMU_SMMU=y CONFIG_PM_DEVFREQ=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-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: qcom_defconfig: Enable SMD-RPM regulators
This patch enables all of the options required to support SMD RPM based regulators. Signed-off-by: Andy Gross --- arch/arm/configs/qcom_defconfig |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig index ff7985b..ee54a70 100644 --- a/arch/arm/configs/qcom_defconfig +++ b/arch/arm/configs/qcom_defconfig @@ -109,6 +109,7 @@ CONFIG_MFD_QCOM_RPM=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_QCOM_RPM=y +CONFIG_REGULATOR_QCOM_SMD_RPM=y CONFIG_MEDIA_SUPPORT=y CONFIG_FB=y CONFIG_SOUND=y @@ -145,16 +146,17 @@ CONFIG_MSM_GCC_8660=y CONFIG_MSM_LCC_8960=y CONFIG_MSM_MMCC_8960=y CONFIG_MSM_MMCC_8974=y -CONFIG_MSM_IOMMU=y +CONFIG_HWSPINLOCK_QCOM=y CONFIG_QCOM_GSBI=y CONFIG_QCOM_PM=y +CONFIG_QCOM_SMD=y +CONFIG_QCOM_SMD_RPM=y +CONFIG_QCOM_SMEM=y CONFIG_PHY_QCOM_APQ8064_SATA=y CONFIG_PHY_QCOM_IPQ806X_SATA=y CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT3_FS=y -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set -CONFIG_EXT4_FS=y CONFIG_FUSE_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=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-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] soc: qcom: smd-rpm: Add existing platform support
This patch adds support for all current Qualcomm platforms which utilize
RPM over SMD. This includes both MSM8916 and APQ8084.
Signed-off-by: Andy Gross
---
.../devicetree/bindings/soc/qcom/qcom,smd-rpm.txt |2 ++
drivers/soc/qcom/smd-rpm.c |2 ++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
index 3710dd5..7d05246 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
@@ -20,6 +20,8 @@ resources.
Value type:
Definition: must be one of:
"qcom,rpm-msm8974"
+ "qcom,rpm-msm8916"
+ "qcom,rpm-apq8084"
- qcom,smd-channels:
Usage: required
diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
index 1392ccf..455083c 100644
--- a/drivers/soc/qcom/smd-rpm.c
+++ b/drivers/soc/qcom/smd-rpm.c
@@ -212,6 +212,8 @@ static void qcom_smd_rpm_remove(struct qcom_smd_device
*sdev)
static const struct of_device_id qcom_smd_rpm_of_match[] = {
{ .compatible = "qcom,rpm-msm8974" },
+ { .compatible = "qcom,rpm-msm8916" },
+ { .compatible = "qcom,rpm-apq8084" },
{}
};
MODULE_DEVICE_TABLE(of, qcom_smd_rpm_of_match);
--
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
[PATCH 03/11] arm64: dts: qcom: Add MSM8916 SMEM nodes
This patch adds the nodes necessary to support the SMEM driver on MSM8916
platforms.
Signed-off-by: Andy Gross
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 36 +
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 5911de0..d321266 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -37,6 +37,22 @@
reg = <0 0 0 0>;
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ reserve_aligned@8600 {
+ reg = <0x0 0x8600 0x0 0x030>;
+ no-map;
+ };
+
+ smem_mem: smem_region@8630 {
+ reg = <0x0 0x8630 0x0 0x010>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -102,6 +118,26 @@
reg = <0x180 0x8>;
};
+ tcsr_mutex_regs: syscon@1905000 {
+ compatible = "syscon";
+ reg = <0x1905000 0x2>;
+ };
+
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <&tcsr_mutex_regs 0 0x1000>;
+ #hwlock-cells = <1>;
+ };
+
+ smem {
+ compatible = "qcom,smem";
+ reg = <0x6 0x8000>;
+ reg-names = "aux-mem1";
+
+ memory-region = <&smem_mem>;
+ hwlocks = <&tcsr_mutex 3>;
+ };
+
blsp1_uart2: serial@78b {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0x78b 0x200>;
--
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
[PATCH 01/11] soc: qcom: documentation: Update SMD/RPM Docs
This patch moves the qcom,smd-rpm.txt to the correct location and splits
out the smd and rpm documentation. In addition, a smd-rpm-regulator
document is added.
Signed-off-by: Andy Gross
---
.../devicetree/bindings/soc/qcom,smd-rpm.txt | 117
.../bindings/soc/qcom/qcom,smd-rpm-regulator.txt | 103 +
.../devicetree/bindings/soc/qcom/qcom,smd-rpm.txt | 55 +
3 files changed, 158 insertions(+), 117 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
create mode 100644
Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
b/Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
deleted file mode 100644
index e27f5c4..000
--- a/Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
+++ /dev/null
@@ -1,117 +0,0 @@
-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"
-
-- qcom,smd-channels:
- Usage: required
- Value type:
- Definition: Shared Memory channel used for communication with the RPM
-
-= SUBDEVICES
-
-The RPM exposes resources to its subnodes. The below bindings specify the set
-of valid subnodes that can operate on these resources.
-
-== Regulators
-
-Regulator nodes are identified by their compatible:
-
-- compatible:
- Usage: required
- Value type:
- Definition: must be one of:
- "qcom,rpm-pm8841-regulators"
- "qcom,rpm-pm8941-regulators"
-
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s3-supply:
-- vdd_s4-supply:
-- vdd_s5-supply:
-- vdd_s6-supply:
-- vdd_s7-supply:
-- vdd_s8-supply:
- Usage: optional (pm8841 only)
- Value type:
- Definition: reference to regulator supplying the input pin, as
- described in the data sheet
-
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s3-supply:
-- vdd_l1_l3-supply:
-- vdd_l2_lvs1_2_3-supply:
-- vdd_l4_l11-supply:
-- vdd_l5_l7-supply:
-- vdd_l6_l12_l14_l15-supply:
-- vdd_l8_l16_l18_l19-supply:
-- vdd_l9_l10_l17_l22-supply:
-- vdd_l13_l20_l23_l24-supply:
-- vdd_l21-supply:
-- vin_5vs-supply:
- Usage: optional (pm8941 only)
- Value type:
- Definition: reference to regulator supplying the input pin, as
- described in the data sheet
-
-The regulator node houses sub-nodes for each regulator within the device. Each
-sub-node is identified using the node's name, with valid values listed for each
-of the pmics below.
-
-pm8841:
- s1, s2, s3, s4, s5, s6, s7, s8
-
-pm8941:
- s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
- l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
- lvs3, 5vs1, 5vs2
-
-The content of each sub-node is defined by the standard binding for regulators
-
-see regulator.txt.
-
-= EXAMPLE
-
- smd {
- compatible = "qcom,smd";
-
- rpm {
- interrupts = <0 168 1>;
- qcom,ipc = <&apcs 8 0>;
- qcom,smd-edge = <15>;
-
- rpm_requests {
- compatible = "qcom,rpm-msm8974";
- qcom,smd-channels = "rpm_requests";
-
- pm8941-regulators {
- compatible =
"qcom,rpm-pm8941-regulators";
- vdd_l13_l20_l23_l24-supply =
<&pm8941_boost>;
-
- pm8941_s3: s3 {
- regulator-min-microvolt =
<180>;
- regulator-max-microvolt =
<180>;
- };
-
- pm8941_boost: s4 {
- regulator-min-microvolt =
<500>;
- regulator-max-microvolt =
<500>;
- };
-
- pm8941_l20: l20 {
- regulator-min-microvolt =
<295>;
- regulator-max-microvolt =
<295>;
- };
- };
- };
- };
- };
-
diff --git
a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
b/Documentation/devicetree/binding
[PATCH 06/11] regulators: qcom-smd: Add PM8916 support
This patch adds support and documentation for the PM8916 regulators
found on MSM8916 platforms.
Signed-off-by: Andy Gross
---
.../bindings/soc/qcom/qcom,smd-rpm-regulator.txt | 18 ++
drivers/regulator/qcom_smd-regulator.c | 64
2 files changed, 82 insertions(+)
diff --git
a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
index 7084474..5c867e9 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
@@ -18,6 +18,7 @@ Regulator nodes are identified by their compatible:
Definition: must be one of:
"qcom,rpm-pm8841-regulators"
"qcom,rpm-pm8941-regulators"
+ "qcom,rpm-pm8916-regulators"
- vdd_s1-supply:
- vdd_s2-supply:
@@ -50,6 +51,19 @@ Regulator nodes are identified by their compatible:
Definition: reference to regulator supplying the input pin, as
described in the data sheet
+- vdd_s1:
+- vdd_s2:
+- vdd_s3:
+- vdd_s4:
+- vdd_l1_l2_l3-supply
+- vdd_l4_l5_l6-supply
+- vdd_l7-supply
+- vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18:
+ Usage: optional (pm8916 only)
+ Value type:
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
The regulator node houses sub-nodes for each regulator within the device. Each
sub-node is identified using the node's name, with valid values listed for each
of the pmics below.
@@ -62,6 +76,10 @@ pm8941:
l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
lvs3, 5vs1, 5vs2
+pm8916:
+ s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
+ l14, l15, l16, l17, l18
+
The content of each sub-node is defined by the standard binding for regulators
-
see regulator.txt.
diff --git a/drivers/regulator/qcom_smd-regulator.c
b/drivers/regulator/qcom_smd-regulator.c
index 9c6167d..e92735f 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -211,6 +211,43 @@ static const struct regulator_desc pm8941_switch = {
.ops = &rpm_switch_ops,
};
+static const struct regulator_desc pm8916_pldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(75, 0, 208, 12500),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 209,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8916_nldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(375000, 0, 93, 12500),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 94,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8916_buck_lvo_smps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(375000, 0, 95, 12500),
+ REGULATOR_LINEAR_RANGE(75, 96, 127, 25000),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 128,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8916_buck_hvo_smps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(155, 0, 31, 25000),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 32,
+ .ops = &rpm_smps_ldo_ops,
+};
+
struct rpm_regulator_data {
const char *name;
u32 type;
@@ -272,9 +309,36 @@ static const struct rpm_regulator_data
rpm_pm8941_regulators[] = {
{}
};
+static const struct rpm_regulator_data rpm_pm8916_regulators[] = {
+ { "s1", QCOM_SMD_RPM_SMPA, 1, &pm8916_buck_lvo_smps, "vdd_s1" },
+ { "s2", QCOM_SMD_RPM_SMPA, 2, &pm8916_buck_lvo_smps, "vdd_s2" },
+ { "s3", QCOM_SMD_RPM_SMPA, 3, &pm8916_buck_lvo_smps, "vdd_s3" },
+ { "s4", QCOM_SMD_RPM_SMPA, 4, &pm8916_buck_hvo_smps, "vdd_s4" },
+ { "l1", QCOM_SMD_RPM_LDOA, 1, &pm8916_nldo, "vdd_l1_l2_l3" },
+ { "l2", QCOM_SMD_RPM_LDOA, 2, &pm8916_nldo, "vdd_l1_l2_l3" },
+ { "l3", QCOM_SMD_RPM_LDOA, 3, &pm8916_nldo, "vdd_l1_l2_l3" },
+ { "l4", QCOM_SMD_RPM_LDOA, 4, &pm8916_pldo, "vdd_l4_l5_l6" },
+ { "l5", QCOM_SMD_RPM_LDOA, 5, &pm8916_pldo, "vdd_l4_l5_l6" },
+ { "l6", QCOM_SMD_RPM_LDOA, 6, &pm8916_pldo, "vdd_l4_l5_l6" },
+ { "l7", QCOM_SMD_RPM_LDOA, 7, &pm8916_pldo, "vdd_l7" },
+ { "l8", QCOM_SMD_RPM_LDOA, 8, &pm8916_pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18" },
+ { "l9", QCOM_SMD_RPM_LDOA, 9, &pm8916_pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18" },
+ { "l10", QCOM_SMD_RPM_LDOA, 10, &pm8916_pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
+ { "l11", QCOM_SMD_RPM_LDOA, 11, &pm8916_pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
+ {
[PATCH 05/11] arm64: dts: Add PM8916 support on MSM8916
This patch adds the PM8916 regulator nodes found on MSM8916 platforms.
Signed-off-by: Andy Gross
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 27d3e90..d2b07eb 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -444,6 +444,34 @@
rpm_requests {
compatible = "qcom,rpm-msm8916";
qcom,smd-channels = "rpm_requests";
+
+ pm8916-regulators {
+ compatible =
"qcom,rpm-pm8916-regulators";
+
+ pm8916_s1: s1 {};
+ pm8916_s2: s2 {};
+ pm8916_s3: s3 {};
+ pm8916_s4: s4 {};
+
+ pm8916_l1: l1 {};
+ pm8916_l2: l2 {};
+ pm8916_l3: l3 {};
+ pm8916_l4: l4 {};
+ pm8916_l5: l5 {};
+ pm8916_l6: l6 {};
+ pm8916_l7: l7 {};
+ pm8916_l8: l8 {};
+ pm8916_l9: l9 {};
+ pm8916_l10: l10 {};
+ pm8916_l11: l11 {};
+ pm8916_l12: l12 {};
+ pm8916_l13: l13 {};
+ pm8916_l14: l14 {};
+ pm8916_l15: l15 {};
+ pm8916_l16: l16 {};
+ pm8916_l17: l17 {};
+ pm8916_l18: l18 {};
+ };
};
};
};
--
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
[PATCH 04/11] arm64: dts: qcom: Add RPM/SMD support on MSM8916
Add support for the SMD and RPM devices found on MSM8916 platforms.
Signed-off-by: Andy Gross
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index d321266..27d3e90 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -138,6 +138,11 @@
hwlocks = <&tcsr_mutex 3>;
};
+ apcs: syscon@b011000 {
+ compatible = "syscon";
+ reg = <0x0b011000 0x1000>;
+ };
+
blsp1_uart2: serial@78b {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0x78b 0x200>;
@@ -427,6 +432,21 @@
#interrupt-cells = <4>;
};
};
+
+ smd {
+ compatible = "qcom,smd";
+
+ rpm {
+ interrupts = ;
+ qcom,ipc = <&apcs 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm_requests {
+ compatible = "qcom,rpm-msm8916";
+ qcom,smd-channels = "rpm_requests";
+ };
+ };
+ };
};
#include "msm8916-pins.dtsi"
--
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
[PATCH 07/11] arm: dts: Add APQ8084 SMEM nodes
This patch adds all the required nodes to support SMEM on APQ8084
Signed-off-by: Andy Gross
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index 7084010..a7e34f9 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -10,6 +10,17 @@
compatible = "qcom,apq8084";
interrupt-parent = <&intc>;
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ smem_mem: smem_region@fa0 {
+ reg = <0xfa0 0x20>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -224,6 +235,26 @@
reg = <0xfc40 0x4000>;
};
+ tcsr_mutex_regs: syscon@fd484000 {
+ compatible = "syscon";
+ reg = <0xfd484000 0x2000>;
+ };
+
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <&tcsr_mutex_regs 0 0x80>;
+ #hwlock-cells = <1>;
+ };
+
+ smem {
+ compatible = "qcom,smem";
+ reg = <0xfc428000 0x4000>;
+ reg-names = "aux-mem1";
+
+ memory-region = <&smem_mem>;
+ hwlocks = <&tcsr_mutex 3>;
+ };
+
tlmm: pinctrl@fd51 {
compatible = "qcom,apq8084-pinctrl";
reg = <0xfd51 0x4000>;
--
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
[PATCH 09/11] arm: dts: Add support for PMA8084 on APQ8084
This patch adds support for the PMA8084 regulators found on APQ8084
platforms.
Signed-off-by: Andy Gross
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 52 +++
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index c4303b9..1239202 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -329,6 +329,58 @@
rpm_requests {
compatible = "qcom,rpm-apq8084";
qcom,smd-channels = "rpm_requests";
+
+ pma8084-regulators {
+ compatible =
"qcom,rpm-pma8084-regulators";
+
+ pma8084_s1: s1 {};
+ pma8084_s2: s2 {};
+ pma8084_s3: s3 {};
+ pma8084_s4: s4 {};
+ pma8084_s5: s5 {};
+ pma8084_s6: s6 {};
+ pma8084_s7: s7 {};
+ pma8084_s8: s8 {};
+ pma8084_s9: s9 {};
+ pma8084_s10: s10 {};
+ pma8084_s11: s11 {};
+ pma8084_s12: s12 {};
+
+ pma8084_l1: l1 {};
+ pma8084_l2: l2 {};
+ pma8084_l3: l3 {};
+ pma8084_l4: l4 {};
+ pma8084_l5: l5 {};
+ pma8084_l6: l6 {};
+ pma8084_l7: l7 {};
+ pma8084_l8: l8 {};
+ pma8084_l9: l9 {};
+ pma8084_l10: l10 {};
+ pma8084_l11: l11 {};
+ pma8084_l12: l12 {};
+ pma8084_l13: l13 {};
+ pma8084_l14: l14 {};
+ pma8084_l15: l15 {};
+ pma8084_l16: l16 {};
+ pma8084_l17: l17 {};
+ pma8084_l18: l18 {};
+ pma8084_l19: l19 {};
+ pma8084_l20: l20 {};
+ pma8084_l21: l21 {};
+ pma8084_l22: l22 {};
+ pma8084_l23: l23 {};
+ pma8084_l24: l24 {};
+ pma8084_l25: l25 {};
+ pma8084_l26: l26 {};
+ pma8084_l27: l27 {};
+
+ pma8084_lvs1: lvs1 {};
+ pma8084_lvs2: lvs2 {};
+ pma8084_lvs3: lvs3 {};
+ pma8084_lvs4: lvs4 {};
+
+ pma8084_5vs1: 5vs1 {};
+ };
};
};
};
--
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
[PATCH 08/11] arm: dts: Add RPM/SMD support on APQ8084
This patch adds support for RPM and SMD nodes that are present on APQ8084
platforms.
Signed-off-by: Andy Gross
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index a7e34f9..c4303b9 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -114,6 +114,11 @@
<0xf9002000 0x1000>;
};
+ apcs: syscon@f9011000 {
+ compatible = "syscon";
+ reg = <0xf9011000 0x1000>;
+ };
+
timer@f902 {
#address-cells = <1>;
#size-cells = <1>;
@@ -312,4 +317,19 @@
#interrupt-cells = <4>;
};
};
+
+ smd {
+ compatible = "qcom,smd";
+
+ rpm {
+ interrupts = <0 168 1>;
+ qcom,ipc = <&apcs 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm_requests {
+ compatible = "qcom,rpm-apq8084";
+ qcom,smd-channels = "rpm_requests";
+ };
+ };
+ };
};
--
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
[PATCH 10/11] regulator: qcom-smd: Add support for PMA8084
This patch adds support and documentation for the PMA8084 regulators
found on APQ8084 platforms.
Signed-off-by: Andy Gross
---
.../bindings/soc/qcom/qcom,smd-rpm-regulator.txt | 35
drivers/regulator/qcom_smd-regulator.c | 95
2 files changed, 130 insertions(+)
diff --git
a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
index 5c867e9..a5f650f 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
@@ -19,6 +19,7 @@ Regulator nodes are identified by their compatible:
"qcom,rpm-pm8841-regulators"
"qcom,rpm-pm8941-regulators"
"qcom,rpm-pm8916-regulators"
+ "qcom,rpm-pma8084-regulators"
- vdd_s1-supply:
- vdd_s2-supply:
@@ -64,6 +65,35 @@ Regulator nodes are identified by their compatible:
Definition: reference to regulator supplying the input pin, as
described in the data sheet
+- vdd_s1:
+- vdd_s2:
+- vdd_s3:
+- vdd_s4:
+- vdd_s5:
+- vdd_s6:
+- vdd_s7:
+- vdd_s8:
+- vdd_s9:
+- vdd_s10:
+- vdd_s11:
+- vdd_s12:
+- vdd_l1_l11:
+- vdd_l2_l3_l4_l27:
+- vdd_l5_l7:
+- vdd_l6_l12_l14_l15_l26:
+- vdd_l8:
+- vdd_l9_l10_l13_l20_l23_l24:
+- vdd_l16_l25:
+- vdd_l17:
+- vdd_l18:
+- vdd_l19:
+- vdd_l21:
+- vdd_l22:
+ Usage: optional (pma8084 only)
+ Value type:
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
The regulator node houses sub-nodes for each regulator within the device. Each
sub-node is identified using the node's name, with valid values listed for each
of the pmics below.
@@ -80,6 +110,11 @@ pm8916:
s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
l14, l15, l16, l17, l18
+pma8084:
+ s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, l4, l5,
+ l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20,
+ l21, l22, l23, l24, l25, l26, l27, lvs1, lvs2, lvs3, lvs4, 5vs1
+
The content of each sub-node is defined by the standard binding for regulators
-
see regulator.txt.
diff --git a/drivers/regulator/qcom_smd-regulator.c
b/drivers/regulator/qcom_smd-regulator.c
index e92735f..f09d5b8 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -153,6 +153,49 @@ static const struct regulator_ops rpm_switch_ops = {
.is_enabled = rpm_reg_is_enabled,
};
+static const struct regulator_desc pma8084_hfsmps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(375000, 0, 95, 12500),
+ REGULATOR_LINEAR_RANGE(155, 96, 158, 25000),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 159,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pma8084_ftsmps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(35, 0, 184, 5000),
+ REGULATOR_LINEAR_RANGE(70, 185, 339, 1),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 340,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pma8084_pldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(75, 0, 30, 25000),
+ REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 100,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pma8084_nldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(75, 0, 63, 12500),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 64,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pma8084_switch = {
+ .ops = &rpm_switch_ops,
+};
+
static const struct regulator_desc pm8x41_hfsmps = {
.linear_ranges = (struct regulator_linear_range[]) {
REGULATOR_LINEAR_RANGE( 375000, 0, 95, 12500),
@@ -309,6 +352,57 @@ static const struct rpm_regulator_data
rpm_pm8941_regulators[] = {
{}
};
+static const struct rpm_regulator_data rpm_pma8084_regulators[] = {
+ { "s1", QCOM_SMD_RPM_SMPA, 1, &pma8084_ftsmps, "vdd_s1" },
+ { "s2", QCOM_SMD_RPM_SMPA, 2, &pma8084_ftsmps, "vdd_s2" },
+ { "s3", QCOM_SMD_RPM_SMPA, 3, &pma8084_hfsmps, "vdd_s3" },
+ { "s4", QCOM_SMD_RPM_SMPA, 4, &pma8084_hfsmps, "vdd_s4" },
+ { "s5", QCOM_SMD_RPM_SMPA, 5, &pma8084_hfsmps, "vdd_s5" },
+ { "s6", QCOM_SMD_RPM_SMPA, 6, &pma8084_ftsmps, "vdd_s6" },
+ { "s7", QCOM_SMD_RPM_SMPA, 7, &pma8084_ftsmps, "vdd_s7" },
+ { "s8", QCOM_SMD_RPM_SMPA, 8, &pma8084_ftsmps, "vdd_s8" },
+ {
[PATCH 11/11] arm: dts: Add RPM SMD regulator support on MSM8974
This patch adds all the nodes required to support the PM8841 and PM8941
PMIC regulators present on MSM8974 platforms.
Signed-off-by: Andy Gross
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 75 +++
1 file changed, 75 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index d7c99b8..f0a41b5 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -114,6 +114,11 @@
<0xf9002000 0x1000>;
};
+ apcs: syscon@f9011000 {
+ compatible = "syscon";
+ reg = <0xf9011000 0x1000>;
+ };
+
timer@f902 {
#address-cells = <1>;
#size-cells = <1>;
@@ -334,4 +339,74 @@
#interrupt-cells = <4>;
};
};
+
+ smd {
+ compatible = "qcom,smd";
+
+ rpm {
+ interrupts = <0 168 1>;
+ qcom,ipc = <&apcs 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm_requests {
+ compatible = "qcom,rpm-msm8974";
+ qcom,smd-channels = "rpm_requests";
+
+ pm8841-regulators {
+ compatible =
"qcom,rpm-pm8841-regulators";
+
+ pm8841_s1: s1 {};
+ pm8841_s2: s2 {};
+ pm8841_s3: s3 {};
+ pm8841_s4: s4 {};
+ pm8841_s5: s5 {};
+ pm8841_s6: s6 {};
+ pm8841_s7: s7 {};
+ pm8841_s8: s8 {};
+ };
+
+ pm8941-regulators {
+ compatible =
"qcom,rpm-pm8941-regulators";
+
+ pm8941_s1: s1 {};
+ pm8941_s2: s2 {};
+ pm8941_s3: s3 {};
+ pm8941_5v: s4 {};
+
+ pm8941_l1: l1 {};
+ pm8941_l2: l2 {};
+ pm8941_l3: l3 {};
+ pm8941_l4: l4 {};
+ pm8941_l5: l5 {};
+ pm8941_l6: l6 {};
+ pm8941_l7: l7 {};
+ pm8941_l8: l8 {};
+ pm8941_l9: l9 {};
+ pm8941_l10: l10 {};
+ pm8941_l11: l11 {};
+ pm8941_l12: l12 {};
+ pm8941_l13: l13 {};
+ pm8941_l14: l14 {};
+ pm8941_l15: l15 {};
+ pm8941_l16: l16 {};
+ pm8941_l17: l17 {};
+ pm8941_l18: l18 {};
+ pm8941_l19: l19 {};
+ pm8941_l20: l20 {};
+ pm8941_l21: l21 {};
+ pm8941_l22: l22 {};
+ pm8941_l23: l23 {};
+ pm8941_l24: l24 {};
+
+ pm8941_lvs1: lvs1 {};
+ pm8941_lvs2: lvs2 {};
+ pm8941_lvs3: lvs3 {};
+ pm8941_lvs4: lvs4 {};
+
+ pm8941_5vs1: 5vs1 {};
+ pm8941_5vs2: 5vs2 {};
+ };
+ };
+ };
+ };
};
--
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
[PATCH 06/11] regulator: qcom-smd: Add PM8916 support
This patch adds support and documentation for the PM8916 regulators
found on MSM8916 platforms.
Signed-off-by: Andy Gross
---
.../bindings/soc/qcom/qcom,smd-rpm-regulator.txt | 18 ++
drivers/regulator/qcom_smd-regulator.c | 64
2 files changed, 82 insertions(+)
diff --git
a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
index 7084474..5c867e9 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
@@ -18,6 +18,7 @@ Regulator nodes are identified by their compatible:
Definition: must be one of:
"qcom,rpm-pm8841-regulators"
"qcom,rpm-pm8941-regulators"
+ "qcom,rpm-pm8916-regulators"
- vdd_s1-supply:
- vdd_s2-supply:
@@ -50,6 +51,19 @@ Regulator nodes are identified by their compatible:
Definition: reference to regulator supplying the input pin, as
described in the data sheet
+- vdd_s1:
+- vdd_s2:
+- vdd_s3:
+- vdd_s4:
+- vdd_l1_l2_l3-supply
+- vdd_l4_l5_l6-supply
+- vdd_l7-supply
+- vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18:
+ Usage: optional (pm8916 only)
+ Value type:
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
The regulator node houses sub-nodes for each regulator within the device. Each
sub-node is identified using the node's name, with valid values listed for each
of the pmics below.
@@ -62,6 +76,10 @@ pm8941:
l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
lvs3, 5vs1, 5vs2
+pm8916:
+ s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
+ l14, l15, l16, l17, l18
+
The content of each sub-node is defined by the standard binding for regulators
-
see regulator.txt.
diff --git a/drivers/regulator/qcom_smd-regulator.c
b/drivers/regulator/qcom_smd-regulator.c
index 9c6167d..e92735f 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -211,6 +211,43 @@ static const struct regulator_desc pm8941_switch = {
.ops = &rpm_switch_ops,
};
+static const struct regulator_desc pm8916_pldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(75, 0, 208, 12500),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 209,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8916_nldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(375000, 0, 93, 12500),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 94,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8916_buck_lvo_smps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(375000, 0, 95, 12500),
+ REGULATOR_LINEAR_RANGE(75, 96, 127, 25000),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 128,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8916_buck_hvo_smps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(155, 0, 31, 25000),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 32,
+ .ops = &rpm_smps_ldo_ops,
+};
+
struct rpm_regulator_data {
const char *name;
u32 type;
@@ -272,9 +309,36 @@ static const struct rpm_regulator_data
rpm_pm8941_regulators[] = {
{}
};
+static const struct rpm_regulator_data rpm_pm8916_regulators[] = {
+ { "s1", QCOM_SMD_RPM_SMPA, 1, &pm8916_buck_lvo_smps, "vdd_s1" },
+ { "s2", QCOM_SMD_RPM_SMPA, 2, &pm8916_buck_lvo_smps, "vdd_s2" },
+ { "s3", QCOM_SMD_RPM_SMPA, 3, &pm8916_buck_lvo_smps, "vdd_s3" },
+ { "s4", QCOM_SMD_RPM_SMPA, 4, &pm8916_buck_hvo_smps, "vdd_s4" },
+ { "l1", QCOM_SMD_RPM_LDOA, 1, &pm8916_nldo, "vdd_l1_l2_l3" },
+ { "l2", QCOM_SMD_RPM_LDOA, 2, &pm8916_nldo, "vdd_l1_l2_l3" },
+ { "l3", QCOM_SMD_RPM_LDOA, 3, &pm8916_nldo, "vdd_l1_l2_l3" },
+ { "l4", QCOM_SMD_RPM_LDOA, 4, &pm8916_pldo, "vdd_l4_l5_l6" },
+ { "l5", QCOM_SMD_RPM_LDOA, 5, &pm8916_pldo, "vdd_l4_l5_l6" },
+ { "l6", QCOM_SMD_RPM_LDOA, 6, &pm8916_pldo, "vdd_l4_l5_l6" },
+ { "l7", QCOM_SMD_RPM_LDOA, 7, &pm8916_pldo, "vdd_l7" },
+ { "l8", QCOM_SMD_RPM_LDOA, 8, &pm8916_pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18" },
+ { "l9", QCOM_SMD_RPM_LDOA, 9, &pm8916_pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18" },
+ { "l10", QCOM_SMD_RPM_LDOA, 10, &pm8916_pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
+ { "l11", QCOM_SMD_RPM_LDOA, 11, &pm8916_pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
+ {
[PATCH 00/11] Add RPM/SMD Support for QCOM platforms
This patch set cleans up the documentation that is currently in place for the SMD, SMD-RPM, and SMD-RPM regulators. In addition, this patch set adds support for the PM8916 found on MSM8916 platforms and the PMA8084 found on APQ8084 platforms. All of the relevant DTS information is fleshed out for the regulators and their dependencies for all of the platforms which support SMD-RPM regulators. Andy Gross (11): soc: qcom: documentation: Update SMD/RPM Docs soc: qcom: smd-rpm: Add existing platform support arm64: dts: qcom: Add MSM8916 SMEM nodes arm64: dts: qcom: Add RPM/SMD support on MSM8916 arm64: dts: Add PM8916 support on MSM8916 regulator: qcom-smd: Add PM8916 support arm: dts: Add APQ8084 SMEM nodes arm: dts: Add RPM/SMD support on APQ8084 arm: dts: Add support for PMA8084 on APQ8084 regulator: qcom-smd: Add support for PMA8084 arm: dts: Add RPM SMD regulator support on MSM8974 .../devicetree/bindings/soc/qcom,smd-rpm.txt | 117 -- .../bindings/soc/qcom/qcom,smd-rpm-regulator.txt | 156 +++ .../devicetree/bindings/soc/qcom/qcom,smd-rpm.txt | 57 +++ arch/arm/boot/dts/qcom-apq8084.dtsi| 103 + arch/arm/boot/dts/qcom-msm8974.dtsi| 75 + arch/arm64/boot/dts/qcom/msm8916.dtsi | 84 +++ drivers/regulator/qcom_smd-regulator.c | 159 drivers/soc/qcom/smd-rpm.c |2 + 8 files changed, 636 insertions(+), 117 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt -- 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
Re: [PATCH 5/9] clk: qcom: gcc-msm8960: add child devices support.
On 09/07, Rajendra Nayak wrote: > > > >Yeah this might happen though because we've assigned the of_node > >pointer to the tsens device before we register it on the platform > >bus. The other way to pass that data down from gcc to tsens would > >be to not have an of_node assigned to the tsens device, and check > >for that case in the tsens driver. If there isn't an of_node, > >then we look at the parent device's of_node to figure out which > >gcc it is (if this even matters) and parse DT properties. > > Parsing DT properties from parent (in the tsens driver) is fine, but > the nvmem apis still expect an of_node for the tsens device and hence > fail. So pass the parent device to the nvmem APIs? Or adjust the nvmem APIs to look for a parent of_node if there isn't an of_node for the device being passed? Or make the nvmem APIs work without using DT, and copy over the nvmem information from the gcc node to the virtual tsens child device? > > Associating the of_node of the parent to the tsens device while being > probed ends up with the same issues of gcc ending up probing the device > and failing because tsens defers probe a couple times before a > successful probe. Yeah sounds like we shouldn't do it that way. -- Qualcomm Innovation Center, Inc. is a member of 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
Re: [PATCH v2] usb: phy: msm: Unregister VBUS and ID events notifiers
On 09/07/2015 01:07 AM, Ivan T. Ivanov wrote:
> Right now even if driver failed to probe extcon framework will
> still deliver its VBUS and ID events, which will lead to random
> exception codes.
>
> Fix this by removing VBUS and ID events notifiers when probe fail.
>
> Fixes: 591fc116f330 ("usb: phy: msm: Use extcon framework for VBUS and ID
> detection")
>
> Reported-by: Tim Bird
> Signed-off-by: Ivan T. Ivanov
> ---
>
> Patch reworked to use new extcon API.
>
> drivers/usb/phy/phy-msm-usb.c | 25 -
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
> index c58c3c0dbe35..0fd21c147c7e 100644
> --- a/drivers/usb/phy/phy-msm-usb.c
> +++ b/drivers/usb/phy/phy-msm-usb.c
> @@ -1598,6 +1598,8 @@ static int msm_otg_read_dt(struct platform_device
> *pdev, struct msm_otg *motg)
> ret = extcon_register_notifier(ext_id, EXTCON_USB_HOST,
> &motg->id.nb);
> if (ret < 0) {
> + extcon_unregister_notifier(motg->vbus.extcon,
> +EXTCON_USB, &motg->vbus.nb);
> dev_err(&pdev->dev, "register ID notifier failed\n");
> return ret;
> }
> @@ -1660,15 +1662,6 @@ static int msm_otg_probe(struct platform_device *pdev)
> if (!motg)
> return -ENOMEM;
>
> - pdata = dev_get_platdata(&pdev->dev);
> - if (!pdata) {
> - if (!np)
> - return -ENXIO;
> - ret = msm_otg_read_dt(pdev, motg);
> - if (ret)
> - return ret;
> - }
> -
> motg->phy.otg = devm_kzalloc(&pdev->dev, sizeof(struct usb_otg),
>GFP_KERNEL);
> if (!motg->phy.otg)
> @@ -1731,6 +1724,15 @@ static int msm_otg_probe(struct platform_device *pdev)
> return motg->irq;
> }
>
> + pdata = dev_get_platdata(&pdev->dev);
> + if (!pdata) {
> + if (!np)
> + return -ENXIO;
> + ret = msm_otg_read_dt(pdev, motg);
> + if (ret)
> + return ret;
> + }
> +
The following code depends on msm_otg_read_dt(), but the
movement of the call puts the phy_number test before msm_otg_read_dt().
/*
* NOTE: The PHYs can be multiplexed between the chipidea controller
* and the dwc3 controller, using a single bit. It is important that
* the dwc3 driver does not set this bit in an incompatible way.
*/
if (motg->phy_number) {
phy_select = devm_ioremap_nocache(&pdev->dev, USB2_PHY_SEL, 4);
if (!phy_select)
return -ENOMEM;
/* Enable second PHY with the OTG port */
writel(0x1, phy_select);
}
Can you please move the motg->phy_number code after the msm_otg_read_dt() call?
(right here, in the patch, would be good :-)
> regs[0].supply = "vddcx";
> regs[1].supply = "v3p3";
> regs[2].supply = "v1p8";
> @@ -1834,6 +1836,11 @@ disable_clks:
> clk_disable_unprepare(motg->clk);
> if (!IS_ERR(motg->core_clk))
> clk_disable_unprepare(motg->core_clk);
> +
> + extcon_unregister_notifier(motg->id.extcon,
> +EXTCON_USB_HOST, &motg->id.nb);
> + extcon_unregister_notifier(motg->vbus.extcon,
> +EXTCON_USB, &motg->vbus.nb);
> return ret;
> }
Other than that - it looks good.
-- Tim
--
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
Re: [PATCH 0/4] Qualcomm Shared Memory State Machines
On Tue, Sep 08, 2015 at 02:20:14PM +0200, Linus Walleij wrote: > On Thu, Aug 27, 2015 at 7:37 PM, Bjorn Andersson > wrote: > Let's discuss this a bit, looping in Mark Brown. Please don't send upstream discussions ot my work address. > While sparsely documented: what about regmap (maybe in the > form of syscon) and drivers/base/regmap/regmap-irq.c for the > interrupt handling? > I cannot claim to understand regmap-irq.c, but I just intuitively > think it deserves consideration, such that drivers who need one > of these misc registers can read/write their bits with regmap > accessors and also get IRQs by way of regmap-irq. Well, all it's doing is exporting a simple register based interrupt controller based on regmap. There's not a lot to document. If you're using it with a system controller you'd probably want to implement support for handling interrupts directly in the primary handler rather than using a threaded handler. Alternatively if there's no cache or no overlap between interrupt registers and other registers then just using the genirq MMIO code should do the trick. signature.asc Description: Digital signature
Re: [PATCH 2/4] gpio: qcom-smsm: Add driver for Qualcomm SMSM
On Thu, Aug 27, 2015 at 7:37 PM, Bjorn Andersson wrote: > This driver exposed the Qualcomm Shared Memory State Machine bits as > GPIOs to the system. > > Signed-off-by: Bjorn Andersson (...) > +/* > + * This driver implements the Qualcomm Shared Memory State Machine, a > mechanism > + * for communicating single bit state information to remote processors. > + * > + * The implementation is based on two sections of shared memory; the first > + * holding the state bits and the second holding a matrix of subscription > bits. > + * > + * The state bits are structured in entries of 32 bits, each belonging to one > + * system in the SoC. The entry belonging to the local system is considered > + * read-write, while the rest should be considered read-only. > + * > + * The subscription matrix consists of N bitmaps per entry, denoting interest > + * in updates of the entry for each of the N hosts. Upon updating a state bit > + * each host's subscription bitmap should be queried and the remote system > + * should be interrupted if they request so. > + * > + * The subscription matrix is laid out in entry-major order: > + * entry0: [host0 ... hostN] > + * . > + * . > + * entryM: [host0 ... hostN] > + * > + * A third, optional, shared memory region might contain information > regarding > + * the number of entries in the state bitmap as well as number of columns in > + * the subscription matrix. > + */ This does seem like a real bad fit to GPIO for me, sorry. IMO this is drivers/soc/qcom, using regmap and possibly regmap IRQs-material. Yours, Linus Walleij -- 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
Re: [PATCH 1/4] dt-binding: gpio: Add Qualcomm SMSM device tree documentation
On Mon, Aug 31, 2015 at 5:43 PM, Rob Herring wrote: > On Thu, Aug 27, 2015 at 12:37 PM, Bjorn Andersson > wrote: >> This documents a device tree binding for exposing the Qualcomm Shared >> Memory State Machine as a set of gpio- and interrupt-controllers. >> >> Signed-off-by: Bjorn Andersson >> +This document defines the binding for a driver that implements and exposes >> this >> +a GPIO controller and a set of interrupt controllers. > > I imagine Linus will have thoughts about that. Yeah you bet :D I wrote a lengthy answer to patch 0. Point being: if we insist on this being modeled as "a kind of GPIO", then *BSD and Windows also has to think of it as "a kind of GPIO" meaning we put Linux implementation details into the DT bindings. At least the idea Rob had about register-bit-* bindings should be respected see for example: Documentation/devicetree/bindings/leds/register-bit-led.txt That naming is neutral, even if we end up solving it in Linux with a GPIO abstraction, it doesn't enforce that on $OTHER_OS. Yours, Linus Walleij -- 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
Re: [PATCH 0/4] Qualcomm Shared Memory State Machines
On Thu, Aug 27, 2015 at 7:37 PM, Bjorn Andersson wrote: Let's discuss this a bit, looping in Mark Brown. > As some of these states on some platforms are passed as physical signals > instead, the two drivers are modelled as gpio- and interrupt-controllers - > providing a nice abstraction both in device tree sense and Linux > implementation > sense. I have unfortunately repeatedly encountered an argument of the type "GPIO has nice infrastructure so let's call X 'a kind of GPIO' so we can use that nice infrastructure". I'm not pleased with something that is not really general purpose input/output being called GPIO. It fits badly with the GPIO subsystem when we support things like open drain and cross-mappings to the pin control subsystem that will never be applicable to these new users. It's more like "special purpose input/output" or something. This happened with syscon LEDs for example, and was the reason I implemented syscon-leds. The original proposal was to say the LEDs register was "a kind of GPIO" on top of regmap and then use gpio-leds on top of that. Instead I insisted it was a syscon/regmap and the LEDs go directly to that, bypassing one layer of abstraction. I also imagine creating syscon-keys.c for input from arbitrary keys in a syscon register actually. Just didn't get around to that yet. I also see some of the stuff GPIO does out-of-the-box being useful, for example in MFD: some of these are interrupt controllers and basically duplicate the kind of code I have in gpiolib for GPIOLIB_IRQCHIP. So we need to figure out what is really needed. While sparsely documented: what about regmap (maybe in the form of syscon) and drivers/base/regmap/regmap-irq.c for the interrupt handling? I cannot claim to understand regmap-irq.c, but I just intuitively think it deserves consideration, such that drivers who need one of these misc registers can read/write their bits with regmap accessors and also get IRQs by way of regmap-irq. Yours, Linus Walleij -- 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
Re: [PATCH v4] usb: chipidea: Use extcon framework for VBUS and ID detect
On Mon, Sep 07, 2015 at 02:45:25PM +0300, Ivan T. Ivanov wrote:
> On recent Qualcomm platforms VBUS and ID lines are not routed to
> USB PHY LINK controller. Use extcon framework to receive connect
> and disconnect ID and VBUS notification.
>
> Signed-off-by: Ivan T. Ivanov
I will queue it for next rc1, thanks.
Peter
> ---
>
> Changes sice v3 [1]:
>
> * Migrate to new extcon framework API
> * Address comments from Peter Chen.
>
> Tested DRD role with "qcom,ci-hdrc" and "qcom,usb-8x16-phy" on DB410c
>
> [1] https://lkml.org/lkml/2015/6/2/333
>
> .../devicetree/bindings/usb/ci-hdrc-usb2.txt | 6 +
> drivers/usb/chipidea/Kconfig | 1 +
> drivers/usb/chipidea/core.c| 125
> +
> drivers/usb/chipidea/otg.c | 39 ++-
> include/linux/usb/chipidea.h | 23
> 5 files changed, 193 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> index d71ef07bca5d..aea7d0af5fd6 100644
> --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> @@ -45,6 +45,11 @@ Optional properties:
>(4 bytes), This register represents the maximum length of a the burst
>in 32-bit words while moving data from the USB bus to system memory,
>changing this value takes effect only the SBUSCFG.AHBBRST is 0.
> +- extcon: phandles to external connector devices. First phandle should point
> to
> + external connector, which provide "USB" cable events, the second should
> point
> + to external connector device, which provide "USB-HOST" cable events. If one
> + of the external connector devices is not required, empty <0> phandle should
> + be specified.
>
> Example:
>
> @@ -61,4 +66,5 @@ Example:
> ahb-burst-config = <0x0>;
> tx-burst-size-dword = <0x10>; /* 64 bytes */
> rx-burst-size-dword = <0x10>;
> + extcon = <0>, <&usb_id>;
> };
> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> index 5ce3f1d6a6ed..5619b8ca3bf3 100644
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -1,6 +1,7 @@
> config USB_CHIPIDEA
> tristate "ChipIdea Highspeed Dual Role Controller"
> depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD &&
> !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
> + select EXTCON
> help
> Say Y here if your system has a dual role high speed USB
> controller based on ChipIdea silicon IP. Currently, only the
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 3feebf7f31f0..573c2876b263 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -47,6 +47,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -602,9 +603,45 @@ static irqreturn_t ci_irq(int irq, void *data)
> return ret;
> }
>
> +static int ci_vbus_notifier(struct notifier_block *nb, unsigned long event,
> + void *ptr)
> +{
> + struct ci_hdrc_cable *vbus = container_of(nb, struct ci_hdrc_cable, nb);
> + struct ci_hdrc *ci = vbus->ci;
> +
> + if (event)
> + vbus->state = true;
> + else
> + vbus->state = false;
> +
> + vbus->changed = true;
> +
> + ci_irq(ci->irq, ci);
> + return NOTIFY_DONE;
> +}
> +
> +static int ci_id_notifier(struct notifier_block *nb, unsigned long event,
> + void *ptr)
> +{
> + struct ci_hdrc_cable *id = container_of(nb, struct ci_hdrc_cable, nb);
> + struct ci_hdrc *ci = id->ci;
> +
> + if (event)
> + id->state = false;
> + else
> + id->state = true;
> +
> + id->changed = true;
> +
> + ci_irq(ci->irq, ci);
> + return NOTIFY_DONE;
> +}
> +
> static int ci_get_platdata(struct device *dev,
> struct ci_hdrc_platform_data *platdata)
> {
> + struct extcon_dev *ext_vbus, *ext_id;
> + struct ci_hdrc_cable *cable;
> int ret;
>
> if (!platdata->phy_mode)
> @@ -695,9 +732,91 @@ static int ci_get_platdata(struct device *dev,
> platdata->flags |= CI_HDRC_OVERRIDE_RX_BURST;
> }
>
> + ext_id = ERR_PTR(-ENODEV);
> + ext_vbus = ERR_PTR(-ENODEV);
> + if (of_property_read_bool(dev->of_node, "extcon")) {
> + /* Each one of them is not mandatory */
> + ext_vbus = extcon_get_edev_by_phandle(dev, 0);
> + if (IS_ERR(ext_vbus) && PTR_ERR(ext_vbus) != -ENODEV)
> + return PTR_ERR(ext_vbus);
> +
> + ext_id = extcon_get_edev_by_phandle(dev, 1);
> + if (IS_ERR(ext_id) && PTR_ERR(ext_id) != -ENODEV)
> + return PTR_ERR(ext_id);
> + }
> +
> + cable = &platdata->vbus_extcon;
Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus
On 09/07/2015 01:46 PM, Archit Taneja wrote:
> Thierry,
>
> On 08/21/2015 11:39 AM, Archit Taneja wrote:
>>
>>
>> On 08/20/2015 05:18 PM, Thierry Reding wrote:
>>> On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:
Hi Thierry, Lucas,
On 08/19/2015 08:32 PM, Thierry Reding wrote:
> On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:
>> Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:
>>> On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:
Hi Thierry, Archit,
>> [...]
> Perhaps a better way would be to invert this relationship.
> According to
> your proposal we'd have to have DT like this:
>
> i2c@... {
> ...
>
> dsi-device@... {
> ...
> dsi-bus = <&dsi>;
> ...
> };
>
> ...
> };
>
> dsi@... {
> ...
> };
>
> Inversing the relationship would become something like this:
>
> i2c@... {
> ...
> };
>
> dsi@... {
> ...
>
> peripheral@... {
> ...
> i2c-bus = <&i2c>;
> ...
> };
>
> ...
> };
>
> Both of those aren't fundamentally different, and they both have
> the
> disavantage of lacking ways to transport configuration data that
> the
> other bus needs to instantiate the dummy device (such as the reg
> property for example, denoting the I2C slave address or the DSI
> VC).
>
> So how about we create two devices in the device tree and fuse
> them at
> the driver level:
>
> i2c@... {
> ...
>
> i2cdsi: dsi-device@... {
> ...
> };
>
> ...
> };
>
> dsi@... {
> ...
>
> peripheral@... {
> ...
> control = <&i2cdsi>;
> ...
> };
>
> ...
> };
>
> This way we'll get both an I2C device and a DSI device that we
> can fully
> describe using the standard device tree bindings. At driver time
> we can
> get the I2C device from the phandle in the control property of
> the DSI
> device and use it to execute I2C transactions.
>
I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.
Devicetree is structured along the control buses, even if the
devices
are connected to multiple buses, in the DT they are always
children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is
clearly
a child of the i2c master controller and only of that one.
>>>
>>> I think that's a flawed interpretation of what's going on here. The
>>> device in fact has two interfaces: one is I2C, the other is DSI.
>>> In my
>>> opinion that's reason enough to represent it as two logical devices.
>>>
>> Does it really have 2 control interfaces that are used at the same
>> time?
>> Or is the DSI connection a passive data bus if the register control
>> happens through i2c?
>
> The interfaces may not be used at the same time, and the DSI interface
> may even be crippled, but the device is still addressable from the DSI
> host controller, if for nothing else than for routing the video stream.
>
If you need to model connections between devices that are not
reflected
through the control bus hierarchy you should really consider
using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)
>>>
>>> The problem is that the original proposal would instantiate a dummy
>>> device, so it wouldn't be represented in DT at all. So unless you
>>> do add
>>> two logical devices to DT (one for each bus interface), you don't
>>> have
>>> anything to glue together with an OF graph.
>>>
>> I see that the having dummy device is the least desirable solution.
>> But
>> if there is only one control bus to the device I think it should be
>> one
>> device sitting beneath the control bus.
>>
>> You can then use of-graph to model the data path between the DSI
>> encoder
>> and device.
>
> But you will be needing a device below the DSI
