Re: [PATCH v2 1/5] devicetree: bindings: Document qcom board compatible format
On 11/23/15 16:47, Stephen Boyd wrote: > On 11/22, Rob Herring wrote: >> >> Much more reasonable now. I do find the '/' in it a bit strange though. > I can remove the backslash if you like. Is a dash more preferred? > >> Acked-by: Rob Herring >> > and if so can I keep the ack? I'll resend with that change and > add the ack. > I'll take no answer as "let's not change anything", so can someone pickup this patch as is? Perhaps Andy can do that? -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] clk: arizona: Add clock driver for the Arizona devices
On 01/05, Charles Keepax wrote:
> Add an initial clock driver for the Arizona series audio CODECs.
> Currently this driver only provides support for parsing the two input
> clocks (mclk1, mclk2) and providing the internally consumed 32k clock.
>
> Signed-off-by: Charles Keepax
Can this go through clk-tree without the other three patches and
nothing breaks?
> diff --git a/drivers/clk/clk-arizona.c b/drivers/clk/clk-arizona.c
> new file mode 100644
> index 000..1ab69ee
> --- /dev/null
> +++ b/drivers/clk/clk-arizona.c
> @@ -0,0 +1,192 @@
> +
> +static int arizona_32k_enable(struct clk_hw *hw)
> +{
> + struct arizona_clk *clkdata = clk32k_to_arizona_clk(hw);
> + struct arizona *arizona = clkdata->arizona;
> + int ret;
> +
> + switch (arizona->pdata.clk32k_src) {
> + case ARIZONA_32KZ_MCLK1:
> + ret = pm_runtime_get_sync(arizona->dev);
> + if (ret != 0)
typically we write this as
if (ret)
> + goto out;
> + break;
> + }
> +
> + ret = regmap_update_bits_async(arizona->regmap, ARIZONA_CLOCK_32K_1,
> +ARIZONA_CLK_32K_ENA,
> +ARIZONA_CLK_32K_ENA);
> +
> +out:
> + return ret;
> +}
> +
> +static int arizona_clk_of_get_pdata(struct arizona *arizona)
> +{
> + const char * const pins[] = { "mclk1", "mclk2" };
> + struct clk *mclk;
> + int i;
> +
> + if (!of_property_read_bool(arizona->dev->of_node, "clocks"))
> + return 0;
> +
> + for (i = 0; i < ARRAY_SIZE(pins); ++i) {
> + mclk = of_clk_get_by_name(arizona->dev->of_node, pins[i]);
> + if (IS_ERR(mclk))
> + return PTR_ERR(mclk);
> +
> + if (clk_get_rate(mclk) == CLK32K_RATE) {
> + arizona->pdata.clk32k_src = ARIZONA_32KZ_MCLK1 + i;
> + arizona->pdata.clk32k_parent = __clk_get_name(mclk);
> + }
> +
> + clk_put(mclk);
Is this configuring some mux for the 32kHz source? Perhaps this
can be done with assigned clock parents and a set_parent clk_op
instead of with of_clk_get_by_name() in a loop over the possible
parents?
> + }
> +
> + return 0;
> +}
> +
> +static int arizona_clk_probe(struct platform_device *pdev)
> +{
[..]
> +
> + if (arizona->pdata.clk32k_parent) {
> + clk32k_init.num_parents = 1;
> + clk32k_init.parent_names = &arizona->pdata.clk32k_parent;
> + } else {
> + clk32k_init.flags |= CLK_IS_ROOT;
> + }
> +
> + clkdata->clk32k_hw.init = &clk32k_init;
> + clkdata->clk32k = devm_clk_register(&pdev->dev, &clkdata->clk32k_hw);
> + if (IS_ERR(clkdata->clk32k)) {
> + ret = PTR_ERR(clkdata->clk32k);
> + dev_err(arizona->dev, "Failed to register 32k clock: %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = clk_register_clkdev(clkdata->clk32k, "arizona-32k",
> + dev_name(arizona->dev));
Any reason we register with clkdev but don't register an of clk
provider?
> + if (ret) {
> + dev_err(arizona->dev, "Failed to register 32k clock dev: %d\n",
> + ret);
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, clkdata);
> +
> + return 0;
> +}
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of/irq: Export of_irq_count()
On 12/22, Rob Herring wrote:
> On Tue, Dec 22, 2015 at 6:22 AM, Mark Brown wrote:
> > Some of the Qualcomm pinctrl drivers have started trying to use
> > of_irq_count() in modular code but this fails to build as the symbol is
> > not exported. Since there doesn't seem to be any reason not to export
> > the symbol make it available to modules.
>
> The reason it has not been exported is because we want to stick with
> the platform_* APIs for IRQs. There's not really an equivalent
> function though. Perhaps we should make one? Usually it is just used
> for allocating some driver data. If that is the case, is it really
> enough data to not just allocate the max?
>
It's mostly used for allocation but we also do some pin type
discovery by reading registers and that would fail if we went
past the actual number of pins there are.
So how about implementing platform_irq_count()? I'd like to keep
these drivers as tristate if possible.
8<
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index d77ed0c946dd..421c67f8fdef 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -118,6 +118,25 @@ int platform_get_irq(struct platform_device *dev, unsigned
int num)
EXPORT_SYMBOL_GPL(platform_get_irq);
/**
+ * platform_irq_count - Count the number of IRQs a platform device uses
+ * @dev: platform device
+ *
+ * Return: Number of IRQs a platform device uses or EPROBE_DEFER
+ */
+int platform_irq_count(struct platform_device *dev)
+{
+ int ret, nr = 0;
+
+ while ((ret = platform_get_irq(dev, nr)) == 0)
+ nr++;
+
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ return nr;
+}
+
+/**
* platform_get_resource_byname - get a resource for a device by name
* @dev: platform device
* @type: resource type
--
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 devicetree" 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 10/10] dt-bindings: Add DSIv2 documentation
On 12/02, Archit Taneja wrote: > On 12/02/2015 01:50 PM, Stephen Boyd wrote: > > > >My only thought there would be to make of_clk_set_defaults() wait > >until both clocks are registered before it does any parent > >setting. But only in the case where the assigned parents contains > >a clock that is provided by the node being processed. I suppose > >the simplest thing to do would be to skip it during the device > >driver probe and handle it when the clk provider is registered. > > > > The assigned-clock-parents stuff you mentioned is needed to set a > default link between the one of the DSI PLLs and the RCG, right? I > just wanted to make clear if we were still discussing the same > issue. Yes. > > From what I understand, we don't need the assigned-clock-parents stuff > to establish a link between byte_clk_src(RCG clock) and > byte_clk(branch clock). That's a fixed link set up by the clock > structs provided in the gcc driver and doesn't need to be specially > assigned, and just a > clk_get_parent in the driver does the job there. There's only one parent of the byte_clk and that's byte_clk_src. So yes, there's no need to describe that in DT and clk_get_parent() works fine. > > About assigning a parent to the RCG, wouldn't that be xo by default, and > changed by the drm/msm driver to one of the PLLs when the need arrives? > I didn't get why we need to establish that beforehand in DT? > Yes, it would be XO out of reset, but we have no idea what the bootloader is doing. I thought the problem was that byte_clk_src is not actually an input to the DSI device. The proposal was to have DT specify byte_clk_src and byte_clk in the clocks array so that byte_clk_src could be reparented to the PLL and the byte_clk could be enabled/disabled. If we use DT to do the parent configuring then the DSI node doesn't have the byte_clk_src in its clocks array and thus DT is reflecting reality. If we want to dynamically switch the parent of byte_clk_src to be different PLLs at runtime, then yes we'll need to get the parent of the byte_clk (which is byte_clk_src) and set the PLL as the parent. Or we'll need to make clk_set_parent() on the byte_clk transparently set the grand-parent to be the PLL. In that case we may need to introduce some sort of flag like CLK_SET_PARENT_GRANDPARENT to add this type of behavior. I don't have a huge problem with clk_set_parent(clk_get_parent(byte_clk), PLL) except that this fails the abstraction test. It leaks information about the clock tree into a driver that shouldn't need to know that on this particular SoC there's a clock in between the PLL and the byte_clk. Future designs may not have the intermediate clock and then we'll need to update the driver to handle the difference, when we could have added the flag and things would work the same. -- 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 devicetree" 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 10/10] dt-bindings: Add DSIv2 documentation
On 12/02, Stephen Boyd wrote: > > My only thought there would be to make of_clk_set_defaults() wait > until both clocks are registered before it does any parent > setting. But only in the case where the assigned parents contains > a clock that is provided by the node being processed. I suppose > the simplest thing to do would be to skip it during the device > driver probe and handle it when the clk provider is registered. > Actually it looks like we already have the code for that. if (clkspec.np == node && !clk_supplier) return 0; So assigned parents should "just work"? -- 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 devicetree" 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 10/10] dt-bindings: Add DSIv2 documentation
On 11/23, Archit Taneja wrote: > > > On 11/21/2015 1:29 AM, Rob Herring wrote: > >+Stephen > > > >On Wed, Nov 18, 2015 at 9:24 AM, Archit Taneja > >wrote: > >>Hi Rob, > >> > >>On 11/18/2015 6:48 PM, Rob Herring wrote: > >>> > >>>+dt list > >>> > >>>On Wed, Nov 18, 2015 at 4:55 AM, Archit Taneja > >>>wrote: > > Add additional property info needed for DSIv2 DT. > >>> > >>> > >>>Please use get_maintainers.pl. > >> > >> > >>Sorry about that, missed out doing that posting this time. > >> > >>> > Signed-off-by: Archit Taneja > --- > Documentation/devicetree/bindings/display/msm/dsi.txt | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt > b/Documentation/devicetree/bindings/display/msm/dsi.txt > index f344b9e..ca65a34 100644 > --- a/Documentation/devicetree/bindings/display/msm/dsi.txt > +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt > @@ -13,18 +13,25 @@ Required properties: > - power-domains: Should be <&mmcc MDSS_GDSC>. > - clocks: device clocks > See Documentation/devicetree/bindings/clocks/clock-bindings.txt for > details. > -- clock-names: the following clocks are required: > +- clock-names: these vary based on the DSI version. For DSI6G: > * "bus_clk" > * "byte_clk" > + * "byte_clk_src > >>> > >>> > >>>This sounds like the parent of byte_clk. Is that really a clock within > >>>the block? > >> > >> > >>byte_clk_src isn't in the block, but byte_clk_src's parent is one of > >>the PLLs in this block. We take this clock so that we can re-parent > >>it to an appropriate PLL. The decision of what PLL to choose needs to > >>be done by the DSI block's driver. > > > >Seems like abuse to me. The list of clocks should match what are > >inputs to the block, not what the driver happens to need. Without a > >full understanding of the clock tree here, I don't have a suggestion. > >Maybe Stephen does. > > We don't need specify byte_clk_src (and other xyz_clk_src clocks) via > DT. There is a static link set up between byte_clk and byte_clk_src by > our clock driver that never changes. We can retrieve it in the driver > itself using clk_get_parent(byte_clk). This way we stick to only > input clocks. > > Stephen, does that sound okay? > I guess so. From the DT perspective it's "correct" so sure. It would be nice if we could use assigned-clock-parents though. As far as I can recall that's hard because the clock tree looks like a cyclic graph when we take a clock provider level view. The display block consumes the byte_clk and provides the source of it too. So if we used assigned parents we would need to wait for both clocks to be registered with the framework before we can reconfigure the parent of byte_clk_src to be the PLL that the display clock outputs. Unfortunately, of_clk_set_defaults() is called during device driver probe, which in the display driver case would be before the PLL is registered. My only thought there would be to make of_clk_set_defaults() wait until both clocks are registered before it does any parent setting. But only in the case where the assigned parents contains a clock that is provided by the node being processed. I suppose the simplest thing to do would be to skip it during the device driver probe and handle it when the clk provider is registered. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arm64: dts: qcom: Add apq8096 dragonboard dts skeletons
On 12/01, Rajendra Nayak wrote: > > On 12/01/2015 05:18 AM, Stephen Boyd wrote: > > On 11/26, Rajendra Nayak wrote: > >> Add new dtsi and dts files for the apq8096 dragonboards with just > >> a serial device used as debug console > >> > >> Signed-off-by: Rajendra Nayak > >> --- > >> Patch applies on top of Stephens' patches to add msm8996 dtsi > >> https://lkml.org/lkml/2015/11/17/955 > >> > >> arch/arm64/boot/dts/qcom/Makefile | 2 +- > >> arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts | 21 > >> arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi | 30 > >> +++ > >> 3 files changed, 52 insertions(+), 1 deletion(-) > >> create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts > >> create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi > >> > >> diff --git a/arch/arm64/boot/dts/qcom/Makefile > >> b/arch/arm64/boot/dts/qcom/Makefile > >> index fa1f661..bd992ef 100644 > >> --- a/arch/arm64/boot/dts/qcom/Makefile > >> +++ b/arch/arm64/boot/dts/qcom/Makefile > >> @@ -1,5 +1,5 @@ > >> dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc.dtb msm8916-mtp.dtb > >> -dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb > >> +dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb apq8096-dragonboard.dtb > > > > We should move to one dtb per line in this file. Other platforms > > are doing the same thing. > > Sure, will repost with the change. I just saw the 8916/8016 ones were all in > a single line so did the same. > Yeah we should probably change the 8916 one too. Make everything the same. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arm64: dts: qcom: Add apq8096 dragonboard dts skeletons
On 11/26, Rajendra Nayak wrote: > Add new dtsi and dts files for the apq8096 dragonboards with just > a serial device used as debug console > > Signed-off-by: Rajendra Nayak > --- > Patch applies on top of Stephens' patches to add msm8996 dtsi > https://lkml.org/lkml/2015/11/17/955 > > arch/arm64/boot/dts/qcom/Makefile | 2 +- > arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts | 21 > arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi | 30 > +++ > 3 files changed, 52 insertions(+), 1 deletion(-) > create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts > create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi > > diff --git a/arch/arm64/boot/dts/qcom/Makefile > b/arch/arm64/boot/dts/qcom/Makefile > index fa1f661..bd992ef 100644 > --- a/arch/arm64/boot/dts/qcom/Makefile > +++ b/arch/arm64/boot/dts/qcom/Makefile > @@ -1,5 +1,5 @@ > dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc.dtb msm8916-mtp.dtb > -dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb > +dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb apq8096-dragonboard.dtb We should move to one dtb per line in this file. Other platforms are doing the same thing. -- 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 devicetree" 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/3] ARM: imx: clk-vf610: fix SAI clock tree
On 11/23, Shawn Guo wrote: > On Sat, Oct 17, 2015 at 09:05:20PM -0700, Stefan Agner wrote: > > > > Since Patch 3 also uses the fixed clock layout, it should be > > applied after the clock tree fix too... > > > > Not sure through which tree these changes should go? > > Mike, Stephen, > > Can I have your ACK on patch #1 so that I can send it together with > #2 for v4.4-rc inclusion? > Yes that's fine. -- 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 devicetree" 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/3] ARM: imx: clk-vf610: fix SAI clock tree
On 10/17, Stefan Agner wrote: > The Synchronous Audio Interface (SAI) instances are clocked by > independent clocks: The bus clock and the audio clock (as shown in > Figure 51-1 in the Vybrid Reference Manual). The clock gates in > CCGR0/CCGR1 for SAI0 through SAI3 are bus clock gates, as access > tests to the registers with/without gating those clocks have shown. > The audio clock is gated by the SAIx_EN gates in CCM_CSCDR1, > followed by a clock divider (SAIx_DIV). Currently, the parent of > the bus clock gates has been assigned to SAIx_DIV, which is not > involved in the bus clock path for the SAI instances (see chapter > 9.10.12, SAI clocking in the Vybrid Reference Manual). > > Fix this by define the parent clock of VF610_CLK_SAIx to be the bus > clock. > > If the driver needs the audio clock (when used in master mode), a > fixed device tree is required which assign the audio clock properly > to VF610_CLK_SAIx_DIV. > > Signed-off-by: Stefan Agner > --- Acked-by: Stephen Boyd -- 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 devicetree" 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 1/5] devicetree: bindings: Document qcom board compatible format
On 11/22, Rob Herring wrote:
> On Fri, Nov 20, 2015 at 03:31:16PM -0800, Stephen Boyd wrote:
> > Some qcom based bootloaders identify the dtb blob based on a set
> > of device properties like SoC, platform, PMIC, and revisions of
> > those components. In downstream kernels, these values are added
> > to the different component dtsi files (i.e. pmic dtsi file, SoC
> > dtsi file, board dtsi file, etc.) via qcom specific DT
> > properties. The dtb files are parsed by a program called dtbTool
> > that picks out these properties and creates a table of contents
> > binary blob with the property information and some offsets into
> > the concatenation of all the dtbs (termed a QCDT image).
> >
> > The suggestion is to do this via the board compatible string
> > instead, because these qcom specific properties are never used by
> > the kernel. Add a document describing the format of the
> > compatible string that encodes all this information that's
> > currently encoded in the qcom,{msm-id,board-id,pmic-id}
> > properties in downstream devicetrees. Future bootloaders may be
> > updated to look at the compatible field instead of looking for
> > the table of contents image. For non-updateable bootloaders, a
> > new dtbTool program will parse the compatible string and generate
> > a QCDT image from it.
> >
> > Signed-off-by: Stephen Boyd
>
> Much more reasonable now. I do find the '/' in it a bit strange though.
I can remove the backslash if you like. Is a dash more preferred?
>
> Acked-by: Rob Herring
>
and if so can I keep the ack? I'll resend with that change and
add the ack.
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: dts: qcom: Add generic PMIC gpio/MPP compat strings
Add the generic compatible strings for the PMIC gpio and MPP
modules found on qcom based PMICs.
Cc:
Cc: "Ivan T. Ivanov"
Cc: Bjorn Andersson
Cc: Rob Herring
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 6 --
arch/arm/boot/dts/qcom-pm8841.dtsi | 2 +-
arch/arm/boot/dts/qcom-pm8941.dtsi | 4 ++--
arch/arm/boot/dts/qcom-pma8084.dtsi | 4 ++--
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 11aca7fb1793..d0670d0ee08c 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -430,7 +430,8 @@
pm8921_gpio: gpio@150 {
- compatible = "qcom,pm8921-gpio";
+ compatible = "qcom,pm8921-gpio",
+"qcom,ssbi-gpio";
reg = <0x150>;
interrupts = <192 1>, <193 1>, <194 1>,
<195 1>, <196 1>, <197 1>,
@@ -454,7 +455,8 @@
};
pm8921_mpps: mpps@50 {
- compatible = "qcom,pm8921-mpp";
+ compatible = "qcom,pm8921-mpp",
+"qcom,ssbi-mpp";
reg = <0x50>;
gpio-controller;
#gpio-cells = <2>;
diff --git a/arch/arm/boot/dts/qcom-pm8841.dtsi
b/arch/arm/boot/dts/qcom-pm8841.dtsi
index 523bee959f98..9f357f68713c 100644
--- a/arch/arm/boot/dts/qcom-pm8841.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8841.dtsi
@@ -10,7 +10,7 @@
#size-cells = <0>;
pm8841_mpps: mpps@a000 {
- compatible = "qcom,pm8841-mpp";
+ compatible = "qcom,pm8841-mpp", "qcom,spmi-mpp";
reg = <0xa000 0x400>;
gpio-controller;
#gpio-cells = <2>;
diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi
b/arch/arm/boot/dts/qcom-pm8941.dtsi
index 12c1202ba2ca..64622bd251d1 100644
--- a/arch/arm/boot/dts/qcom-pm8941.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
@@ -48,7 +48,7 @@
};
pm8941_gpios: gpios@c000 {
- compatible = "qcom,pm8941-gpio";
+ compatible = "qcom,pm8941-gpio", "qcom,spmi-gpio";
reg = <0xc000 0x2400>;
gpio-controller;
#gpio-cells = <2>;
@@ -91,7 +91,7 @@
};
pm8941_mpps: mpps@a000 {
- compatible = "qcom,pm8941-mpp";
+ compatible = "qcom,pm8941-mpp", "qcom,spmi-mpp";
reg = <0xa000 0x800>;
gpio-controller;
#gpio-cells = <2>;
diff --git a/arch/arm/boot/dts/qcom-pma8084.dtsi
b/arch/arm/boot/dts/qcom-pma8084.dtsi
index 10b8f9e6d60b..4e9bd3f88473 100644
--- a/arch/arm/boot/dts/qcom-pma8084.dtsi
+++ b/arch/arm/boot/dts/qcom-pma8084.dtsi
@@ -19,7 +19,7 @@
};
pma8084_gpios: gpios@c000 {
- compatible = "qcom,pma8084-gpio";
+ compatible = "qcom,pma8084-gpio", "qcom,spmi-gpio";
reg = <0xc000 0x1600>;
gpio-controller;
#gpio-cells = <2>;
@@ -48,7 +48,7 @@
};
pma8084_mpps: mpps@a000 {
- compatible = "qcom,pma8084-mpp";
+ compatible = "qcom,pma8084-mpp", "qcom,spmi-mpp";
reg = <0xa000 0x800>;
gpio-controller;
#gpio-cells = <2>;
--
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 devicetree" 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 0/3] clk: Broadcom BCM63138 support
On 11/20, Florian Fainelli wrote: > On 20/11/15 10:46, Stephen Boyd wrote: > > On 11/19, Florian Fainelli wrote: > >> On 19/11/15 17:00, Florian Fainelli wrote: > >>> On 29/10/15 18:23, Florian Fainelli wrote: > >>>> This patch series adds support for the Broadcom BCM63138 DSL SoCs > >>>> clocking framework. > >>>> > >>>> Since the HW is identical to the one found in Broadcom iProc SoCs, but > >>>> the > >>>> integration is different (obviously), there is still a new compatible > >>>> string > >>>> introduced just in case we happen to find issues in the future. > >>>> > >>>> Stephen, could you stage the two patches in a clk-bcm63xx branch that I > >>>> could > >>>> later utilize while doing the arm-soc DT pull request? > >>> > >>> Stephen, can you queue the first two patches in a topic branch for me to > >>> merge as part of the commit adding the DTS changes? > >> > >> Well, now that I look back at the changes, you can actually merge the > >> two patches in clk-next, and the DTS changes can come in before or > >> after, it does not really matter, this would not cause breakage or > >> anything. Sorry for the noise. > > > > Really? I thought if the clk patches aren't there then the dts > > change would cause some clocks to be orphaned. If that's ok with > > you it's ok with me. > > Woah, I guess I was not thinking very clearly yesterday, yes, we need to > bundle these changes together, so if you are still okay with the topic > branch for me to include as a merge commit, that's fine with me as well. Ok. Done. -- 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 devicetree" 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 2/3] clk: bcm: Add BCM63138 clock support
On 10/29, Florian Fainelli wrote: > BCM63138 has a simple clocking domain which is primarily the ARMPLL > clocking complex, from which the ARM (CPU), APB and AXI clocks would be > derived from. > > Since the ARMPLL controller is entirely compatible with the iProc ARM > PLL, we just initialize it without additional parameters. > > Signed-off-by: Florian Fainelli > --- Applied to clk-bcm63xx -- 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 devicetree" 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 1/3] clk: iproc: Extend binding to cover BCM63138
On 10/29, Florian Fainelli wrote: > Broadcom BCM63138 DSL SoCs have the same ARMPLL clocking infrastructure > as the Cygnus and iProc chips, add a dedicated compatible string and > document that the ARMPLL node is a valid node for this chip. > > Acked-by: Rob Herring > Signed-off-by: Florian Fainelli > --- Applied to clk-bcm63xx -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] arm: dts: qcom: Update ifc6540 compat for qcom boot format
The ifc6540 is an sbc (single board computer) board, so update
the compatible field accordingly.
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
index c9c2b769554f..32aaa9d45228 100644
--- a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
+++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
@@ -3,7 +3,7 @@
/ {
model = "Qualcomm APQ8084/IFC6540";
- compatible = "qcom,apq8084-ifc6540", "qcom,apq8084";
+ compatible = "qcom,apq8084-sbc", "qcom,apq8084";
aliases {
serial0 = &blsp2_uart2;
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] arm64: dts: qcom: Alias pm8916 on msm8916 devices
Add an alias for pm8916 on msm8916 based SoCs so that the newly
updated dtbTool can find the pmic compatible string and add the
pmic-id element to the QCDT header.
Signed-off-by: Stephen Boyd
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 1 +
arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi | 1 +
arch/arm64/boot/dts/qcom/pm8916.dtsi | 6 +++---
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 6b8abbe68746..46bfcb9b2e84 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -20,6 +20,7 @@
aliases {
serial0 = &blsp1_uart2;
serial1 = &blsp1_uart1;
+ usid0 = &pm8916_0;
};
chosen {
diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
index a1aa0b201e92..ceeb8a6feed6 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
@@ -17,6 +17,7 @@
/ {
aliases {
serial0 = &blsp1_uart2;
+ usid0 = &pm8916_0;
};
chosen {
diff --git a/arch/arm64/boot/dts/qcom/pm8916.dtsi
b/arch/arm64/boot/dts/qcom/pm8916.dtsi
index b222ece7e3d2..37432451ee4c 100644
--- a/arch/arm64/boot/dts/qcom/pm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8916.dtsi
@@ -4,8 +4,8 @@
&spmi_bus {
- usid0: pm8916@0 {
- compatible = "qcom,spmi-pmic";
+ pm8916_0: pm8916@0 {
+ compatible = "qcom,pm8916", "qcom,spmi-pmic";
reg = <0x0 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
@@ -90,7 +90,7 @@
};
};
- usid1: pm8916@1 {
+ pm8916_1: pm8916@1 {
compatible = "qcom,spmi-pmic";
reg = <0x1 SPMI_USID>;
#address-cells = <1>;
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] arm: dts: qcom: Add aliases for PMICs
Add an alias for the PMICs found on qcom based SoCs so that the
newly updated dtbTool can find the PMIC compatible string and add
the pmic-id element to the QCDT header.
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 2 ++
arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 1 +
arch/arm/boot/dts/qcom-apq8084-mtp.dts | 1 +
arch/arm/boot/dts/qcom-pm8841.dtsi | 8
arch/arm/boot/dts/qcom-pm8941.dtsi | 8
arch/arm/boot/dts/qcom-pma8084.dtsi| 8
6 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
index 835bdc71c5ba..c0e205315042 100644
--- a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
@@ -8,6 +8,8 @@
aliases {
serial0 = &blsp1_uart2;
+ usid0 = &pm8941_0;
+ usid4 = &pm8841_0;
};
chosen {
diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
index 32aaa9d45228..2052b84a77c6 100644
--- a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
+++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
@@ -7,6 +7,7 @@
aliases {
serial0 = &blsp2_uart2;
+ usid0 = &pma8084_0;
};
chosen {
diff --git a/arch/arm/boot/dts/qcom-apq8084-mtp.dts
b/arch/arm/boot/dts/qcom-apq8084-mtp.dts
index 3016c7048d44..d174d15bcf70 100644
--- a/arch/arm/boot/dts/qcom-apq8084-mtp.dts
+++ b/arch/arm/boot/dts/qcom-apq8084-mtp.dts
@@ -7,6 +7,7 @@
aliases {
serial0 = &blsp2_uart2;
+ usid0 = &pma8084_0;
};
chosen {
diff --git a/arch/arm/boot/dts/qcom-pm8841.dtsi
b/arch/arm/boot/dts/qcom-pm8841.dtsi
index 8f1a0b162017..523bee959f98 100644
--- a/arch/arm/boot/dts/qcom-pm8841.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8841.dtsi
@@ -3,8 +3,8 @@
&spmi_bus {
- usid4: pm8841@4 {
- compatible = "qcom,spmi-pmic";
+ pm8841_0: pm8841@4 {
+ compatible = "qcom,pm8841", "qcom,spmi-pmic";
reg = <0x4 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
@@ -27,8 +27,8 @@
};
};
- usid5: pm8841@5 {
- compatible = "qcom,spmi-pmic";
+ pm8841_1: pm8841@5 {
+ compatible = "qcom,pm8841", "qcom,spmi-pmic";
reg = <0x5 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi
b/arch/arm/boot/dts/qcom-pm8941.dtsi
index c19a48732b2d..12c1202ba2ca 100644
--- a/arch/arm/boot/dts/qcom-pm8941.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
@@ -4,8 +4,8 @@
&spmi_bus {
- usid0: pm8941@0 {
- compatible ="qcom,spmi-pmic";
+ pm8941_0: pm8941@0 {
+ compatible = "qcom,pm8941", "qcom,spmi-pmic";
reg = <0x0 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
@@ -153,8 +153,8 @@
};
};
- usid1: pm8941@1 {
- compatible = "qcom,spmi-pmic";
+ pm8941_1: pm8941@1 {
+ compatible = "qcom,pm8941", "qcom,spmi-pmic";
reg = <0x1 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/qcom-pma8084.dtsi
b/arch/arm/boot/dts/qcom-pma8084.dtsi
index 5e240ccc08b7..10b8f9e6d60b 100644
--- a/arch/arm/boot/dts/qcom-pma8084.dtsi
+++ b/arch/arm/boot/dts/qcom-pma8084.dtsi
@@ -4,8 +4,8 @@
&spmi_bus {
- usid0: pma8084@0 {
- compatible = "qcom,spmi-pmic";
+ pma8084_0: pma8084@0 {
+ compatible = "qcom,pma8084", "qcom,spmi-pmic";
reg = <0x0 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
@@ -101,8 +101,8 @@
};
};
- usid1: pma8084@1 {
- compatible = "qcom,spmi-pmic";
+ pma8084_1: pma8084@1 {
+ compatible = "qcom,pma8084", "qcom,spmi-pmic";
reg = <0x1 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] devicetree: bindings: Document qcom board compatible format
Some qcom based bootloaders identify the dtb blob based on a set
of device properties like SoC, platform, PMIC, and revisions of
those components. In downstream kernels, these values are added
to the different component dtsi files (i.e. pmic dtsi file, SoC
dtsi file, board dtsi file, etc.) via qcom specific DT
properties. The dtb files are parsed by a program called dtbTool
that picks out these properties and creates a table of contents
binary blob with the property information and some offsets into
the concatenation of all the dtbs (termed a QCDT image).
The suggestion is to do this via the board compatible string
instead, because these qcom specific properties are never used by
the kernel. Add a document describing the format of the
compatible string that encodes all this information that's
currently encoded in the qcom,{msm-id,board-id,pmic-id}
properties in downstream devicetrees. Future bootloaders may be
updated to look at the compatible field instead of looking for
the table of contents image. For non-updateable bootloaders, a
new dtbTool program will parse the compatible string and generate
a QCDT image from it.
Signed-off-by: Stephen Boyd
---
Documentation/devicetree/bindings/arm/qcom.txt | 51 ++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/qcom.txt
diff --git a/Documentation/devicetree/bindings/arm/qcom.txt
b/Documentation/devicetree/bindings/arm/qcom.txt
new file mode 100644
index ..3e24518c6678
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom.txt
@@ -0,0 +1,51 @@
+QCOM device tree bindings
+-
+
+Some qcom based bootloaders identify the dtb blob based on a set of
+device properties like SoC and platform and revisions of those components.
+To support this scheme, we encode this information into the board compatible
+string.
+
+Each board must specify a top-level board compatible string with the following
+format:
+
+ compatible =
"qcom,[-][-]-[/][-]"
+
+The 'SoC' and 'board' elements are required. All other elements are optional.
+
+The 'SoC' element must be one of the following strings:
+
+ apq8016
+ apq8074
+ apq8084
+ apq8096
+ msm8916
+ msm8974
+ msm8996
+
+The 'board' element must be one of the following strings:
+
+ cdp
+ liquid
+ dragonboard
+ mtp
+ sbc
+
+The 'soc_version' and 'board_version' elements take the form of
v.
+where the minor number may be omitted when it's zero, i.e. v1.0 is the same
+as v1. If all versions of the 'board_version' elements match, then a
+wildcard '*' should be used, e.g. 'v*'.
+
+The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9.
+
+Examples:
+
+ "qcom,msm8916-v1-cdp-pm8916-v2.1"
+
+A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version
+2.1.
+
+ "qcom,apq8074-v2.0-2-dragonboard/1-v0.1"
+
+A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
+foundry 2.
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] arm64: dts: qcom: Make msm8916-mtp compatible string compliant
This compatible string isn't compliant with the format for
subtypes. Replace it with a compliant compatible type.
Signed-off-by: Stephen Boyd
---
arch/arm64/boot/dts/qcom/msm8916-mtp.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
index fced77f0fd3a..b0a064d3806b 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
@@ -17,6 +17,6 @@
/ {
model = "Qualcomm Technologies, Inc. MSM 8916 MTP";
- compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp-smb1360",
+ compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp/1",
"qcom,msm8916", "qcom,mtp";
};
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] Remove the need for qcom,{msm-id,board-id,pmic-id}
This patchset documents a compatible string format that encodes all the information that was being encoded in qcom specific DT properties in downstream msm kernels. The goal being to come up with a format that will allow us to express the information we want to express without requiring the use of vendor specific properties. An updated dtbTool will be released after these new bindings are accepted so that users can work with non-updateable bootloaders. This is an attempt to resolve a discussion around March of this year[1] where the arm-soc maintainers suggested we express this information through the board's compatible string. Changes from v1: * Remove unused elements (mb, panel, boot device) * Remove PMICs from board compatible * Add patches to allow us to parse PMIC compatibles with aliases [1] http://lkml.kernel.org/g/1425503602-24916-1-git-send-email-ga...@codeaurora.org Stephen Boyd (5): devicetree: bindings: Document qcom board compatible format arm64: dts: qcom: Make msm8916-mtp compatible string compliant arm: dts: qcom: Update ifc6540 compat for qcom boot format arm64: dts: qcom: Alias pm8916 on msm8916 devices arm: dts: qcom: Add aliases for PMICs Documentation/devicetree/bindings/arm/qcom.txt | 51 ++ arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 2 + arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 3 +- arch/arm/boot/dts/qcom-apq8084-mtp.dts | 1 + arch/arm/boot/dts/qcom-pm8841.dtsi | 8 ++-- arch/arm/boot/dts/qcom-pm8941.dtsi | 8 ++-- arch/arm/boot/dts/qcom-pma8084.dtsi| 8 ++-- arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 1 + arch/arm64/boot/dts/qcom/msm8916-mtp.dts | 2 +- arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi | 1 + arch/arm64/boot/dts/qcom/pm8916.dtsi | 6 +-- 11 files changed, 74 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/qcom.txt -- 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 devicetree" 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 0/3] clk: Broadcom BCM63138 support
On 11/19, Florian Fainelli wrote: > On 19/11/15 17:00, Florian Fainelli wrote: > > On 29/10/15 18:23, Florian Fainelli wrote: > >> This patch series adds support for the Broadcom BCM63138 DSL SoCs > >> clocking framework. > >> > >> Since the HW is identical to the one found in Broadcom iProc SoCs, but the > >> integration is different (obviously), there is still a new compatible > >> string > >> introduced just in case we happen to find issues in the future. > >> > >> Stephen, could you stage the two patches in a clk-bcm63xx branch that I > >> could > >> later utilize while doing the arm-soc DT pull request? > > > > Stephen, can you queue the first two patches in a topic branch for me to > > merge as part of the commit adding the DTS changes? > > Well, now that I look back at the changes, you can actually merge the > two patches in clk-next, and the DTS changes can come in before or > after, it does not really matter, this would not cause breakage or > anything. Sorry for the noise. Really? I thought if the clk patches aren't there then the dts change would cause some clocks to be orphaned. If that's ok with you it's ok with me. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] pinctrl: qcom: Add generic ssbi and spmi GPIO/MPP bindings
On 11/19, Rob Herring wrote: > On Tue, Nov 17, 2015 at 05:00:26PM -0800, Stephen Boyd wrote: > > The drivers don't really need to know which PMIC they're for, so > > make a generic binding for them. This alleviates us from updating > > the drivers every time a new PMIC comes out. It's still > > recommended that we update the binding with new PMIC models and > > always specify the specific model for the MPPs and gpios before > > the generic compatible string in devicetree, but this at least > > cuts down on adding more and more compatible strings to the > > drivers until we actually need them. > > > > Cc: > > Cc: "Ivan T. Ivanov" > > Cc: Bjorn Andersson > > Signed-off-by: Stephen Boyd > > --- > > Seems okay to me. I assume you are going to update all the dts files? Yep, I'll send out patches to do that. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: add generic driver for fixed rate clock
On 11/17, Geert Uytterhoeven wrote: > Hi Stefan, > > (quoting the full driver, as it predates linux-clk) > > On Sun, Sep 1, 2013 at 6:40 AM, Stefan Kristiansson > wrote: > > This adds a simple driver with the only purpose to initialise > > the fixed rate clock. > > This is useful for systems that do not wish to use seperate init > > code for the fixed rate clock init, but rather only rely on a > > device tree description of it. > > > > Signed-off-by: Stefan Kristiansson > > Thanks, this is still very useful! > > I stumbled across this old patch while trying to instantiate a fixed rate > clock from a DT overlay. > Without this, the clock is never instantiated, as drivers/clk/clk-fixed-rate.c > uses CLK_OF_DECLARE() :-( With your driver, it works as expected > (after fixing the modpost complaint, cfr. below). > > However, I think that instead of creating a new driver, you should just add > the meat of clk-generic-fixed.c to clk-fixed-rate.c. Hm... what happens when of_clk_init() runs and instantiates the clock, and then of_platform_populate() runs and creates the clock again? The platform device probe fails because the framework checks to make sure two clocks don't have the same name? I guess that's going to work, but it doesn't make me feel good. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Add DTS for MSM8996 SoC and MTP
These patches add the initial dts files for the MSM8996 SoC and MTP evaluation board. Stephen Boyd (4): devicetree: bindings: Document Kryo cpu arm64: dts: Add msm8996 SoC and MTP board support arm64: dts: qcom: Add pm8994, pmi8994, pm8004 PMIC skeletons arm64: dts: qcom: Add pm8994 gpios and MPPs Documentation/devicetree/bindings/arm/cpus.txt | 1 + arch/arm64/boot/dts/qcom/Makefile | 1 + arch/arm64/boot/dts/qcom/msm8996-mtp.dts | 21 ++ arch/arm64/boot/dts/qcom/msm8996-mtp.dtsi | 30 +++ arch/arm64/boot/dts/qcom/msm8996.dtsi | 267 + arch/arm64/boot/dts/qcom/pm8004.dtsi | 19 ++ arch/arm64/boot/dts/qcom/pm8994.dtsi | 62 ++ arch/arm64/boot/dts/qcom/pmi8994.dtsi | 19 ++ 8 files changed, 420 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/msm8996-mtp.dts create mode 100644 arch/arm64/boot/dts/qcom/msm8996-mtp.dtsi create mode 100644 arch/arm64/boot/dts/qcom/msm8996.dtsi create mode 100644 arch/arm64/boot/dts/qcom/pm8004.dtsi create mode 100644 arch/arm64/boot/dts/qcom/pm8994.dtsi create mode 100644 arch/arm64/boot/dts/qcom/pmi8994.dtsi -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] devicetree: bindings: Document Kryo cpu
Document the compatible string for the Kryo family of qcom cpus. Cc: Signed-off-by: Stephen Boyd --- Documentation/devicetree/bindings/arm/cpus.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 3a07a87fef20..6008b99ccb2b 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -177,6 +177,7 @@ nodes to be present and contain the properties described below. "marvell,sheeva-v5" "nvidia,tegra132-denver" "qcom,krait" + "qcom,kryo" "qcom,scorpion" - enable-method Value type: -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] pinctrl: qcom: Add generic ssbi and spmi GPIO/MPP bindings
The drivers don't really need to know which PMIC they're for, so
make a generic binding for them. This alleviates us from updating
the drivers every time a new PMIC comes out. It's still
recommended that we update the binding with new PMIC models and
always specify the specific model for the MPPs and gpios before
the generic compatible string in devicetree, but this at least
cuts down on adding more and more compatible strings to the
drivers until we actually need them.
Cc:
Cc: "Ivan T. Ivanov"
Cc: Bjorn Andersson
Signed-off-by: Stephen Boyd
---
We can also figure out the number of the pins from the number
of interrupts, so we really don't need to even look at the size of the
reg property or model number for the spmi and ssbi modules. I'll propose
that change as well tomorrow.
Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 5 -
Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt | 5 -
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
drivers/pinctrl/qcom/pinctrl-spmi-mpp.c | 1 +
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
index a90c812ad642..f1e4643f4132 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
@@ -17,6 +17,9 @@ PMIC's from Qualcomm.
"qcom,pm8994-gpio"
"qcom,pma8084-gpio"
+ And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio"
+ if the device is on an spmi bus or an ssbi bus respectively
+
- reg:
Usage: required
Value type:
@@ -183,7 +186,7 @@ to specify in a pin configuration subnode:
Example:
pm8921_gpio: gpio@150 {
- compatible = "qcom,pm8921-gpio";
+ compatible = "qcom,pm8921-gpio", "qcom,ssbi-gpio";
reg = <0x150 0x160>;
interrupts = <192 1>, <193 1>, <194 1>,
<195 1>, <196 1>, <197 1>,
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
index d74e631e10da..e28320b18ecb 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
@@ -18,6 +18,9 @@ of PMIC's from Qualcomm.
"qcom,pm8994-mpp",
"qcom,pma8084-mpp",
+ And must contain either "qcom,spmi-mpp" or "qcom,ssbi-mpp"
+ if the device is on an spmi bus or an ssbi bus respectively.
+
- reg:
Usage: required
Value type:
@@ -157,7 +160,7 @@ to specify in a pin configuration subnode:
Example:
mpps@a000 {
- compatible = "qcom,pm8841-mpp";
+ compatible = "qcom,pm8841-mpp", "qcom,spmi-mpp";
reg = <0xa000>;
gpio-controller;
#gpio-cells = <2>;
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index df4413023e21..9f9979903fcb 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -806,6 +806,7 @@ static const struct of_device_id pmic_gpio_of_match[] = {
{ .compatible = "qcom,pm8941-gpio" }, /* 36 GPIO's */
{ .compatible = "qcom,pm8994-gpio" }, /* 22 GPIO's */
{ .compatible = "qcom,pma8084-gpio" }, /* 22 GPIO's */
+ { .compatible = "qcom,spmi-gpio" }, /* Generic */
{ },
};
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
index 7b4136a22c5b..5a4373dd9c61 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
@@ -909,6 +909,7 @@ static const struct of_device_id pmic_mpp_of_match[] = {
{ .compatible = "qcom,pm8941-mpp" },/* 8 MPP's */
{ .compatible = "qcom,pm8994-mpp" },/* 8 MPP's */
{ .compatible = "qcom,pma8084-mpp" }, /* 8 MPP's */
+ { .compatible = "qcom,spmi-mpp" }, /* Generic */
{ },
};
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] pinctrl: qcom: spmi-gpio: Add pm8994 gpio support
Update the binding and driver for pm8994-gpio devices.
Cc:
Cc: "Ivan T. Ivanov"
Cc: Bjorn Andersson
Signed-off-by: Stephen Boyd
---
Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 2 ++
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
index 1ae63c0acd40..a90c812ad642 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
@@ -14,6 +14,7 @@ PMIC's from Qualcomm.
"qcom,pm8917-gpio"
"qcom,pm8921-gpio"
"qcom,pm8941-gpio"
+ "qcom,pm8994-gpio"
"qcom,pma8084-gpio"
- reg:
@@ -79,6 +80,7 @@ to specify in a pin configuration subnode:
gpio1-gpio38 for pm8917
gpio1-gpio44 for pm8921
gpio1-gpio36 for pm8941
+ gpio1-gpio22 for pm8994
gpio1-gpio22 for pma8084
- function:
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index 6c42ca14d2fd..df4413023e21 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -804,6 +804,7 @@ static int pmic_gpio_remove(struct platform_device *pdev)
static const struct of_device_id pmic_gpio_of_match[] = {
{ .compatible = "qcom,pm8916-gpio" }, /* 4 GPIO's */
{ .compatible = "qcom,pm8941-gpio" }, /* 36 GPIO's */
+ { .compatible = "qcom,pm8994-gpio" }, /* 22 GPIO's */
{ .compatible = "qcom,pma8084-gpio" }, /* 22 GPIO's */
{ },
};
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add pm8994 gpio and mpp support
This adds the support for pm8994 gpio and mpp modules. Given that there's nothing besides a compatible string update, I'm going to send a separate patch to add generic compatible strings for these sorts of things. Stephen Boyd (2): pinctrl: qcom: spmi-gpio: Add pm8994 gpio support pinctrl: qcom: spmi-mpp: Add pm8994 mpp support Cc: Cc: "Ivan T. Ivanov" Cc: Bjorn Andersson Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 2 ++ Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt | 1 + drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 + drivers/pinctrl/qcom/pinctrl-spmi-mpp.c | 1 + 4 files changed, 5 insertions(+) -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] pinctrl: qcom: spmi-mpp: Add pm8994 mpp support
Update the driver and binding for pm8994-mpp devices.
Cc:
Cc: "Ivan T. Ivanov"
Cc: Bjorn Andersson
Signed-off-by: Stephen Boyd
---
Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt | 1 +
drivers/pinctrl/qcom/pinctrl-spmi-mpp.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
index d7803a2a94e9..d74e631e10da 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
@@ -15,6 +15,7 @@ of PMIC's from Qualcomm.
"qcom,pm8917-mpp",
"qcom,pm8921-mpp",
"qcom,pm8941-mpp",
+ "qcom,pm8994-mpp",
"qcom,pma8084-mpp",
- reg:
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
index 9ce0e30e33e8..7b4136a22c5b 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
@@ -907,6 +907,7 @@ static const struct of_device_id pmic_mpp_of_match[] = {
{ .compatible = "qcom,pm8841-mpp" },/* 4 MPP's */
{ .compatible = "qcom,pm8916-mpp" },/* 4 MPP's */
{ .compatible = "qcom,pm8941-mpp" },/* 8 MPP's */
+ { .compatible = "qcom,pm8994-mpp" },/* 8 MPP's */
{ .compatible = "qcom,pma8084-mpp" }, /* 8 MPP's */
{ },
};
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pinctrl: qcom: Add msm8996 pinctrl driver
From: Joonwoo Park Add initial pinctrl driver to support pin configuration with pinctrl framework for msm8996. Cc: Cc: Bjorn Andersson Signed-off-by: Joonwoo Park [sb...@codeaurora.org: Remove duplicate entries and enums] Signed-off-by: Stephen Boyd --- .../bindings/pinctrl/qcom,msm8996-pinctrl.txt | 199 ++ drivers/pinctrl/qcom/Kconfig |8 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-msm8996.c | 1942 4 files changed, 2150 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8996.c diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt new file mode 100644 index ..e312a71b2f94 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt @@ -0,0 +1,199 @@ +Qualcomm MSM8996 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +MSM8996 platform. + +- compatible: + Usage: required + Value type: + Definition: must be "qcom,msm8996-pinctrl" + +- reg: + Usage: required + Value type: + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +- gpio-controller: + Usage: required + Value type: + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: + Definition: List of gpio pins affected by the properties specified in + this subnode. + + Valid pins are: + gpio0-gpio149 + Supports mux, bias and drive-strength + + sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd, + sdc2_data sdc1_rclk + Supports bias and drive-strength + +- function: + Usage: required + Value type: + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + + blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens, + bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8, + qdss_cti_trig_out_b, bimc_dte0, dac_calib1, qdss_cti_trig_in_b, + dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, blsp_uart10, + blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, atest_usb12, + mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11, + atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, atest_char, + cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, qdss_tracedata_b, + pll_reset, qdss_stm6, qdss_stm5, qdss_stm4, atest_usb2, cci_i2c, + qdss_stm3, dac_calib3, atest_usb23, ate
Re: [PATCH 1/3] devicetree: bindings: Document qcom board compatible format
On 11/12, Rob Herring wrote: > On Thu, Nov 12, 2015 at 6:11 PM, Stephen Boyd wrote: > > On 11/12, Rob Herring wrote: > >> On Thu, Nov 12, 2015 at 1:44 PM, Stephen Boyd wrote: > >> > On 11/12, Rob Herring wrote: > >> >> On Mon, Oct 26, 2015 at 02:25:10PM -0700, Stephen Boyd wrote: > >> > >> >> > +Some qcom based bootloaders identify the dtb blob based on a set of > >> >> > +device properties like SoC, platform, PMIC, and revisions of those > >> >> > components. > >> >> > +To support this scheme, we encode this information into the board > >> >> > compatible > >> >> > +string. > >> >> > >> >> Why does all this need to be a single property? > >> > > >> > Because the different vendor properties were rejected by arm-soc > >> > maintainers and the board compatible string was suggested as the > >> > place to put such information. > >> > >> I'm surprised an 80+ character compatible stream is okay. The parts > >> giving me heartburn here are not mentioned in the previous discussion > >> nor the QCDT format. > >> > >> As presented previously I agree with the push back. However, we could > >> do standard properties for SOC and board versions rather than > >> something vendor specific. Then the existing kernel support for > >> versions could use it. We could also just make this compatible string > >> formatting standard for more than just QC boards. > > > > Some standard properties for these things sounds good to me. > > What's the existing kernel support for versions though? Is that > > just compatible string matching, or something else? > > The soc_device stuff (and arm32 cpuinfo has a h/w version). Today I > think users are pulling version info from h/w registers, but if you > don't have h/w registers, then getting it from DT would make sense. Ah ok. The version here is mostly about specifying some minimum version or greater that the dtb matches against. If we were to actually put the real version we may need more blobs for the different combinations of board and SoC versions. So perhaps leaving that in compatible string is the right way to go? > > > >> For mb, can't the tool just parse the memory node to get ram size > >> rather than parsing the compatible. > > > > Sure. Right now the bootloader injects the memory information > > during boot. I think it should work if we already have the memory > > information there. I don't have any usage of mb at the moment > > though, so if you want we can drop this field until a time that > > we need it. > > If the bootloader injects it, then how do you know what to put into > the compatible string? Presumably the bootloader finds the matching size compatible element and then populates the memory info that just happens to match the same size. I don't know if this is happening, but it certainly seems possible to have the same memory size at different starting addresses. So we could simplify that situation by having one size in the compatible that works for either starting address. In summary, I don't > > > With that in mind, right now I'm using fdtget from python to grab > > the compatible string and parse it with a regex. If things need > > to become more complicated to start following phandles, etc. are > > there some python bindings to libfdt somewhere? > > Not that I'm aware of. C is the only language you need. ;) Urgh. I converted dtbtool to python to make it simpler and avoid that compilation step. I guess I'll explore wrapping some calls to the C library inside dtbtool itself for this particular purpose. It would be nice though if I could get a python object for the root of the unflattened dtb that could be iterated and inspected. I'll take a look at doing that sometime. I'm thinking the aliases would be something like this: usid0 = <&pmic0>; usid2 = <&pmic1>; usid4 = <&pmic2>; usid6 = <&pmic3>; We could specify usid1,3,5,7 too, but they're the same as the 0,2,4,6 ones. So far I think all that will change is dropping the mb/panel elements and parsing the PMIC ids from compatible strings and DT traversal. Sounds right? -- 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 devicetree" 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/3] devicetree: bindings: Document qcom board compatible format
On 11/12, Olof Johansson wrote: > On Mon, Oct 26, 2015 at 2:25 PM, Stephen Boyd wrote: > > +Examples: > > + > > + "qcom,msm8916-v1-cdp-pm8916-v2.1" > > This is just awkward, but this... > > > + > > +A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of > > version > > +2.1. > > + > > + > > "qcom,apq8074-v2.0-2-dragonboard/1-v0.1-512MB-panel-qHD-boot-emmc_sdc1-pm8941-v0.2-pm8909-v2.2-pma8084-v3-pm8110-v1" > > ...this is just too much. It makes no sense to try to linearly > describe pretty much the whole hardware in the compatible string like > this when the information should be elsewhere in the DT. > > If this is how it's done, why bother documenting the rest in device > tree at all? Why not just do a depth-first traversal of the DT and > create a string out of that and make that the compatible while you're > at it? Haha. The entire device is just one big compatible string! I love it! Seriously though, once the PMIC stuff appeared I started thinking about some way to detect that dynamically because you're right, it's already in DT somewhere and these huge compatible strings are gross. Using aliases as Rob suggests should work nicely so that we can find most of the elements with some simple tree traversal. In the example above we would be left with apq8074-v2.0-2-dragonboard/1-v0.1. Is that palatable? -- 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 devicetree" 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/3] devicetree: bindings: Document qcom board compatible format
On 11/12, Rob Herring wrote: > On Thu, Nov 12, 2015 at 1:44 PM, Stephen Boyd wrote: > > On 11/12, Rob Herring wrote: > >> On Mon, Oct 26, 2015 at 02:25:10PM -0700, Stephen Boyd wrote: > > >> > +Some qcom based bootloaders identify the dtb blob based on a set of > >> > +device properties like SoC, platform, PMIC, and revisions of those > >> > components. > >> > +To support this scheme, we encode this information into the board > >> > compatible > >> > +string. > >> > >> Why does all this need to be a single property? > > > > Because the different vendor properties were rejected by arm-soc > > maintainers and the board compatible string was suggested as the > > place to put such information. > > I'm surprised an 80+ character compatible stream is okay. The parts > giving me heartburn here are not mentioned in the previous discussion > nor the QCDT format. > > As presented previously I agree with the push back. However, we could > do standard properties for SOC and board versions rather than > something vendor specific. Then the existing kernel support for > versions could use it. We could also just make this compatible string > formatting standard for more than just QC boards. Some standard properties for these things sounds good to me. What's the existing kernel support for versions though? Is that just compatible string matching, or something else? > > >> > + > >> > +The 'soc_version', 'plat_version' and 'pmic_version' elements take the > >> > form of > >> > +v. where the minor number may be omitted when it's zero, > >> > i.e. > >> > +v1.0 is the same as v1. If all versions of the 'plat_version' element's > >> > match, > >> > +then a wildcard '*' should be used, e.g. 'v*'. > >> > + > >> > +The 'foundry_id', 'subtype', and 'mb' elements are one or more digits > >> > from 0 > >> > +to 9. > >> > >> Can you define what these are exactly. I gather mb is RAM size. > > > > Not really, foundry_id is a number and so is subtype. > > For mb, can't the tool just parse the memory node to get ram size > rather than parsing the compatible. Sure. Right now the bootloader injects the memory information during boot. I think it should work if we already have the memory information there. I don't have any usage of mb at the moment though, so if you want we can drop this field until a time that we need it. > > >> > + > >> > +The 'panel' element must be one of the following strings: > >> > + > >> > + 720p > >> > + fWVGA > >> > + hd > >> > + qHD > >> > >> How is this used? > > > > I believe this was added so that we could have different dtbs for > > devices that have different panels on them. I'm not sure this is > > still used though. It could be legacy. > > Dealing with multiple panels is fairly common. I think you could use > an alias to the panel node and match using its compatible or > resolution. So dtbtool will need to resolve the alias and then figure out which type of panel it is from compatible? Ok. I'd rather not write that code unless it's needed, so I hope this field is not used either. > > >> > +The 'boot' element must be one of the following strings: > >> > + > >> > + emmc_sdc1 > >> > + ufs > >> > + > > Again, perhaps an alias would work here. > > >> > +The 'pmic' element must be one of the following strings: > >> > + > >> > + pm8841 > >> > + pm8019 > >> > + pm8110 > >> > + pma8084 > >> > + pmi8962 > >> > + pmd9635 > >> > + pm8994 > >> > + pmi8994 > >> > + pm8916 > >> > + pm8004 > >> > + pm8909 > >> > + > >> > +The 'pmic' element is specified in order of ascending USID. The PMIC in > >> > USID0 > >> > +goes first, and then USID2, USID4, and finally USID6. Up to four PMICs > >> > may be > >> > +specified and no holes in the USID number space are allowed. > >> > >> What is USID? > > > > USID is Unique Slave IDentifier. It's an SPMI concept. > > Okay, then please say "SPMI USID" or something. Ok. In attempts to shorten the compatible string, we could use aliases for the USIDs too. Then it should be possible to pull out the information from the compatible fields of the PMIC nodes to construct the PMIC part of the string. I'd like to avoid having to go down the path of / -> soc -> spmi controller -> usidx,y,z and just go straight to the usid node from a phandle. With that in mind, right now I'm using fdtget from python to grab the compatible string and parse it with a regex. If things need to become more complicated to start following phandles, etc. are there some python bindings to libfdt somewhere? -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] clk: sunxi: Add display clock
On 11/06, Maxime Ripard wrote: > Hi Stephen, > > Thanks for your feedback! > > On Fri, Oct 30, 2015 at 02:29:02PM -0700, Stephen Boyd wrote: > > > + > > > + mux = kzalloc(sizeof(*mux), GFP_KERNEL); > > > + if (!mux) > > [..] > > > + goto free_reset; > > > + } > > > + > > > + return; > > > + > > > +free_reset: > > > + kfree(reset_data); > > > +free_clk: > > > + clk_unregister(clk); > > > > We really ought to have a clk_composite_unregister() API. > > Can we? > > We can always unregister the clock itself, but do we have a way to > retrieve the structure that has been allocated in there? > > (note that it also applies to the generic clocks registration: muxes, > dividers, and so on). Yes we have a way. We've done the same sort of design for other generic clocks. Do the __clk_get_hw() thing like in clk-divider.c -- 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 devicetree" 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/3] devicetree: bindings: Document qcom board compatible format
On 11/12, Rob Herring wrote:
> On Mon, Oct 26, 2015 at 02:25:10PM -0700, Stephen Boyd wrote:
> > Some qcom based bootloaders identify the dtb blob based on a set
> > of device properties like SoC, platform, PMIC, and revisions of
> > those components. In downstream kernels, these values are added
> > to the different component dtsi files (i.e. pmic dtsi file, SoC
> > dtsi file, board dtsi file, etc.) via qcom specific DT
> > properties. The dtb files are parsed by a program called dtbTool
> > that picks out these properties and creates a table of contents
> > binary blob with the property information and some offsets into
> > the concatenation of all the dtbs (termed a QCDT image).
>
> Got a pointer to what these properties look like?
Do you mean the blob header format? You can see that described
in a text document next to the C file for dtbtool[1].
>
> > The suggestion is to do this via the board compatible string
> > instead, because these qcom specific properties are never used by
> > the kernel. Add a document describing the format of the
> > compatible string that encodes all this information that's
> > currently encoded in the qcom,{msm-id,board-id,pmic-id}
> > properties in downstream devicetrees. Future bootloaders may be
> > updated to look at the compatible field instead of looking for
> > the table of contents image. For non-updateable bootloaders, a
> > new dtbTool program will parse the compatible string and generate
> > a QCDT image from it.
> >
> > Signed-off-by: Stephen Boyd
> > ---
> > Documentation/devicetree/bindings/arm/qcom.txt | 86
> > ++
> > 1 file changed, 86 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/qcom.txt
> >
> > diff --git a/Documentation/devicetree/bindings/arm/qcom.txt
> > b/Documentation/devicetree/bindings/arm/qcom.txt
> > new file mode 100644
> > index ..ed084367182d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/qcom.txt
> > @@ -0,0 +1,86 @@
> > +QCOM device tree bindings
> > +-
> > +
> > +Some qcom based bootloaders identify the dtb blob based on a set of
> > +device properties like SoC, platform, PMIC, and revisions of those
> > components.
> > +To support this scheme, we encode this information into the board
> > compatible
> > +string.
>
> Why does all this need to be a single property?
Because the different vendor properties were rejected by arm-soc
maintainers and the board compatible string was suggested as the
place to put such information.
>
> > +Each board must specify a top-level board compatible string with the
> > following
> > +format:
> > +
> > + compatible =
> > "qcom,(-)(-)-(/)(-)(-MB)(--panel)(-boot-)(-(-v)){0-4}"
> > +
> > +where elements in parentheses "()" are optional and elements in brackets
> > "<>"
>
> [] brackets are more generally used for optional params.
Ok. I can make that change.
>
> > +are names of elements. Meaning only the 'SoC' and 'plat_type' elements are
> > +required.
> > +
> > +The 'SoC' element must be one of the following strings:
> > +
> > + apq8016
> > + apq8074
> > + apq8084
> > + apq8096
> > + msm8916
> > + msm8974
> > + msm8996
> > +
> > +The 'plat_type' element must be one of the following strings:
> > +
> > + cdp
> > + liquid
> > + dragonboard
> > + mtp sbc
>
> Platform is pretty overloaded meaning. Perhaps board_type would be more
> clear.
Ok.
>
> > +
> > +The 'soc_version', 'plat_version' and 'pmic_version' elements take the
> > form of
> > +v. where the minor number may be omitted when it's zero, i.e.
> > +v1.0 is the same as v1. If all versions of the 'plat_version' element's
> > match,
> > +then a wildcard '*' should be used, e.g. 'v*'.
> > +
> > +The 'foundry_id', 'subtype', and 'mb' elements are one or more digits from > > 0
> > +to 9.
>
> Can you define what these are exactly. I gather mb is RAM size.
Not really, foundry_id is a number and so is subtype.
>
> > +
> > +The 'panel' element must be one of the following strings:
> > +
> > + 720p
> > + fWVGA
> > + hd
> > + qHD
>
> How is this used?
I believe this was added so that we could have different
Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding
On 11/03, Viresh Kumar wrote: > On 02-11-15, 11:21, Stephen Boyd wrote: > > Ah I see that after looking at the previous thread. Perhaps we > > can add such information into the documentation so that people > > aren't misled into thinking they're limited to 32 bits? > > What about these changes: Yep looks good. Assuming this is squashed into the original: Reviewed-by: Stephen Boyd One typo below. > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt > b/Documentation/devicetree/bindings/opp/opp.txt > index 96892057586a..b6ca2239838b 100644 > --- a/Documentation/devicetree/bindings/opp/opp.txt > +++ b/Documentation/devicetree/bindings/opp/opp.txt > @@ -123,11 +123,15 @@ properties. > - opp-suspend: Marks the OPP to be used during device suspend. Only one OPP > in >the table should have this. > > -- opp-supported-hw: User defined array containing a hierarchy of hardware > - version numbers, supported by the OPP. For example: a platform with > hierarchy > - of three levels of versions (A, B and C), this field should be like Z>, > - where X corresponds to Version hierarchy A, Y corresponds to version > hierarchy > - B and Z corresponds to version hierarchy C. > +- opp-supported-hw: This enables us to select only a subset of OPPs from the > + larger OPP table, based on what version of the hardware we are running on. > We > + still can't have multiple nodes with the same opp-hz value in OPP table. > + > + Its an user defined array containing a hierarchy of hardware version > numbers, s/Its/It's/ -- 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 devicetree" 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/3] PM / OPP: Add "opp-supported-hw" binding
On 11/03, Viresh Kumar wrote:
> On 30-10-15, 15:18, Stephen Boyd wrote:
> > A side-note. I wonder if it would be better style to have the
> > node name be:
> >
> > opp@6 {
> >
> > At least it seems that the assumption is we can store all the
> > possible combinations of OPP values for a particular frequency in
> > the same node. Following this style would make dt compilation
> > fail if two nodes have the same frequency.
>
> From: Viresh Kumar
> Date: Tue, 3 Nov 2015 07:51:09 +0530
> Subject: [PATCH] PM / OPP: Rename OPP nodes as opp@
>
> It would be better to name OPP nodes as opp@ as that will ensure
> that multiple DT nodes don't contain the same frequency. Of course we
> expect the writer to name the node with its opp-hz frequency and not any
> other frequency.
>
> And that will let the compile error out if multiple nodes are using the
> same opp-hz frequency.
>
> Suggested-by: Stephen Boyd
> Signed-off-by: Viresh Kumar
> ---
Reviewed-by: Stephen Boyd
--
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 devicetree" 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/3] PM / OPP: Add "opp-supported-hw" binding
On 10/31, Viresh Kumar wrote: > On 30-10-15, 14:49, Stephen Boyd wrote: > > I suppose if you wanted to have 64 possible combinations of some > > attribute you would just extend it to two 32 bit numbers in > > sequence? I don't see the limitation here, and hopefully there > > isn't a limitation so that we can specify sufficiently large > > numbers with more bits if we need to. > > Yeah, we discussed this earlier when Lee had the same query and I > suggested the exact same thing to him then. > Ah I see that after looking at the previous thread. Perhaps we can add such information into the documentation so that people aren't misled into thinking they're limited to 32 bits? -- 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 devicetree" 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/3] PM / OPP: Add "opp-supported-hw" binding
On 10/31, Viresh Kumar wrote: > On 30-10-15, 15:18, Stephen Boyd wrote: > > > Also, this makes it sound like opp-supported-hw is really just > > telling us if this is a supported frequency or not for the > > particular device we're running on. > > That's right. > > > The current wording makes it > > Of the commit log ? Or the way the nodes are written? The way the documentation is written. -- 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 devicetree" 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/3] PM / OPP: Add "opp-supported-hw" binding
On 10/30, Viresh Kumar wrote:
> + opp_table {
> + compatible = "operating-points-v2";
> + status = "okay";
> + opp-shared;
> +
> + opp00 {
A side-note. I wonder if it would be better style to have the
node name be:
opp@6 {
At least it seems that the assumption is we can store all the
possible combinations of OPP values for a particular frequency in
the same node. Following this style would make dt compilation
fail if two nodes have the same frequency.
Also, this makes it sound like opp-supported-hw is really just
telling us if this is a supported frequency or not for the
particular device we're running on. The current wording makes it
sound like we could have two OPP nodes with the same frequency
but different voltages inside them, which we're trying to
discourage by compressing the tables into less nodes.
I think in Lee's case we're only going to use the cuts parameter
to figure out if the OPP is supported or not. On qcom platforms
we will only use one parameter for this property as well, the
speed bin. The slow/fast and version stuff will be handled by
named opp properties.
> + /*
> + * Supports all substrate and process versions for 0xF
> + * cuts, i.e. only first four cuts.
> + */
> + opp-supported-hw = <0xF 0x 0x>
> + opp-hz = /bits/ 64 <6>;
> + opp-microvolt = <90 915000 925000>;
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] PM / OPP: Remove 'operating-points-names' binding
On 10/30, Viresh Kumar wrote: > These aren't used until now by any DT files and wouldn't be used now as > we have a better scheme in place now, i.e. opp-property- > properties. > > Remove the (useless) binding without breaking ABI. > > Signed-off-by: Viresh Kumar > --- Reviewed-by: Stephen Boyd -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] PM / OPP: Add {opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
On 10/30, Viresh Kumar wrote: > Depending on the version of hardware or its properties, which are only > known at runtime, various properties of the OPP can change. For example, > an OPP with frequency 1.2 GHz, may have different voltage/current > requirements based on the version of the hardware it is running on. > Similarly, it may or may not be a turbo or suspend OPP on those > circumstances. > > In order to not replicate the same OPP tables for varying values of all > such fields, this commit introduces the concept of opp-property-. > The can be chosen by the platform at runtime, and OPPs will be > initialized depending on that name string. Currently support is extended > for the following properties: > - opp-microvolt- > - opp-microamp- > - turbo-mode- > - opp-suspend- > > If the name string isn't provided by the platform, or if it is provided > but doesn't match the properties present in the OPP node, we will fall > back to the original properties without the - string, if they are > available. > > Signed-off-by: Viresh Kumar > --- Reviewed-by: Stephen Boyd -- 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 devicetree" 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/3] PM / OPP: Add "opp-supported-hw" binding
On 10/30, Viresh Kumar wrote: > +- opp-supported-hw: User defined array containing a hierarchy of hardware > + version numbers, supported by the OPP. For example: a platform with > hierarchy > + of three levels of versions (A, B and C), this field should be like Z>, > + where X corresponds to Version hierarchy A, Y corresponds to version > hierarchy > + B and Z corresponds to version hierarchy C. > + > + Each level of hierarchy is represented by a 32 bit value, and so there can > be > + only 32 different supported version per hierarchy. i.e. 1 bit per version. > A > + value of 0x will enable the OPP for all versions for that hierarchy > + level. And a value of 0x will disable the OPP completely, and so we > + never want that to happen. I suppose if you wanted to have 64 possible combinations of some attribute you would just extend it to two 32 bit numbers in sequence? I don't see the limitation here, and hopefully there isn't a limitation so that we can specify sufficiently large numbers with more bits if we need to. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/19] clk: sunxi: Add TCON channel1 clock
On 10/30, Maxime Ripard wrote: > The TCON is a controller generating the timings to output videos signals, > acting like both a CRTC and an encoder. > > It has two channels depending on the output, each channel being driven by > its own clock (and own clock controller). > > Add a driver for the channel 1 clock. > > Signed-off-by: Maxime Ripard Similar comments apply to patches 3 and 4. Was the same code copy/pasted two more times and then changed to have different values? Looks like we should consolidate all that stuff into something more generic so that we don't have the same problems 3 times. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/19] clk: sunxi: Add PLL3 clock
On 10/30, Maxime Ripard wrote:
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index a9e1a5885846..40c32ffd912c 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -9,8 +9,9 @@ obj-y += clk-a10-mod1.o
> obj-y += clk-a10-pll2.o
> obj-y += clk-a20-gmac.o
> obj-y += clk-mod0.o
> -obj-y += clk-sun4i-display.o
> obj-y += clk-simple-gates.o
> +obj-y += clk-sun4i-display.o
Put this in the right place in patch 1 please.
> +obj-y += clk-sun4i-pll3.o
> obj-y += clk-sun8i-mbus.o
> obj-y += clk-sun9i-core.o
> obj-y += clk-sun9i-mmc.o
> diff --git a/drivers/clk/sunxi/clk-sun4i-pll3.c
> b/drivers/clk/sunxi/clk-sun4i-pll3.c
> new file mode 100644
> index ..7ea178bf19fa
> --- /dev/null
> +++ b/drivers/clk/sunxi/clk-sun4i-pll3.c
> @@ -0,0 +1,84 @@
> +/*
> + * Copyright 2015 Maxime Ripard
> + *
> + * Maxime Ripard
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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.
> + */
> +
> +#include
> +#include
#include for of_property_read_string()
> +#include
> +#include
> +
> +#define SUN4I_A10_PLL3_GATE_BIT 31
[...]
> +
> + clk = clk_register_composite(NULL, clk_name,
> + &parent, 1,
> + NULL, NULL,
> + &mult->hw, &clk_factor_ops,
> + &gate->hw, &clk_gate_ops,
> + 0);
> + if (IS_ERR(clk)) {
> + pr_err("%s: Couldn't register the clock\n", clk_name);
> + goto free_mult;
> + }
> +
> + of_clk_add_provider(node, of_clk_src_simple_get, clk);
I hope this doesn't fail.
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] clk: sunxi: Add display clock
On 10/30, Maxime Ripard wrote:
> diff --git a/drivers/clk/sunxi/clk-sun4i-display.c
> b/drivers/clk/sunxi/clk-sun4i-display.c
> new file mode 100644
> index ..f13b095c6d7a
> --- /dev/null
> +++ b/drivers/clk/sunxi/clk-sun4i-display.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright 2015 Maxime Ripard
> + *
> + * Maxime Ripard
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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.
> + */
> +
#include for container_of?
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SUN4I_A10_DISPLAY_PARENTS3
> +
> +#define SUN4I_A10_DISPLAY_GATE_BIT 31
> +#define SUN4I_A10_DISPLAY_RESET_BIT 30
> +#define SUN4I_A10_DISPLAY_MUX_MASK 3
> +#define SUN4I_A10_DISPLAY_MUX_SHIFT 24
> +#define SUN4I_A10_DISPLAY_DIV_WIDTH 4
> +#define SUN4I_A10_DISPLAY_DIV_SHIFT 0
> +
> +struct reset_data {
> + void __iomem*reg;
> + spinlock_t *lock;
> + struct reset_controller_dev rcdev;
> +};
> +
> +static DEFINE_SPINLOCK(sun4i_a10_display_lock);
> +
> +static int sun4i_a10_display_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct reset_data *data = container_of(rcdev,
> +struct reset_data,
> +rcdev);
Can this be a macro rcdev_to_reset_data() or something?
> + unsigned long flags;
[..]
> +
> +static int sun4i_a10_display_status(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct reset_data *data = container_of(rcdev,
> +struct reset_data,
> +rcdev);
> +
> + return !(readl(data->reg) & BIT(SUN4I_A10_DISPLAY_RESET_BIT));
> +}
> +
> +static struct reset_control_ops sun4i_a10_display_reset_ops = {
Someone should make it so this can be const...
> + .assert = sun4i_a10_display_assert,
> + .deassert = sun4i_a10_display_deassert,
> + .status = sun4i_a10_display_status,
> +};
> +
> +static int sun4i_a10_display_reset_xlate(struct reset_controller_dev *rcdev,
> + const struct of_phandle_args *spec)
> +{
> + if (WARN_ON(spec->args_count != rcdev->of_reset_n_cells))
> + return -EINVAL;
Do we really need this check? Seems like something the reset core
should handle.
> +
> + /* We only have a single reset signal */
> + return 0;
> +}
> +
> +static void __init sun4i_a10_display_setup(struct device_node *node)
> +{
> + const char *parents[SUN4I_A10_DISPLAY_PARENTS];
> + const char *clk_name = node->name;
> + struct reset_data *reset_data;
> + struct clk_divider *div;
> + struct clk_gate *gate;
> + struct clk_mux *mux;
> + void __iomem *reg;
> + struct clk *clk;
> + int i;
> +
> + of_property_read_string(node, "clock-output-names", &clk_name);
> +
> + reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> + if (IS_ERR(reg)) {
> + pr_err("%s: Could not map the clock registers\n", clk_name);
> + return;
> + }
> +
> + for (i = 0; i < SUN4I_A10_DISPLAY_PARENTS; i++)
> + parents[i] = of_clk_get_parent_name(node, i);
of_clk_parent_fill()?
> +
> + mux = kzalloc(sizeof(*mux), GFP_KERNEL);
> + if (!mux)
[..]
> + goto free_reset;
> + }
> +
> + return;
> +
> +free_reset:
> + kfree(reset_data);
> +free_clk:
> + clk_unregister(clk);
We really ought to have a clk_composite_unregister() API.
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding
On 10/28, Mark Brown wrote: > On Tue, Oct 27, 2015 at 01:49:17PM +0530, Viresh Kumar wrote: > > On 23-10-15, 01:39, Mark Brown wrote: > > > > I'm not sure that's > > > a place we want to end up just yet, I think it's safer to just have a > > > little bit of code in the kernel that glues things together in the cases > > > where this is needed. > > > So you are effectively saying that we shouldn't go ahead with multi > > regulator support in OPP library, right? > > Well, I think things like libraries for getting the data tables out of > DT are fine but I'm not convinced that trying to avoid having any device > specific code at all is sufficiently clear yet - as far as I know we're > mostly looking at a fairly small subset of devices still and with things > like sequencing in the mix it's a bit worrying to me to be putting it > all into an ABI intended to be used with no knowledge of the platform. Agreed. Looking at the current oppv2 binding I'm confused how it even works. It shows cpu-supply = <&phandle1>, <&phandle2>, etc. which doesn't work with the regulator bindings design. It seems that Viresh figured that out when implementing support for multiple regulators, so the binding was changed to put names in the opp tables and then use that to get regulators in the opp core. Urgh. I think I understand the goal here though. The goal is to move all the clk_get()/regulator_get() and clock and regulator API interactions into the OPP framework so that we can say "go to OPP at index 4" from the cpufreq core and the OPP framework takes care of actually doing the transition. Given that doing such a transition could be very machine specific, we probably ought to make the OPP framework flexible enough to let us decide how to do that. Perhaps we need to expand on the compatible string in the opp node to have compatible = "vendor,cool-transition", "operating-points-v2"? Then we can plug in vendor specific drivers that handle the frequency/voltage transition and they'll know that the fourth column in the voltage entry corresponds to this particular device's foo-supply and in what order to change voltages. A generic driver could exist for the simple case of one regulator and one clock that matches on "operating-points-v2". Or we can avoid doing any clk_get()/regulator_get() stuff inside the OPP framework, and let OPP consumers tell the OPP framework about each clock and regulator it wants the framework to manage on the consumer's behalf. It could even tell the framework which regulator corresponds to which voltage column and in what order to change the voltages so that the OPP framework doesn't need to know these device specific details. Then the consumer can still say go to OPP level 4 and that all works without introducing some new DT ABI. -- 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 devicetree" 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 0/3] clk: Broadcom BCM63138 support
On 10/26, Florian Fainelli wrote:
> Hi all,
>
> This patch series adds support for the Broadcom BCM63138 DSL SoCs
> clocking framework.
>
> Since the HW is identical to the one found in Broadcom iProc SoCs, but the
> integration is different (obviously), there is still a new compatible string
> introduced just in case we happen to find issues in the future.
>
> This applies on top of clk/next as of
> 679c51cffc3b316bd89ecc91ef92603dd6d4fc68 ("clk: Add stubs for of_clk_*() APIs
> when CONFIG_OF=n")
>
> Since there is an obvious dependency between patch 2 and 3, we can either
> merge this through the Clock tree or via a future arm-soc pull requests
> for Broadcom SoCs.
One way to avoid the dependency would be to stage the first two
patches in clk tree under clk-bcm63xxx and then pull that into
your local branch via git FETCH && git checkout FETCH_HEAD and
then apply the 3rd patch on top, tag it and send it off to
arm-soc. This way, when arm-soc merges into linus' tree the
dependency is taken care of and we don't take anything for dtsi
files through the clk tree. It looks like nothing bad will happen
if patch 2 is merged before patch 3.
--
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 devicetree" 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 2/3] clk: bcm: Add BCM63138 clock support
On 10/27, Florian Fainelli wrote: > On 27/10/15 10:46, Stephen Boyd wrote: > > On 10/26, Florian Fainelli wrote: > >> diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig > >> index 85260fb96b36..a0c18528b70d 100644 > >> --- a/drivers/clk/bcm/Kconfig > >> +++ b/drivers/clk/bcm/Kconfig > >> @@ -1,3 +1,13 @@ > >> +config CLK_BCM_63XX > >> + bool "Broadcom BCM63xx clock support" > >> + depends on ARCH_BCM_63XX || COMPILE_TEST > >> + depends on COMMON_CLK > >> + select COMMON_CLK_IPROC > >> + default y > > > > perhaps default CLK_BCM_63XX? > > Did you mean default ARCH_BCM_63XX instead? > Yes. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] EDAC: Add ARM64 EDAC
On 10/27, Brijesh Singh wrote:
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index ef25000..84507b5 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -390,4 +390,12 @@ config EDAC_XGENE
> Support for error detection and correction on the
> APM X-Gene family of SOCs.
>
> +config EDAC_CORTEX_ARM64
> + tristate "ARM Cortex A57/A53"
> + depends on EDAC_MM_EDAC && ARM64
> + default n
n is the default so this can be removed.
> + help
> + Support for error detection and correction on the
> + ARM Cortex A57 and A53.
> +
> endif # EDAC
> diff --git a/drivers/edac/cortex_arm64_edac.c
> b/drivers/edac/cortex_arm64_edac.c
> new file mode 100644
> index 000..7c936b66
> --- /dev/null
> +++ b/drivers/edac/cortex_arm64_edac.c
> +
> +static struct platform_driver cortex_arm64_edac_driver = {
> + .probe = cortex_arm64_edac_probe,
> + .remove = cortex_arm64_edac_remove,
> + .driver = {
> + .name = DRV_NAME,
> + .owner = THIS_MODULE,
This line can be removed. THIS_MODULE is assigned by
platform_driver_register().
> + .of_match_table = cortex_arm64_edac_of_match,
> + },
> +};
> +
> +static int __init cortex_arm64_edac_init(void)
> +{
> + return platform_driver_register(&cortex_arm64_edac_driver);
> +}
> +module_init(cortex_arm64_edac_init);
> +
> +static void __exit cortex_arm64_edac_exit(void)
> +{
> + platform_driver_unregister(&cortex_arm64_edac_driver);
> +}
> +module_exit(cortex_arm64_edac_exit);
This can be module_platform_driver(cortex_arm64_edac_driver) now.
--
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 devicetree" 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 2/3] clk: bcm: Add BCM63138 clock support
On 10/26, Florian Fainelli wrote:
> diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
> index 85260fb96b36..a0c18528b70d 100644
> --- a/drivers/clk/bcm/Kconfig
> +++ b/drivers/clk/bcm/Kconfig
> @@ -1,3 +1,13 @@
> +config CLK_BCM_63XX
> + bool "Broadcom BCM63xx clock support"
> + depends on ARCH_BCM_63XX || COMPILE_TEST
> + depends on COMMON_CLK
> + select COMMON_CLK_IPROC
> + default y
perhaps default CLK_BCM_63XX?
> + help
> + Enable common clock framework support for Broadcom BCM63xx DSL SoCs
> + based on the ARM architecture
> +
> config CLK_BCM_KONA
> bool "Broadcom Kona CCU clock support"
> depends on ARCH_BCM_MOBILE || COMPILE_TEST
> diff --git a/drivers/clk/bcm/clk-bcm63xx.c b/drivers/clk/bcm/clk-bcm63xx.c
> new file mode 100644
> index ..b7e0469d0522
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-bcm63xx.c
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 2015 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include
> +#include
> +#include
#include ?
I'm not sure what the kernel.h include is for.
> +#include "clk-iproc.h"
> +
> +static void __init bcm63138_armpll_init(struct device_node *node)
> +{
> + iproc_armpll_setup(node);
> +}
> +CLK_OF_DECLARE(bcm63138_armpll, "brcm,bcm63138-armpll",
> bcm63138_armpll_init);
> --
> 2.1.0
>
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13 v2] clk: add ARM syscon ICST device tree bindings
On 10/26, Linus Walleij wrote: > This adds the device tree bindings for the ARM Syscon ICST > oscillators, which is a register-level interface to the > Integrated Device Technology (IDT) ICS525 and ICS307 > serially programmable oscillators. > > Cc: devicetree@vger.kernel.org > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: linux-...@vger.kernel.org > Signed-off-by: Linus Walleij > --- Acked-by: Stephen Boyd -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Remove the need for qcom,{msm-id,board-id,pmic-id}
This patchset documents a compatible string format that encodes all the information that was being encoded in qcom specific DT properties in downstream msm kernels. The goal being to come up with a format that will allow us to express the information we want to express without requiring the use of vendor specific properties. An updated dtbTool will be released after these new bindings are accepted so that users can work with non-updateable bootloaders. This is an attempt to resolve a discussion around March of this year[1] where the arm-soc maintainers suggested we express this information through the board's compatible string. [1] http://lkml.kernel.org/g/1425503602-24916-1-git-send-email-ga...@codeaurora.org Stephen Boyd (3): devicetree: bindings: Document qcom board compatible format arm64: dts: qcom: Make msm8916-mtp compatible string compliant arm: dts: qcom: Update ifc6540 compat for qcom boot format Documentation/devicetree/bindings/arm/qcom.txt | 86 ++ arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 2 +- arch/arm64/boot/dts/qcom/msm8916-mtp.dts | 2 +- 3 files changed, 88 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/qcom.txt -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] arm64: dts: qcom: Make msm8916-mtp compatible string compliant
This compatible string isn't compliant with the format for
subtypes. Replace it with a compliant compatible type.
Signed-off-by: Stephen Boyd
---
arch/arm64/boot/dts/qcom/msm8916-mtp.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
index fced77f0fd3a..b0a064d3806b 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
@@ -17,6 +17,6 @@
/ {
model = "Qualcomm Technologies, Inc. MSM 8916 MTP";
- compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp-smb1360",
+ compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp/1",
"qcom,msm8916", "qcom,mtp";
};
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] devicetree: bindings: Document qcom board compatible format
Some qcom based bootloaders identify the dtb blob based on a set
of device properties like SoC, platform, PMIC, and revisions of
those components. In downstream kernels, these values are added
to the different component dtsi files (i.e. pmic dtsi file, SoC
dtsi file, board dtsi file, etc.) via qcom specific DT
properties. The dtb files are parsed by a program called dtbTool
that picks out these properties and creates a table of contents
binary blob with the property information and some offsets into
the concatenation of all the dtbs (termed a QCDT image).
The suggestion is to do this via the board compatible string
instead, because these qcom specific properties are never used by
the kernel. Add a document describing the format of the
compatible string that encodes all this information that's
currently encoded in the qcom,{msm-id,board-id,pmic-id}
properties in downstream devicetrees. Future bootloaders may be
updated to look at the compatible field instead of looking for
the table of contents image. For non-updateable bootloaders, a
new dtbTool program will parse the compatible string and generate
a QCDT image from it.
Signed-off-by: Stephen Boyd
---
Documentation/devicetree/bindings/arm/qcom.txt | 86 ++
1 file changed, 86 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/qcom.txt
diff --git a/Documentation/devicetree/bindings/arm/qcom.txt
b/Documentation/devicetree/bindings/arm/qcom.txt
new file mode 100644
index ..ed084367182d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom.txt
@@ -0,0 +1,86 @@
+QCOM device tree bindings
+-
+
+Some qcom based bootloaders identify the dtb blob based on a set of
+device properties like SoC, platform, PMIC, and revisions of those components.
+To support this scheme, we encode this information into the board compatible
+string.
+
+Each board must specify a top-level board compatible string with the following
+format:
+
+ compatible =
"qcom,(-)(-)-(/)(-)(-MB)(--panel)(-boot-)(-(-v)){0-4}"
+
+where elements in parentheses "()" are optional and elements in brackets "<>"
+are names of elements. Meaning only the 'SoC' and 'plat_type' elements are
+required.
+
+The 'SoC' element must be one of the following strings:
+
+ apq8016
+ apq8074
+ apq8084
+ apq8096
+ msm8916
+ msm8974
+ msm8996
+
+The 'plat_type' element must be one of the following strings:
+
+ cdp
+ liquid
+ dragonboard
+ mtp sbc
+
+
+The 'soc_version', 'plat_version' and 'pmic_version' elements take the form of
+v. where the minor number may be omitted when it's zero, i.e.
+v1.0 is the same as v1. If all versions of the 'plat_version' element's match,
+then a wildcard '*' should be used, e.g. 'v*'.
+
+The 'foundry_id', 'subtype', and 'mb' elements are one or more digits from 0
+to 9.
+
+The 'panel' element must be one of the following strings:
+
+ 720p
+ fWVGA
+ hd
+ qHD
+
+The 'boot' element must be one of the following strings:
+
+ emmc_sdc1
+ ufs
+
+The 'pmic' element must be one of the following strings:
+
+ pm8841
+ pm8019
+ pm8110
+ pma8084
+ pmi8962
+ pmd9635
+ pm8994
+ pmi8994
+ pm8916
+ pm8004
+ pm8909
+
+The 'pmic' element is specified in order of ascending USID. The PMIC in USID0
+goes first, and then USID2, USID4, and finally USID6. Up to four PMICs may be
+specified and no holes in the USID number space are allowed.
+
+Examples:
+
+ "qcom,msm8916-v1-cdp-pm8916-v2.1"
+
+A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version
+2.1.
+
+
"qcom,apq8074-v2.0-2-dragonboard/1-v0.1-512MB-panel-qHD-boot-emmc_sdc1-pm8941-v0.2-pm8909-v2.2-pma8084-v3-pm8110-v1"
+
+A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
+foundry 2 with 512MB of memory and a qHD panel booting from emmc_sdc1, paired
+with a pm8941 PMIC version 0.2 at USID0, pm8909 PMIC version 2.2 at USID2,
+pma8084 version 3 at USID4 and a pm8110 version 1 at USID6.
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] arm: dts: qcom: Update ifc6540 compat for qcom boot format
The ifc6540 is an sbc (single board computer) board, so update
the compatible field accordingly.
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
index c9c2b769554f..32aaa9d45228 100644
--- a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
+++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
@@ -3,7 +3,7 @@
/ {
model = "Qualcomm APQ8084/IFC6540";
- compatible = "qcom,apq8084-ifc6540", "qcom,apq8084";
+ compatible = "qcom,apq8084-sbc", "qcom,apq8084";
aliases {
serial0 = &blsp2_uart2;
--
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 devicetree" 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 5/5] [RFC] clk: shmobile: r8a7795: Add new CPG/MSSR driver
On 10/22, Geert Uytterhoeven wrote: > Hi Mike, > > On Tue, Oct 20, 2015 at 3:07 PM, Geert Uytterhoeven > wrote: > > On Tue, Oct 20, 2015 at 3:00 PM, Michael Turquette > > wrote: > >> Quoting Geert Uytterhoeven (2015-10-20 05:31:12) > >>> On Tue, Oct 20, 2015 at 2:24 PM, Michael Turquette > >>> wrote: > > > >> The bindings should go in for 4.4, but if the driver is slated for 4.5 > >> then can you investigate this some more? Stephen and I are on a mission > >> to have _real_ clk drivers. > > > > Sure, I'll have a deeper look. > > And so I did (on r8a7791/koelsch). > > As I want to have as much clock data/code __init as possible (think > multi-platform kernels --- pinmux data is a disaster here), I have to use > platform_driver_probe(). > > - Calling platform_driver_probe() from core_initcall() or > postcore_initcall() > is too early, as the platform device for the CPG hasn't been created yet. > Hence the CPG Clock Domain isn't registered, and all devices fail to probe > as they can't be attached to their Clock Domain. > -> This is where the -ENOENT came from (I incorrectly assumed it came > from the clock code; sorry for that), and it's converted into > -EPROBE_DEFER by genpd_dev_pm_attach(). > > - Calling platform_driver_probe() from arch_initcall() is too late, as the > IRQC is initialized first (it's located before the CPG in .dtsi). > Hence the IRQC can't find it's Clock Domain, and its probe is deferred. > IRQC will be reprobed later, but in the mean time the Ethernet PHY can't > find its IRQ, as the of_mdio code uses irq_of_parse_and_map(), which > plainly ignores EPROBE_DEFER :-( > Nevertheless, Ethernet works... > > - Using subsys_initcall() and later causes even more probe deferral. > > So that's why I went with CLK_OF_DECLARE() again... > Understandable for the few clocks that are used by the interrupt controller, but for the other clocks, could those be registered from a real platform device driver probe path? I've been considering making some API that lets devices associate with the clocks that the file had to register with CLK_OF_DECLARE(). The driver would have to be builtin then (no modules) but otherwise we would be able to benefit from the device driver model for most other clocks. -- 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 devicetree" 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] EDAC: Add ARM64 EDAC
Drive by nitpicks
On 10/21, Brijesh Singh wrote:
> diff --git a/drivers/edac/cortex_arm64_edac.c
> b/drivers/edac/cortex_arm64_edac.c
> new file mode 100644
> index 000..c37bb94
> --- /dev/null
> +++ b/drivers/edac/cortex_arm64_edac.c
> +
> +#define L1_CACHE 0
> +#define L2_CACHE 1
> +
> +int poll_msec = 100;
static?
> +
> +struct cortex_arm64_edac {
> + struct edac_device_ctl_info *edac_ctl;
> +};
[..]
> +
> +static int cortex_arm64_edac_probe(struct platform_device *pdev)
> +{
> + int rc;
> + struct cortex_arm64_edac *drv;
> + struct device *dev = &pdev->dev;
> +
> + drv = devm_kzalloc(dev, sizeof(*drv), GFP_KERNEL);
> + if (!drv)
> + return -ENOMEM;
> +
> + drv->edac_ctl = edac_device_alloc_ctl_info(0, "cpu",
> +num_possible_cpus(), "L", 2,
> +1, NULL, 0,
> +edac_device_alloc_index());
> + if (IS_ERR(drv->edac_ctl))
> + return -ENOMEM;
> +
> + drv->edac_ctl->poll_msec = poll_msec;
> + drv->edac_ctl->edac_check = arm64_monitor_cache_errors;
> + drv->edac_ctl->dev = dev;
> + drv->edac_ctl->mod_name = dev_name(dev);
> + drv->edac_ctl->dev_name = dev_name(dev);
> + drv->edac_ctl->ctl_name = "cpu_err";
> + drv->edac_ctl->panic_on_ue = 1;
> + platform_set_drvdata(pdev, drv);
> +
> + rc = edac_device_add_device(drv->edac_ctl);
> + if (rc)
> + goto edac_alloc_failed;
> +
> + return 0;
> +
> +edac_alloc_failed:
> + edac_device_free_ctl_info(drv->edac_ctl);
> + return rc;
Simplify to:
rc = edac_device_add_device(...
if (rc)
edac_device_free_ctl_info(..
return rc;
> +}
> +
> +
> +static const struct of_device_id cortex_arm64_edac_of_match[] = {
> + { .compatible = "arm,armv8-edac" },
> + {},
Dropping the comma here is good style because it forces us to add
a comma if we were to add an element after the sentinel,
hopefully causing us to question why we're doing that in the
first place.
> +};
> +MODULE_DEVICE_TABLE(of, cortex_arm64_edac_of_match);
> +
> +static struct platform_driver cortex_arm64_edac_driver = {
> + .probe = cortex_arm64_edac_probe,
> + .remove = cortex_arm64_edac_remove,
> + .driver = {
> + .name = "arm64-edac",
> + .owner = THIS_MODULE,
platform_driver_register() sets this so we can drop this
assignment here.
> + .of_match_table = cortex_arm64_edac_of_match,
> + },
> +};
> +
> +static int __init cortex_arm64_edac_init(void)
> +{
> + int rc;
> +
> + /* Only POLL mode is supported so far */
> + edac_op_state = EDAC_OPSTATE_POLL;
> +
> + rc = platform_driver_register(&cortex_arm64_edac_driver);
> + if (rc) {
> + edac_printk(KERN_ERR, EDAC_MOD_STR, "failed to register\n");
> + return rc;
> + }
> +
> + return 0;
This could be simplified to
rc = ...
if (rc)
edac_printk(...
return rc;
Or even just 'return platform_driver_register()' and not care
about printing a message in that case because the end-user can't
do anything with the message anyway.
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13 v2] clk: add ARM syscon ICST device tree bindings
On 10/23, Linus Walleij wrote: > This adds the device tree bindings for the ARM Syscon ICST > oscillators, which is a register-level interface to the > Integrated Device Technology (IDT) ICS525 and ICS307 > serially programmable oscillators. > > Cc: devicetree@vger.kernel.org > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: linux-...@vger.kernel.org > Signed-off-by: Linus Walleij > --- Acked-by: Stephen Boyd -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13] clk: add ARM syscon ICST device tree bindings
On 10/23, Linus Walleij wrote: > On Thu, Oct 15, 2015 at 9:23 PM, Stephen Boyd wrote: > > On 10/15, Linus Walleij wrote: > > >> +Required properties: > >> +- lock-offset: the offset address into the system controller where the > >> + unlocking register is located > >> +- vco-offset: the offset address into the system controller where the > >> + ICST control register is located (even 32 bit address) > > > > Is there any reason why we don't use a reg property for this? > > Usually reg = <> is used with two (or more) tokens: > > reg = ; > > The exception being things like I2C addresses which > are just one token. > > Since in this case, there is a "mother" reg property in the > syscon-compatible node, which we are indexing into, > it is confusing to use the same name for subnodes. > > Also there is a bunch of precedents doing it like this > for sybdevices to system controllers, just > git grep offset Documentation/devicetree/bindings > will give you a bunch of them. > Ok. I'm no DT expert, but it seems odd to have subnodes without a reg property. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/10] clk: iproc: define Broadcom NSP iProc clock binding
On 10/15, Jon Mason wrote: > Document the device tree bindings for Broadcom Northstar Plus > architecture based clock controller > > Signed-off-by: Jon Mason > --- Applied to clk-iproc -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/10] clk: iproc: define Broadcom NS2 iProc clock binding
On 10/15, Jon Mason wrote: > Document the device tree bindings for Broadcom Northstar 2 architecture > based clock controller > > Signed-off-by: Jon Mason > --- Applied to clk-iproc -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC
On 10/15, Jon Mason wrote: > The Broadcom Northstar 2 SoC is architected under the iProc > architecture. It has the following PLLs: GENPLL SCR, GENPLL SW, > LCPLL DDR, LCPLL Ports, all derived from an onboard crystal. > > Signed-off-by: Jon Mason > --- Applied to clk-iproc -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC
On 10/15, Scott Branden wrote: > On 15-10-15 02:15 PM, Ray Jui wrote: > >On 10/15/2015 2:10 PM, Jon Mason wrote: > >>On Thu, Oct 15, 2015 at 02:04:09PM -0700, Scott Branden wrote: > >>>On 15-10-15 01:55 PM, Ray Jui wrote: > On 10/15/2015 1:40 PM, Scott Branden wrote: > > If using CONFIG_CLK_NS2, how is it going to be enabled/selected? > >>> > >>>Since CONFIG_ARCH_BCM_NS2 isn't "allowed" to be introduced we will > >>>need to create and select a CONFIG_CLK_BCM_NS2 in the defconfig > >>>instead. > >> > >>Is this better than the binary becoming slightly bigger? I thought > >>the extra complexity was worse than having an unused chunk of clk code > >>(and Kona is already doing the same thing above). I believe Ray was > >>in agreement with me during the internal review of this code. > >> > >>Thanks, > >>Jon > >> > > > >Yes, I'm okay with leaving it as it is. I even prefer changing the > >current Makefile to make all iProc based core clock drivers and SoC > >specific clock tables under CONFIG_COMMON_CLK_IPROC, which is what some > >of the other vendors do. > > > I'd leave it exactly as is then rather than pulling in more dead > code when not needed. This ns2 clock code is very minor compared to > other code bloat in the kernel and drivers. We should really make these visible options that can be selected by anyone. Having selects in the ARCH config area is simple, but also has some downsides: 1) select is a reverse dependency and is hard for people to understand and can sometimes be a pain to track down 2) build coverage goes down because configs are hidden 3) we get code bloat like is being discussed here So I'd really like to see someone take a good look at this whole Makefile situation that's going on and clean it up so that they're user visible options and then throw the config options into the defconfig. It isn't going to block this series, but it would be nice to do at some later point. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 07/10] clk: iproc: Separate status and control variables
On 10/15, Jon Mason wrote: > Some PLLs have separate registers for Status and Control. The means the > pll_base needs to be split into 2 new variables, so that those PLLs can > specify device tree registers for those independently. Also, add a new > driver flag to identify this presence of the split, and let the driver > know that additional registers need to be used. > > Signed-off-by: Jon Mason > --- Applied to clk-iproc -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/10] clk: iproc: Split off dig_filter
On 10/15, Jon Mason wrote: > The PLL loop filter/gain can be located in a separate register on some > SoCs. Split these off into a separate variable, so that an offset can > be added if necessary. Also, make the necessary modifications to the > Cygnus and NSP drivers for this change. > > Signed-off-by: Jon Mason > --- Applied to clk-iproc -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/10] clk: nsp: add clock support for Broadcom Northstar Plus SoC
On 10/15, Jon Mason wrote: > The Broadcom Northstar Plus SoC is architected under the iProc > architecture. It has the following PLLs: ARMPLL, GENPLL, LCPLL0, all > derived from an onboard crystal. > > Signed-off-by: Jon Mason > --- Applied to clk-iproc -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/10] clk: iproc: add support for BCM NS, NSP, and NS2
On 10/15, Jon Mason wrote: > > v3 - Added a patch to fix cygnus clk link failures, and added back the > DT documentation patches that were removed from v2. > > v2 - Added a patch to change the Cygnus clk macros to uppercase, > removed the device tree changes from the series (will send out those as > an RFC), and other minor changes that Stephen Boyd requested. > > This patch series adds support for the Broadcom Northstar, Northstar > Plus, and Northstar 2 clocks. Some slight modifications were necessary > to clk-iproc-pll to get Northstar and Northstar Plus working, due to > differences in register layout. This is the reason why the first patch > is necessary. Some more modifications were necessary to clk-iproc-pll > to get Northstar 2 working, due to differences in register layout (and > resulting fallout in Cygnus and NSP). This is the reason why the sixth > and seventh patches are necessary. The fifth patch is clean-up to > prevent accidentally forgetting to adjust for the base write errata > (which happened a few times, but was caught in internal review). > Can you please use git cover-letter format where the diffstat for the series is shown? Without that information here I started applying patches until I realized this added dt-bindings headers, thus probably needing some stable clk branch to pull into arm-soc. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 03/10] clk: iproc: Add PWRCTRL support
On 10/15, Jon Mason wrote:
> Some iProc SoC clocks use a different way to control clock power, via
> the PWRDWN bit in the PLL control register. Since the PLL control
> register is used to access the PWRDWN bit, there is no need for the
> pwr_base when this is being used. A new flag, IPROC_CLK_EMBED_PWRCTRL,
> has been added to identify this usage. We can use the AON interface to
> write the values to enable/disable PWRDOWN.
>
> Signed-off-by: Jon Mason
> ---
Applied to clk-next +
---8<
diff --git a/drivers/clk/bcm/clk-iproc-pll.c b/drivers/clk/bcm/clk-iproc-pll.c
index 61b49ba24602..fb1e6b1d0df6 100644
--- a/drivers/clk/bcm/clk-iproc-pll.c
+++ b/drivers/clk/bcm/clk-iproc-pll.c
@@ -150,7 +150,7 @@ static void __pll_disable(struct iproc_pll *pll)
if (ctrl->flags & IPROC_CLK_EMBED_PWRCTRL) {
val = readl(pll->pll_base + ctrl->aon.offset);
- val |= (bit_mask(ctrl->aon.pwr_width) << ctrl->aon.pwr_shift);
+ val |= bit_mask(ctrl->aon.pwr_width) << ctrl->aon.pwr_shift;
writel(val, pll->pll_base + ctrl->aon.offset);
if (unlikely(ctrl->flags & IPROC_CLK_NEEDS_READ_BACK))
@@ -160,7 +160,7 @@ static void __pll_disable(struct iproc_pll *pll)
if (pll->pwr_base) {
/* latch input value so core power can be shut down */
val = readl(pll->pwr_base + ctrl->aon.offset);
- val |= (1 << ctrl->aon.iso_shift);
+ val |= 1 << ctrl->aon.iso_shift;
writel(val, pll->pwr_base + ctrl->aon.offset);
/* power down the core */
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/10] clk: cygnus: Convert all macros to all caps
On 10/15, Jon Mason wrote: > The macros that are being used to initialize the values of the clk > structures should be all caps. Find and replace all of them with their > relevant counterparts. > > Signed-off-by: Jon Mason > --- Applied to clk-next -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/10] ARM: cygnus: fix link failures when CONFIG_COMMON_CLK_IPROC is disabled
On 10/15, Jon Mason wrote: > diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig > index 88febf5..46ee475 100644 > --- a/drivers/clk/bcm/Kconfig > +++ b/drivers/clk/bcm/Kconfig > @@ -9,10 +9,8 @@ config CLK_BCM_KONA > in the BCM281xx and BCM21664 families. > > config COMMON_CLK_IPROC > - bool "Broadcom iProc clock support" > - depends on ARCH_BCM_IPROC Another patch added COMPILE_TEST here, so I've removed COMPILE_TEST now. Applied to clk-next. -- 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 devicetree" 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/3] clk: samsung: exynos4: Add SSS gate clock
On 10/19, Krzysztof Kozlowski wrote: > Add a gate clock for controlling all clocks of Security Sub System > (SSS). > > Signed-off-by: Krzysztof Kozlowski > --- The To: list is huge, so I have no idea if you want me to apply this patch or not, and given that it's part of a series that has dts changes I guess that means it should go through arm-soc: Acked-by: Stephen Boyd -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 4/5] clk: iproc: define Broadcom NS2 iProc clock binding
On 10/14, Ray Jui wrote: > > > On 10/14/2015 8:44 AM, Jon Mason wrote: > > On Tue, Oct 13, 2015 at 03:24:52PM -0700, Ray Jui wrote: > >> Same as this patch. I thought device tree binding document should go > >> with the clock driver changes. > >> > >> Strictly speaking, device tree binding document should always go before > >> the driver changes. In the binding document the DT interface is defined, > >> then changes are implemented in the driver. > > > > I split them off this way due to the clk maintainer not wanting to > > pull in any device tree changes. Since the documentation is for the > > device tree enties, it makes logical sense to me that they be in the > > same device tree series. If Stephen will pull these in with the clk > > changes, I am more than happy to have it done by him :) > > > > Thanks, > > Jon > > Yeah the clock maintainers do not pull in device tree changes like > *.dtsi and *.dts. But they do take changes including the binding > documents and clock driver changes. You can confirm with Stephen. > Yes we take bindings (I know I'm replying to an old patch). -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] clk: rockchip: Add sclk_mipidsi_24m for mipi dsi
On 10/10, Chris Zhong wrote:
> sclk_mipidsi_24m is the gating of mipi dsi phy.
>
> Signed-off-by: Chris Zhong
> ---
Acked-by: Stephen Boyd
>
> drivers/clk/rockchip/clk-rk3288.c | 2 +-
> include/dt-bindings/clock/rk3288-cru.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3288.c
> b/drivers/clk/rockchip/clk-rk3288.c
> index 9040878..c7d7ebf 100644
> --- a/drivers/clk/rockchip/clk-rk3288.c
> +++ b/drivers/clk/rockchip/clk-rk3288.c
> @@ -709,7 +709,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
> __initdata = {
> GATE(SCLK_LCDC_PWM1, "sclk_lcdc_pwm1", "xin24m", 0,
> RK3288_CLKGATE_CON(13), 11, GFLAGS),
> GATE(SCLK_PVTM_CORE, "sclk_pvtm_core", "xin24m", 0,
> RK3288_CLKGATE_CON(5), 9, GFLAGS),
> GATE(SCLK_PVTM_GPU, "sclk_pvtm_gpu", "xin24m", 0,
> RK3288_CLKGATE_CON(5), 10, GFLAGS),
> - GATE(0, "sclk_mipidsi_24m", "xin24m", 0, RK3288_CLKGATE_CON(5), 15,
> GFLAGS),
> + GATE(SCLK_MIPI_24M, "sclk_mipidsi_24m", "xin24m", 0,
> RK3288_CLKGATE_CON(5), 15, GFLAGS),
>
It would have been better to make #defines for all these clocks
even if they weren't going to be used here. Then we could have
applied this patch directly to clk tree without having a clk tree
to arm-soc dependency.
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding
On 10/16, Viresh Kumar wrote: > On 15-10-15, 17:22, Stephen Boyd wrote: > > I'm lost why we need this property at all. What happened to using > > > > opp-microvolt-0 = <1 2 3>; > > opp-microvolt-1 = <1>; > > opp-microvolt-2 = <3 4 5>; > > etc. > > Perhaps you are confusing this with the bindings we came up for > picking right voltage levels based on the cuts/version of the hardware > we are running on. The problem that Lee Jones mentioned and that can > be used in your case as well. Isn't that what this patch series is for? > > > That seems to avoid any problem with 3 vs. 1 element properties > > combined into one large array. > > That's not the problem I was trying to solve here. What problem are you trying to solve then? > > > Having supply-names seems too > > brittle and would tie us to a particular OPP user's decision to > > call supplies by some name. > > No. The name has to match the -supply property present in the > device's node, that's why we need this property :) Why does it need to match? Sorry I'm totally lost now. -- 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 devicetree" 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 1/2] clk: samsung: exynos5250: Add DISP1 clocks
On 10/16, Michael Turquette wrote: > Quoting Krzysztof Kozlowski (2015-10-15 16:46:27) > > On 15.10.2015 19:31, Tomeu Vizoso wrote: > > > When the DISP1 power domain is powered off, there's two clocks that need > > > to be temporarily reparented to OSC, and back to their original parents > > > when the domain is powered on again. > > > > > > We expose these two clocks in the DT bindings so that the DT node of the > > > power domain can reference them. > > > > > > Signed-off-by: Tomeu Vizoso > > > Acked-by: Stephen Boyd > > > --- > > > > > > Changes in v2: > > > - Reuse mout_aclk200_p > > > - Rename div_aclk300 as div_aclk300_disp > > > > > > drivers/clk/samsung/clk-exynos5250.c | 14 +- > > > include/dt-bindings/clock/exynos5250.h | 4 +++- > > > 2 files changed, 16 insertions(+), 2 deletions(-) > > > > > > > Reviewed-by: Krzysztof Kozlowski > > Applied to clk-next. > I think Tomeu wanted to take this through arm-soc? Otherwise we'll need to provide a stable branch for the dt header. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding
On 09/14, Rob Herring wrote: > On 09/11/2015 07:01 AM, Viresh Kumar wrote: > > Regulators already have stable DT bindings, wherein the consumer (of > > supplies) will have following for each regulator/supply. > > > > -supply: ; > > > > Current OPP bindings extend above, by transforming it into a list of > > phandles. But we missed the string, which is used to identify the > > regulator. > > > > And looking from regulators perspective, having two different ways of > > specifying regulators doesn't seem like a step forward, it also means we > > have to update every single device binding. And things will become > > complex. > > > > Another way to support multiple regulators per device (in OPP V2 > > bindings) is to leave regulator consumer bindings as is, and create a > > 'supply-names' property in the opp-table node, which will contain a list > > of strings. The names in this list shall match 'name' from the > > '-supply' strings present in the device node. > > > > The strings in this list also specify the order in which values must be > > present in 'opp-microvolt' and 'opp-microamp' properties. > > > > Cc: Mark Brown > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Viresh Kumar > > --- > > Documentation/devicetree/bindings/opp/opp.txt | 26 > > +++--- > > 1 file changed, 19 insertions(+), 7 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt > > b/Documentation/devicetree/bindings/opp/opp.txt > > index 0cb44dc21f97..8759bc4783ed 100644 > > --- a/Documentation/devicetree/bindings/opp/opp.txt > > +++ b/Documentation/devicetree/bindings/opp/opp.txt > > @@ -69,6 +69,13 @@ This describes the OPPs belonging to a device. This node > > can have following > > - compatible: Allow OPPs to express their compatibility. It should be: > >"operating-points-v2". > > > > +- supply-names: This is a required property, only if multiple supplies are > > + available for the device. Otherwise it is optional. > > + > > + This list is used to pass names of all the device supplies. The order of > > names > > + present here is important, as that should match the order in which > > values are > > + present in 'opp-microvolt' and 'opp-microamp' properties. > > + > > What if we have a 2nd device and supply rail? For example, what if the > L2$ has a separate rail from the cores but is linked to the OPPs. I'm lost why we need this property at all. What happened to using opp-microvolt-0 = <1 2 3>; opp-microvolt-1 = <1>; opp-microvolt-2 = <3 4 5>; etc. That seems to avoid any problem with 3 vs. 1 element properties combined into one large array. Having supply-names seems too brittle and would tie us to a particular OPP user's decision to call supplies by some name. Also, I've seen devices that are split across two power domains. These devices aren't CPUs, but they are other devices including L2 caches. So we're going to need either multiple regulator support or multiple "power domain at a particular performance levels" support somehow. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13] clk: add ARM syscon ICST device tree bindings
On 10/15, Linus Walleij wrote:
> diff --git a/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt
> b/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt
> new file mode 100644
> index ..19eb3aa765c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt
> @@ -0,0 +1,40 @@
> +ARM System Controller ICST clocks
> +
> +The ICS525 and ICS307 oscillators are produced by Integrated Devices
> +Technology (IDT). ARM integrated these oscillators deeply into their
> +reference designs by adding special control registers that manage such
> +oscillators to their system controllers.
> +
> +The ARM system controller contains logic to serialized and initialize
serialize ?
> +an ICST clock request after a write to the 32 bit register at an offset
> +into the system controller. Further, to even be able to alter one of
Furthermore?
> +these frequencies, the system controller must first be unlocked by
> +writing a special token to another offset in the system controller.
Sounds like a great design!
> +
> +The ICST oscillator must be provided inside a system controller node.
> +
> +Required properties:
> +- lock-offset: the offset address into the system controller where the
> + unlocking register is located
> +- vco-offset: the offset address into the system controller where the
> + ICST control register is located (even 32 bit address)
Is there any reason why we don't use a reg property for this?
> +- compatible: must be one of "arm,syscon-icst525" or "arm,syscon-icst307"
> +- #clock-cells: must be <0>
> +- clocks: parent clock, since the ICST needs a parent clock to derive its
> + frequency from, this attribute is compulsory.
> +
> +Example:
> +
> +syscon: syscon@1000 {
> + compatible = "syscon";
> + reg = <0x1000 0x1000>;
> +
> + oscclk0: osc0@0c {
> + compatible = "arm,syscon-icst307";
> + #clock-cells = <0>;
> + lock-offset = <0x20>;
> + vco-offset = <0x0C>;
lowercase the C?
> + clocks = <&xtal24mhz>;
> + };
> + (...)
> +};
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/2] clk: samsung: exynos5250: Add DISP1 clocks
On 10/14, Tomeu Vizoso wrote: > When the DISP1 power domain is powered off, there's two clocks that need > to be temporarily reparented to OSC, and back to their original parents > when the domain is powered on again. > > We expose these two clocks in the DT bindings so that the DT node of the > power domain can reference them. > > Signed-off-by: Tomeu Vizoso > --- Acked-by: Stephen Boyd -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC
On 10/13/2015 09:51 AM, Scott Branden wrote: > > Is that really necessary at all I think something like this work > instead? > > -obj-$(CONFIG_ARCH_BCM)+= bcm/ > +obj-y+= bcm/ > > Yes that's fine too, as long as we don't add any obj-y inside bcm/Makefile -- 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 devicetree" 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 0/4] arm64: dts: qcom: add support to LS and HS connectors
On 10/09/2015 01:53 AM, Srinivas Kandagatla wrote: > Hi Andy, > > This patchset adds support for i2c and spi on High-Speed and Low speed > connectors on DB410c. > One of the patch fixes the sleep state of existing i2c node. > > thanks, > srini > > Changes since v1: > - removed useless comment spotted by Stephen Boyd. > - Use absolute names instead of lables for consistency suggested by > Stephen Boyd. > Reviewed-by: Stephen Boyd -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC
On 10/02, Jon Mason wrote: > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index 23800a1..2790f21 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -2,6 +2,7 @@ menu "Platform selection" > > config ARCH_BCM_IPROC > bool "Broadcom iProc SoC Family" > + select COMMON_CLK_IPROC Given that this is a visible option, I'd expect the defconfig to enable this. > help > This enables support for Broadcom iProc based SoCs > > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile > index d08b3e5..ea81eaa 100644 > --- a/drivers/clk/Makefile > +++ b/drivers/clk/Makefile > @@ -47,7 +47,8 @@ obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o > obj-$(CONFIG_COMMON_CLK_XGENE) += clk-xgene.o > obj-$(CONFIG_COMMON_CLK_PWM) += clk-pwm.o > obj-$(CONFIG_COMMON_CLK_AT91)+= at91/ > -obj-$(CONFIG_ARCH_BCM) += bcm/ > +obj-$(CONFIG_CLK_BCM_KONA) += bcm/ > +obj-$(CONFIG_COMMON_CLK_IPROC) += bcm/ Also, perhaps we need some sort of Kconfig thing for overall bcm clock drivers, so that we don't have duplicate Makefile rules. config COMMON_CLK_BCM bool "Support for Broadcom clocks" -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] clk: iproc: Add PLL base write function
On 10/02, Jon Mason wrote:
> diff --git a/drivers/clk/bcm/clk-iproc-pll.c b/drivers/clk/bcm/clk-iproc-pll.c
> index e029ab3..a4602aa 100644
> --- a/drivers/clk/bcm/clk-iproc-pll.c
> +++ b/drivers/clk/bcm/clk-iproc-pll.c
> @@ -137,6 +137,18 @@ static int pll_wait_for_lock(struct iproc_pll *pll)
> return -EIO;
> }
>
> +static void iproc_pll_write(struct iproc_pll *pll, void __iomem *base,
> + u32 offset, u32 val)
> +{
> + const struct iproc_pll_ctrl *ctrl = pll->ctrl;
> +
> + writel(val, base + offset);
> +
> + if (unlikely(ctrl->flags & IPROC_CLK_NEEDS_READ_BACK &&
> + base == pll->pll_base))
> + val = readl(base + offset);
Is there any point to assign val here?
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC
On 10/02, Jon Mason wrote:
> diff --git a/drivers/clk/bcm/clk-ns2.c b/drivers/clk/bcm/clk-ns2.c
> new file mode 100644
> index 000..1d08281
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-ns2.c
> @@ -0,0 +1,290 @@
> +/*
> + * Copyright (C) 2015 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
clkdev looks unused here too?
> +#include
> +#include
And this one?
> +
> +#include
> +#include "clk-iproc.h"
> +
> +#define reg_val(o, s, w) { .offset = o, .shift = s, .width = w, }
I guess we missed this one already, but this isn't a macro
resembling a function. Kernel style is to capitalize this sort of
macro.
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] ARM: dts: enable clock support for BCM5301X
On 10/09, Jon Mason wrote:
> On Fri, Oct 09, 2015 at 12:35:40AM -0700, Stephen Boyd wrote:
> > On 10/02, Jon Mason wrote:
> >
> > > arch/arm/boot/dts/bcm5301x.dtsi | 67
> > > -
> > > 1 file changed, 60 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
> > > b/arch/arm/boot/dts/bcm5301x.dtsi
> > > index 6f50f67..f717859 100644
> > > --- a/arch/arm/boot/dts/bcm5301x.dtsi
> > > +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> > > @@ -55,14 +56,14 @@
> > > compatible = "arm,cortex-a9-global-timer";
> > > reg = <0x0200 0x100>;
> > > interrupts = ;
> > > - clocks = <&clk_periph>;
> > > + clocks = <&periph_clk>;
> > > };
> > >
> > > local-timer@0600 {
> > > compatible = "arm,cortex-a9-twd-timer";
> > > reg = <0x0600 0x100>;
> > > interrupts = ;
> > > - clocks = <&clk_periph>;
> > > + clocks = <&periph_clk>;
> > > };
> > >
> > > gic: interrupt-controller@1000 {
> > > @@ -94,14 +95,66 @@
> > >
> > > clocks {
> >
> > I'd expect this to only contain nodes that don't have a reg
> > property. Clock providers that have a reg property would go into
> > some soc node or bus. Perhaps that's the chipcommonA node, or
> > axi?
>
> This might get a little ugly, as some of the clocks are in the
> 0x1800 and others are in 0x1900. I would think it better to
> have them all in one place (as that is more readable). Do you preferr
> I split the pieces up into their respective DT nodes?
Are there two clock controllers? Sorry I don't understand the
architecture here very well. Nodes with reg properties in the
same range should be near each other. We don't group all i2c
controllers into the same node because they're logically i2c
controllers. We express the hierarchy of devices with container
nodes. The clocks node is only useful for board-level clocks, not
things that are inside the SoC.
--
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 devicetree" 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 1/2] devicetree: add binding for generic mmio clocksource
On 10/09, Måns Rullgård wrote: > Stephen Boyd writes: > > > > Does that mean a flag day? Urgh. Pain. I'm not opposed to adding > > a pointer, in fact it might be better for performance so that we > > don't take a cache miss in read() functions that need to load > > some pointer. We were talking about that problem a few months > > ago, but nothing came of it. > > I've sent a patch. Let the flames begin. > I never got it. Was I Cced? -- 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 devicetree" 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 1/2] devicetree: add binding for generic mmio clocksource
On 10/09, Måns Rullgård wrote: > Stephen Boyd writes: > > > On 10/09, Rob Herring wrote: > >> > >> Adding a ptr to the callback seems fine to me. > >> > > > > Does that mean a flag day? Urgh. Pain. I'm not opposed to adding > > a pointer, in fact it might be better for performance so that we > > don't take a cache miss in read() functions that need to load > > some pointer. We were talking about that problem a few months > > ago, but nothing came of it. > > Flag day in what sense? There aren't all that many users of the > interface (56, to be precise), and sched_clock_register() isn't > exported. That's exactly what a flag day is. Lots of coordination, lots of acks, etc. Last time when I changed the registration API I made a new registration API, moved every caller over one by one, and then deleted the old registration API. That's how you manage a flag day. We could probably do the same thing again with two different types of registration APIs so that we move over users one by one. The old registration API would be wrapped with a sched_clock local function that doesn't pass the pointer it gets called with, while the new registration API would fill in the function pointer that we call directly from the core code. The double function call is probably bad for performance, so I guess we should get rid of it and always pass the pointer to the callback. But this is at least a method to convert everything gradually without breaking users that may be going through different trees. > Verifying the change will be a minor pain, but I don't see > why it should have any major consequences. Obviously I'd just set the > pointer to null for existing users and leave it for the respective > maintainers to make proper use of it where sensible. > Sure. -- 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 devicetree" 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 1/2] devicetree: add binding for generic mmio clocksource
On 10/09, Rob Herring wrote: > +Stephen who has worked on this code. > > On Fri, Oct 9, 2015 at 11:19 AM, Måns Rullgård wrote: > > Måns Rullgård writes: > > > >> Rob Herring writes: > >> > >>> On Wed, Oct 7, 2015 at 11:47 AM, Måns Rullgård wrote: > What would be a proper way to select a sched_clock source? I realise > it's a Linux-specific thing and DT is supposed to be generic, but the > information must be provided somehow. > >>> > >>> The kernel already has some logic to do this. Most number of bits > >>> followed by highest frequency will be the winning sched_clock. You > >>> might also want to look at things like always on or not. > >> > >> The problem is that sched_clock_register() doesn't take a pointer to be > >> passed back to the read_sched_clock callback like most interfaces of > >> this type do. This means the callback must use global variables set up > >> before the register call, but at that time there's no way of knowing > >> which one will be used. If there were a way of getting a pointer to the > >> callback, it would be a simple matter of registering all instances and > >> letting the kernel choose which to use. > > > > Anyone got a comment on this? Do I have to send a patch adding this > > before anyone will tell me why it's a bad idea? (That method almost > > always works.) > > Adding a ptr to the callback seems fine to me. > Does that mean a flag day? Urgh. Pain. I'm not opposed to adding a pointer, in fact it might be better for performance so that we don't take a cache miss in read() functions that need to load some pointer. We were talking about that problem a few months ago, but nothing came of it. -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] clk: nsp: add clock support for Broadcom Northstar Plus SoC
On 10/02, Jon Mason wrote: > diff --git a/drivers/clk/bcm/clk-nsp.c b/drivers/clk/bcm/clk-nsp.c > new file mode 100644 > index 000..708961a > --- /dev/null > +++ b/drivers/clk/bcm/clk-nsp.c > @@ -0,0 +1,139 @@ > +/* > + * Copyright (C) 2015 Broadcom Corporation > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation version 2. > + * > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any > + * kind, whether express or implied; without even the implied warranty > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include Is this used? > +#include > +#include Is this used? > + > +#include > +#include "clk-iproc.h" -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] ARM: dts: enable clock support for BCM5301X
On 10/02, Jon Mason wrote:
> Replace current device tree dummy clocks with real clock support for
> Broadcom Northstar SoCs.
>
> Signed-off-by: Jon Mason
> ---
I'd rather not take any dts changes through clk tree.
> arch/arm/boot/dts/bcm5301x.dtsi | 67
> -
> 1 file changed, 60 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> index 6f50f67..f717859 100644
> --- a/arch/arm/boot/dts/bcm5301x.dtsi
> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> @@ -55,14 +56,14 @@
> compatible = "arm,cortex-a9-global-timer";
> reg = <0x0200 0x100>;
> interrupts = ;
> - clocks = <&clk_periph>;
> + clocks = <&periph_clk>;
> };
>
> local-timer@0600 {
> compatible = "arm,cortex-a9-twd-timer";
> reg = <0x0600 0x100>;
> interrupts = ;
> - clocks = <&clk_periph>;
> + clocks = <&periph_clk>;
> };
>
> gic: interrupt-controller@1000 {
> @@ -94,14 +95,66 @@
>
> clocks {
I'd expect this to only contain nodes that don't have a reg
property. Clock providers that have a reg property would go into
some soc node or bus. Perhaps that's the chipcommonA node, or
axi?
> #address-cells = <1>;
> - #size-cells = <0>;
> + #size-cells = <1>;
> + ranges;
>
> - /* As long as we do not have a real clock driver us this
> - * fixed clock */
> - clk_periph: periph {
> + osc: oscillator {
> + #clock-cells = <0>;
> compatible = "fixed-clock";
> + clock-frequency = <2500>;
> + };
> +
> + lcpll0: lcpll0@1800c100 {
> + #clock-cells = <1>;
> + compatible = "brcm,nsp-lcpll0";
> + reg = <0x1800c100 0x14>;
> + clocks = <&osc>;
> + clock-output-names = "lcpll0", "pcie_phy", "sdio",
> + "ddr_phy";
> + };
> +
> + genpll: genpll@1800c140 {
> + #clock-cells = <1>;
> + compatible = "brcm,nsp-genpll";
> + reg = <0x1800c140 0x24>;
> + clocks = <&osc>;
> + clock-output-names = "genpll", "phy", "ethernetclk",
> + "usbclk", "iprocfast", "sata1",
> + "sata2";
> + };
> +
> + iprocmed: iprocmed {
> + #clock-cells = <0>;
> + compatible = "fixed-factor-clock";
> + clocks = <&genpll BCM_NSP_GENPLL_IPROCFAST_CLK>;
> + clock-div = <2>;
> + clock-mult = <1>;
> + clock-output-names = "iprocmed";
> + };
> +
> + iprocslow: iprocslow {
> + #clock-cells = <0>;
> + compatible = "fixed-factor-clock";
> + clocks = <&genpll BCM_NSP_GENPLL_IPROCFAST_CLK>;
> + clock-div = <4>;
> + clock-mult = <1>;
> + clock-output-names = "iprocslow";
> + };
> +
> +
> + a9pll: arm_clk@1900 {
> + #clock-cells = <0>;
> + compatible = "brcm,nsp-armpll";
> + clocks = <&osc>;
> + reg = <0x1900 0x1000>;
> + };
> +
> + periph_clk: periph_clk {
> #clock-cells = <0>;
> - clock-frequency = <4>;
> + compatible = "fixed-factor-clock";
> + clocks = <&a9pll>;
> + clock-div = <2>;
> + clock-mult = <1>;
> };
> };
>
We're trying to move away from putting individual clocks into DT
like this. Is there some sort of clock controller that's at
0x1800c000, but we're just not exposing all the clocks in there?
See this thread for more information on why we'd like to avoid
this sort of design:
http://lkml.kernel.org/r/<20150416192014.19585.9663@quantum>
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] clk: iproc: Add PLL base write function
On 10/02, Jon Mason wrote:
> diff --git a/drivers/clk/bcm/clk-iproc-pll.c b/drivers/clk/bcm/clk-iproc-pll.c
> index e029ab3..a4602aa 100644
> --- a/drivers/clk/bcm/clk-iproc-pll.c
> +++ b/drivers/clk/bcm/clk-iproc-pll.c
> @@ -137,6 +137,18 @@ static int pll_wait_for_lock(struct iproc_pll *pll)
> return -EIO;
> }
>
> +static void iproc_pll_write(struct iproc_pll *pll, void __iomem *base,
Seems that pll could be const too?
> + u32 offset, u32 val)
> +{
> + const struct iproc_pll_ctrl *ctrl = pll->ctrl;
> +
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] clk: imx7d: add ADC root clock
On 10/08, Haibo Chen wrote: > Add ADC root clock support in imx7d clock tree. > > Signed-off-by: Haibo Chen > --- I see no cover letter indicating how you want this merged, so: Acked-by: Stephen Boyd -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] arm64: dts: qcom: Add msm8916 I2C nodes.
On 10/08/2015 04:19 AM, Srinivas Kandagatla wrote:
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 85f7bee..d49ac37 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -233,6 +233,22 @@
> status = "disabled";
> };
>
> + /* BLSP1 QUP2 */
This comment is useless.
> + blsp_i2c2: i2c@78b6000 {
> + compatible = "qcom,i2c-qup-v2.2.1";
> + reg = <0x78b6000 0x1000>;
> + interrupts = ;
>
--
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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm64: dts: apq8016-sbc: enable spi buses on LS and HS
On 10/08/2015 04:19 AM, Srinivas Kandagatla wrote:
> This patch enables spi buses on low speed and high speed expansion
> connectors on DB410C
>
> Signed-off-by: Srinivas Kandagatla
> ---
> arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 3581272..d872654 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -92,11 +92,21 @@
> status = "okay";
> };
>
> +&blsp_spi3 {
> + /* On High speed expansion */
> + status = "okay";
> +};
> +
> &blsp_i2c4 {
> /* On High speed expansion */
> status = "okay";
> };
>
> +&blsp_spi5 {
> + /* On Low speed expansion */
> + status = "okay";
> +};
> +
> &blsp_i2c6 {
> /* On Low speed expansion */
> status = "okay";
We've been using absolute nodes to mark device nodes as status = "okay".
Can we keep doing that here please?
--
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 devicetree" 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 2/4] drivers: clk: st: PLL rate change implementation for DVFS
On 10/07, Gabriel Fernandez wrote: > Change A9 PLL rate, as per requirement from the cpufreq framework, > for DVFS. For rate change, the A9 clock needs to be temporarily sourced > from PLL external to A9 and then sourced back to A9-PLL > > Signed-off-by: Pankaj Dev > Signed-off-by: Gabriel Fernandez > --- Applied to clk-next -- 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 devicetree" 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 3/4] drivers: clk: st: Correct the pll-type for A9 for stih418
On 10/07, Gabriel Fernandez wrote: > Add support for new PLL-type for stih418 A9-PLL. > Currently the 407_A9_PLL type being used, it is corrected with this patch > 4600c28 PLL allows to reach higher frequencies > so its programming algorithm is extended. > > Signed-off-by: Pankaj Dev > Signed-off-by: Gabriel Fernandez > --- Applied to clk-next -- 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 devicetree" 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 1/4] drivers: clk: st: Support for enable/disable in Clockgen PLLs
On 10/07, Gabriel Fernandez wrote: > The patch adds support for enable/disable of the Clockgen PLLs. > clkgen_pll_enable/clkgen_pll_disable added as generic function for all PLLs. > > Signed-off-by: Pankaj Dev > Signed-off-by: Gabriel Fernandez > --- Applied to clk-next -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] drivers: clk: st: PLL rate change implementation for DVFS
On 10/05, Gabriel Fernandez wrote:
> @@ -452,7 +651,7 @@ static const struct clk_ops st_pll1200c32_ops = {
> static struct clk * __init clkgen_pll_register(const char *parent_name,
> struct clkgen_pll_data *pll_data,
> void __iomem *reg,
> - const char *clk_name)
> + const char *clk_name, spinlock_t *lock)
Is there a reason we pass lock here but never use it in this
function?
> {
> struct clkgen_pll *pll;
> struct clk *clk;
--
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 devicetree" 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 3/4] drivers: clk: st: Correct the pll-type for A9 for stih418
On 08/24, Gabriel Fernandez wrote: > Add support for new PLL-type for stih418 A9-PLL. > Currently the 407_A9_PLL type being used, it is corrected with this patch > 4600c28 PLL allows to reach higher frequencies > so its programming algorithm is extended. > > Signed-off-by: Pankaj Dev > Signed-off-by: Gabriel Fernandez > --- Applied to clk-next -- 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
