Re: [PATCH v2 1/5] devicetree: bindings: Document qcom board compatible format

[Stephen Boyd]

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 <r...@kernel.org>
>>
> 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

[Stephen Boyd]

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 = >pdata.clk32k_parent;
> + } else {
> + clk32k_init.flags |= CLK_IS_ROOT;
> + }
> +
> + clkdata->clk32k_hw.init = _init;
> + clkdata->clk32k = devm_clk_register(>dev, >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()

[Stephen Boyd]

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

[Stephen Boyd]

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 < 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: [PATCH v2 10/10] dt-bindings: Add DSIv2 documentation

[Stephen Boyd]

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

[Stephen Boyd]

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 1/3] ARM: imx: clk-vf610: fix SAI clock tree

[Stephen Boyd]

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 <ste...@agner.ch>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
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

[Stephen Boyd]

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: arm64: dts: qcom: Add apq8096 dragonboard dts skeletons

[Stephen Boyd]

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: arm64: dts: qcom: Add apq8096 dragonboard dts skeletons

[Stephen Boyd]

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 <rna...@codeaurora.org>
> >> ---
> >> 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: [PATCH v2 1/5] devicetree: bindings: Document qcom board compatible format

[Stephen Boyd]

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 <sb...@codeaurora.org>
> 
> 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 <r...@kernel.org>
> 

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

Re: [PATCH v4 0/3] clk: Broadcom BCM63138 support

[Stephen Boyd]

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

[Stephen Boyd]

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: <devicetree@vger.kernel.org>
> > Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
> > Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> > Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> > ---
> 
> 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 v4 1/3] clk: iproc: Extend binding to cover BCM63138

[Stephen Boyd]

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

Re: [PATCH v4 2/3] clk: bcm: Add BCM63138 clock support

[Stephen Boyd]

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 0/3] clk: Broadcom BCM63138 support

[Stephen Boyd]

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

[PATCH v2 3/5] arm: dts: qcom: Update ifc6540 compat for qcom boot format

[Stephen Boyd]

The ifc6540 is an sbc (single board computer) board, so update
the compatible field accordingly.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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 = _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

[Stephen Boyd]

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 <sb...@codeaurora.org>
---
 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 = _uart2;
serial1 = _uart1;
+   usid0 = _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 = _uart2;
+   usid0 = _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 @@
 
 _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

[Stephen Boyd]

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 <sb...@codeaurora.org>
---
 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 = _uart2;
+   usid0 = _0;
+   usid4 = _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 = _uart2;
+   usid0 = _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 = _uart2;
+   usid0 = _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 @@
 
 _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 @@
 
 _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 @@
 
 _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

[Stephen Boyd]

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 <sb...@codeaurora.org>
---
 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

[Stephen Boyd]

This compatible string isn't compliant with the format for
subtypes. Replace it with a compliant compatible type.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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}

[Stephen Boyd]

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

[PATCH] arm: dts: qcom: Add generic PMIC gpio/MPP compat strings

[Stephen Boyd]

Add the generic compatible strings for the PMIC gpio and MPP
modules found on qcom based PMICs.

Cc: <devicetree@vger.kernel.org>
Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
Cc: Rob Herring <r...@kernel.org>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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] clk: add generic driver for fixed rate clock

[Stephen Boyd]

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] pinctrl: qcom: Add msm8996 pinctrl driver

[Stephen Boyd]

From: Joonwoo Park <joonw...@codeaurora.org>

Add initial pinctrl driver to support pin configuration with
pinctrl framework for msm8996.

Cc: <devicetree@vger.kernel.org>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
Signed-off-by: Joonwoo Park <joonw...@codeaurora.org>
[sb...@codeaurora.org: Remove duplicate entries and enums]
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 .../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_tra

[PATCH 0/2] Add pm8994 gpio and mpp support

[Stephen Boyd]

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: <devicetree@vger.kernel.org>
Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>

 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 1/2] pinctrl: qcom: spmi-gpio: Add pm8994 gpio support

[Stephen Boyd]

Update the binding and driver for pm8994-gpio devices.

Cc: <devicetree@vger.kernel.org>
Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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 2/2] pinctrl: qcom: spmi-mpp: Add pm8994 mpp support

[Stephen Boyd]

Update the driver and binding for pm8994-mpp devices.

Cc: <devicetree@vger.kernel.org>
Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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

[RFC/PATCH] pinctrl: qcom: Add generic ssbi and spmi GPIO/MPP bindings

[Stephen Boyd]

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: <devicetree@vger.kernel.org>
Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---

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 0/4] Add DTS for MSM8996 SoC and MTP

[Stephen Boyd]

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

[Stephen Boyd]

Document the compatible string for the Kryo family of qcom cpus.

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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

Re: [PATCH 1/3] devicetree: bindings: Document qcom board compatible format

[Stephen Boyd]

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 <sb...@codeaurora.org>
> > ---
> >  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 dtbs for
devices that have different panels on them. I'm not sure this is
still used though. It could be legacy.

> 
> 
> > +The 'boot' e

Re: [PATCH 1/3] devicetree: bindings: Document qcom board compatible format

[Stephen Boyd]

On 11/12, Rob Herring wrote:
> On Thu, Nov 12, 2015 at 1:44 PM, Stephen Boyd <sb...@codeaurora.org> 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 1/3] devicetree: bindings: Document qcom board compatible format

[Stephen Boyd]

On 11/12, Olof Johansson wrote:
> On Mon, Oct 26, 2015 at 2:25 PM, Stephen Boyd <sb...@codeaurora.org> 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

[Stephen Boyd]

On 11/12, Rob Herring wrote:
> On Thu, Nov 12, 2015 at 6:11 PM, Stephen Boyd <sb...@codeaurora.org> wrote:
> > On 11/12, Rob Herring wrote:
> >> On Thu, Nov 12, 2015 at 1:44 PM, Stephen Boyd <sb...@codeaurora.org> 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 = <>;
usid2 = <>;
usid4 = <>;
usid6 = <>;

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] PM / OPP: Add "opp-supported-hw" binding

[Stephen Boyd]

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 <viresh.ku...@linaro.org>
> 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 <sb...@codeaurora.org>
> Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
> ---

Reviewed-by: Stephen Boyd <sb...@codeaurora.org>

-- 
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

[Stephen Boyd]

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 <sb...@codeaurora.org>

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

[Stephen Boyd]

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

[Stephen Boyd]

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

[Stephen Boyd]

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 02/19] clk: sunxi: Add PLL3 clock

[Stephen Boyd]

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,
> +  , 1,
> +  NULL, NULL,
> +  >hw, _factor_ops,
> +  >hw, _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 3/3] PM / OPP: Remove 'operating-points-names' binding

[Stephen Boyd]

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 <viresh.ku...@linaro.org>
> ---

Reviewed-by: Stephen Boyd <sb...@codeaurora.org>

-- 
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

[Stephen Boyd]

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 <viresh.ku...@linaro.org>
> ---

Reviewed-by: Stephen Boyd <sb...@codeaurora.org>

-- 
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

[Stephen Boyd]

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 04/19] clk: sunxi: Add TCON channel1 clock

[Stephen Boyd]

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 01/19] clk: sunxi: Add display clock

[Stephen Boyd]

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", _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

[Stephen Boyd]

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 = <>, <>, 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 08/13 v2] clk: add ARM syscon ICST device tree bindings

[Stephen Boyd]

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 <mturque...@baylibre.com>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
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

[Stephen Boyd]

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 v3] EDAC: Add ARM64 EDAC

[Stephen Boyd]

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(_arm64_edac_driver);
> +}
> +module_init(cortex_arm64_edac_init);
> +
> +static void __exit cortex_arm64_edac_exit(void)
> +{
> + platform_driver_unregister(_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

[Stephen Boyd]

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 v2 0/3] clk: Broadcom BCM63138 support

[Stephen Boyd]

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

[PATCH 0/3] Remove the need for qcom,{msm-id,board-id,pmic-id}

[Stephen Boyd]

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

[Stephen Boyd]

This compatible string isn't compliant with the format for
subtypes. Replace it with a compliant compatible type.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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

[Stephen Boyd]

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 <sb...@codeaurora.org>
---
 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

[Stephen Boyd]

The ifc6540 is an sbc (single board computer) board, so update
the compatible field accordingly.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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 = _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 08/13 v2] clk: add ARM syscon ICST device tree bindings

[Stephen Boyd]

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 <mturque...@baylibre.com>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
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

[Stephen Boyd]

On 10/23, Linus Walleij wrote:
> On Thu, Oct 15, 2015 at 9:23 PM, Stephen Boyd <sb...@codeaurora.org> 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 v2] EDAC: Add ARM64 EDAC

[Stephen Boyd]

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 = >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(_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 v4 5/5] [RFC] clk: shmobile: r8a7795: Add new CPG/MSSR driver

[Stephen Boyd]

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 v3 01/10] ARM: cygnus: fix link failures when CONFIG_COMMON_CLK_IPROC is disabled

[Stephen Boyd]

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 v3 02/10] clk: cygnus: Convert all macros to all caps

[Stephen Boyd]

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 03/10] clk: iproc: Add PWRCTRL support

[Stephen Boyd]

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 04/10] clk: nsp: add clock support for Broadcom Northstar Plus SoC

[Stephen Boyd]

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 07/10] clk: iproc: Separate status and control variables

[Stephen Boyd]

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

[Stephen Boyd]

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 08/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Stephen Boyd]

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 09/10] clk: iproc: define Broadcom NSP iProc clock binding

[Stephen Boyd]

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 0/10] clk: iproc: add support for BCM NS, NSP, and NS2

[Stephen Boyd]

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 08/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Stephen Boyd]

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 10/10] clk: iproc: define Broadcom NS2 iProc clock binding

[Stephen Boyd]

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 1/3] clk: samsung: exynos4: Add SSS gate clock

[Stephen Boyd]

On 10/19, Krzysztof Kozlowski wrote:
> Add a gate clock for controlling all clocks of Security Sub System
> (SSS).
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> ---

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 <sb...@codeaurora.org>

-- 
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

[Stephen Boyd]

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 <tomeu.viz...@collabora.com>
> > > Acked-by: Stephen Boyd <sb...@codeaurora.org>
> > > ---
> > > 
> > > 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 <k.kozlow...@samsung.com>
> 
> 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

[Stephen Boyd]

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 01/10] clk: rockchip: Add sclk_mipidsi_24m for mipi dsi

[Stephen Boyd]

On 10/10, Chris Zhong wrote:
> sclk_mipidsi_24m is the gating of mipi dsi phy.
> 
> Signed-off-by: Chris Zhong <z...@rock-chips.com>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

> 
>  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: [RFC 4/5] clk: iproc: define Broadcom NS2 iProc clock binding

[Stephen Boyd]

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/16] PM / OPP: Add 'supply-names' binding

[Stephen Boyd]

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

[Stephen Boyd]

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 = <>;
> + };
> + (...)
> +};

-- 
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

[Stephen Boyd]

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 <tomeu.viz...@collabora.com>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
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

[Stephen Boyd]

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

[Stephen Boyd]

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 <sb...@codeaurora.org>

-- 
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

[Stephen Boyd]

On 10/09, Måns Rullgård wrote:
> Stephen Boyd <sb...@codeaurora.org> 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 04/10] ARM: dts: enable clock support for BCM5301X

[Stephen Boyd]

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 = <_periph>;
> > > + clocks = <_clk>;
> > >   };
> > >  
> > >   local-timer@0600 {
> > >   compatible = "arm,cortex-a9-twd-timer";
> > >   reg = <0x0600 0x100>;
> > >   interrupts = ;
> > > - clocks = <_periph>;
> > > + clocks = <_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

[Stephen Boyd]

On 10/09, Måns Rullgård wrote:
> Stephen Boyd <sb...@codeaurora.org> 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 05/10] clk: iproc: Add PLL base write function

[Stephen Boyd]

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

[Stephen Boyd]

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 09/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Stephen Boyd]

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 02/10] clk: nsp: add clock support for Broadcom Northstar Plus SoC

[Stephen Boyd]

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 05/10] clk: iproc: Add PLL base write function

[Stephen Boyd]

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 04/10] ARM: dts: enable clock support for BCM5301X

[Stephen Boyd]

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 = <_periph>;
> + clocks = <_clk>;
>   };
>  
>   local-timer@0600 {
>   compatible = "arm,cortex-a9-twd-timer";
>   reg = <0x0600 0x100>;
>   interrupts = ;
> - clocks = <_periph>;
> + clocks = <_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 = <>;
> + clock-output-names = "lcpll0", "pcie_phy", "sdio",
> +  "ddr_phy";
> + };
> +
> + genpll: genpll@1800c140 {
> + #clock-cells = <1>;
> + compatible = "brcm,nsp-genpll";
> + reg = <0x1800c140 0x24>;
> + clocks = <>;
> + clock-output-names = "genpll", "phy", "ethernetclk",
> +  "usbclk", "iprocfast", "sata1",
> +  "sata2";
> + };
> +
> + iprocmed: iprocmed {
> + #clock-cells = <0>;
> + compatible = "fixed-factor-clock";
> + clocks = < 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 = < 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 = <>;
> + reg = <0x1900 0x1000>;
> + };
> +
> + periph_clk: periph_clk {
>   #clock-cells = <0>;
> - clock-frequency = <4>;
> + compatible = "fixed-factor-clock";
> + clocks = <>;
> + 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 v2 1/2] devicetree: add binding for generic mmio clocksource

[Stephen Boyd]

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 3/5] clk: imx7d: add ADC root clock

[Stephen Boyd]

On 10/08, Haibo Chen wrote:
> Add ADC root clock support in imx7d clock tree.
> 
> Signed-off-by: Haibo Chen <haibo.c...@freescale.com>
> ---

I see no cover letter indicating how you want this merged, so:

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
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

[Stephen Boyd]

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";
>  };
>  
> +_spi3 {
> + /* On High speed expansion */
> + status = "okay";
> +};
> +
>  _i2c4 {
>   /* On High speed expansion */
>   status = "okay";
>  };
>  
> +_spi5 {
> + /* On Low speed expansion */
> + status = "okay";
> +};
> +
>  _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 2/4] arm64: dts: qcom: Add msm8916 I2C nodes.

[Stephen Boyd]

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 v4 2/4] drivers: clk: st: PLL rate change implementation for DVFS

[Stephen Boyd]

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 v3 2/4] drivers: clk: st: PLL rate change implementation for DVFS

[Stephen Boyd]

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] Add driver for the si514 clock generator chip

[Stephen Boyd]

On 10/02, Mike Looijmans wrote:
> On 02-10-15 01:34, Stephen Boyd wrote:
> >>+ - clock-output-names: From common clock bindings. Recommended to be 
> >>"si514".
> >>+ - clock-frequency: Output frequency to generate. This defines the output
> >>+   frequency set during boot. It can be reprogrammed during
> >>+   runtime through the common clock framework.
> >
> >Can we use assigned clock rates instead of this property?
> 
> I'll first need to learn what 'assigned clock rates' means. But I
> suspect the answer will be yes.

See the "Assigned clock parents and rates" section of
Documentation/devicetree/bindings/clock/clock-bindings.txt and
commit 86be408bfbd8 (clk: Support for clock parents and rates
assigned from device tree, 2014-06-18).

> 
> >>+
> >>+Example:
> >>+   si514: clock-generator@55 {
> >>+   reg = <0x55>;
> >>+   #clock-cells = <0>;
> >>+   compatible = "silabs,si514";
> >>+   };
> >>diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> >>index 42f7120..6ac7deb5 100644
> >>--- a/drivers/clk/Kconfig
> >>+++ b/drivers/clk/Kconfig
> >>@@ -68,6 +68,16 @@ config COMMON_CLK_SI5351
> >>  This driver supports Silicon Labs 5351A/B/C programmable clock
> >>  generators.
> >>
> >>+config COMMON_CLK_SI514
> >>+   tristate "Clock driver for SiLabs 514 devices"
> >>+   depends on I2C
> >>+   depends on OF
> >
> >It actually depends on this to build?
> 
> It calls various 'of_' methods unconditionally, so I'd think so.

Aren't there stubs for those if CONFIG_OF=n?

-- 
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/4] drivers: clk: st: Support for enable/disable in Clockgen PLLs

[Stephen Boyd]

On 08/24, 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 v2 4/4] ARM: STi: DT: Add support for stih418 A9 pll

[Stephen Boyd]

On 08/24, Gabriel Fernandez wrote:
> Add support for new PLL-type for stih418 A9-PLL.
> 
> Signed-off-by: Gabriel Fernandez 
> ---

I assume this will go through 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 v2 2/4] drivers: clk: st: PLL rate change implementation for DVFS

[Stephen Boyd]

On 08/24, 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