[v11,0/6] Add support for Qualcomm A53 CPU clock

This patchset adds support for the A53 CPU clock on MSM8916 platforms
and allows scaling of the CPU frequency on msm8916 based platforms.

Changes since v10 (https://lkml.org/lkml/2017/12/1/577)
* Addressed Bjorn's comments on APCS clock driver.
* Picked Acks from Rob and Bjorn.

Changes since v9 (https://lkml.org/lkml/2017/9/21/511)
* Added the clock properties to the APCS DT node, instead of adding a subnode
and also replaced patch "mailbox: qcom: Populate APCS child platform devices"
with "mailbox: qcom: Create APCS child device for clock controller".
* Dropped patch "mailbox: qcom: Move the apcs struct into a separate header",
and use dev_get_regmap(dev->parent) in the child driver.
* Addressed Bjorn's comments on a53-pll and apcs-clk drivers.
* Added SPDX copyright identifiers.

Changes since v8 (https://lkml.org/lkml/2017/6/23/476)
 * Converted APCS mailbox driver to use regmap and to populate child
 platform devices that will handle the rest of the functionality
 provided by APCS block.
 * Picked Rob's Ack for the PLL binding.
 * Changed the APCS binding and put it into a separate patch.
 * Addressed review comments.
 * Minor changes.

Changes since v7 (https://lkml.org/lkml/2016/10/31/296)
 * Add the APCS clock controller to the APCS driver to expose both the
 mailbox and clock controller functionality as discussed earlier:
 https://lkml.org/lkml/2016/11/14/860
 * Changed the a53pll compatible string as suggested by Rob.

Changes since v6 (https://lkml.org/lkml/2016/9/7/347)
 * Addressed various comments from Stephen Boyd

Changes since v5 (https://lkml.org/lkml/2016/2/1/407)
 * Rebase to clk-next and update according to the recent API changes.

Changes since v4 (https://lkml.org/lkml/2015/12/14/367)
 * Convert to builtin drivers as now __clk_lookup() is used

Changes since v3 (https://lkml.org/lkml/2015/8/12/585)
 * Split driver into two parts - and separate A53 PLL and
   A53 clock controller drivers.
 * Drop the safe switch hook patch. Add a clock notifier in
   the clock provider to handle switching via safe mux and
   divider configuration.

Changes since v2 (https://lkml.org/lkml/2015/7/24/526)
 * Drop gpll0_vote patch.
 * Switch to the new clk_hw_* APIs.
 * Rebase to the current clk-next.

Changes since v1 (https://lkml.org/lkml/2015/6/12/193)
 * Drop SR2 PLL patch, as it is already applied.
 * Add gpll0_vote rate propagation patch.
 * Update/rebase patches to the current clk-next.

Georgi Djakov (6):
  mailbox: qcom: Convert APCS IPC driver to use regmap
  mailbox: qcom: Create APCS child device for clock controller
  clk: qcom: Add A53 PLL support
  clk: qcom: Add regmap mux-div clocks support
  dt-bindings: mailbox: qcom: Document the APCS clock binding
  clk: qcom: Add APCS clock controller support

 .../devicetree/bindings/clock/qcom,a53pll.txt      |  22 ++
 .../bindings/mailbox/qcom,apcs-kpss-global.txt     |  18 ++
 drivers/clk/qcom/Kconfig                           |  21 ++
 drivers/clk/qcom/Makefile                          |   3 +
 drivers/clk/qcom/a53-pll.c                         | 110 ++++++++++
 drivers/clk/qcom/apcs-msm8916.c                    | 149 ++++++++++++++
 drivers/clk/qcom/clk-regmap-mux-div.c              | 229 +++++++++++++++++++++
 drivers/clk/qcom/clk-regmap-mux-div.h              |  46 +++++
 drivers/mailbox/qcom-apcs-ipc-mailbox.c            |  35 +++-
 9 files changed, 628 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53pll.txt
 create mode 100644 drivers/clk/qcom/a53-pll.c
 create mode 100644 drivers/clk/qcom/apcs-msm8916.c
 create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.c
 create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.h

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue 05 Dec 07:47 PST 2017, Georgi Djakov wrote:

> Add a driver for the APCS clock controller. It is part of the APCS
> hardware block, which among other things implements also a combined
> mux and half integer divider functionality. It can choose between a
> fixed-rate clock or the dedicated APCS (A53) PLL. The source and the
> divider can be set both at the same time.
> 
> This is required for enabling CPU frequency scaling on MSM8916-based
> platforms.
> 

Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Regards,
Bjorn

> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
>  drivers/clk/qcom/Kconfig        |  11 +++
>  drivers/clk/qcom/Makefile       |   1 +
>  drivers/clk/qcom/apcs-msm8916.c | 149 ++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 161 insertions(+)
>  create mode 100644 drivers/clk/qcom/apcs-msm8916.c
> 
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 81ac7b9378fe..255023b439c9 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -22,6 +22,17 @@ config QCOM_A53PLL
>  	  Say Y if you want to support higher CPU frequencies on MSM8916
>  	  devices.
>  
> +config QCOM_CLK_APCS_MSM8916
> +	bool "MSM8916 APCS Clock Controller"
> +	depends on COMMON_CLK_QCOM
> +	depends on QCOM_APCS_IPC
> +	default ARCH_QCOM
> +	help
> +	  Support for the APCS Clock Controller on msm8916 devices. The
> +	  APCS is managing the mux and divider which feeds the CPUs.
> +	  Say Y if you want to support CPU frequency scaling on devices
> +	  such as msm8916.
> +
>  config QCOM_CLK_RPM
>  	tristate "RPM based Clock Controller"
>  	depends on COMMON_CLK_QCOM && MFD_QCOM_RPM
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index 7c51d877f967..0408cebf38d4 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -34,5 +34,6 @@ obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
>  obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
>  obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
>  obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
> +obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o
>  obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
>  obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
> diff --git a/drivers/clk/qcom/apcs-msm8916.c b/drivers/clk/qcom/apcs-msm8916.c
> new file mode 100644
> index 000000000000..832172c2fc8b
> --- /dev/null
> +++ b/drivers/clk/qcom/apcs-msm8916.c
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Qualcomm APCS clock controller driver
> + *
> + * Copyright (c) 2017, Linaro Limited
> + * Author: Georgi Djakov <georgi.djakov@linaro.org>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/kernel.h>
> +#include <linux/mailbox_controller.h>
> +#include <linux/module.h>
> +#include <linux/io.h>
> +#include <linux/slab.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include "clk-regmap.h"
> +#include "clk-regmap-mux-div.h"
> +
> +enum {
> +	P_GPLL0,
> +	P_A53PLL,
> +};
> +
> +static const struct parent_map gpll0_a53cc_map[] = {
> +	{ P_GPLL0, 4 },
> +	{ P_A53PLL, 5 },
> +};
> +
> +static const char * const gpll0_a53cc[] = {
> +	"gpll0_vote",
> +	"a53pll",
> +};
> +
> +/*
> + * We use the notifier function for switching to a temporary safe configuration
> + * (mux and divider), while the A53 PLL is reconfigured.
> + */
> +static int a53cc_notifier_cb(struct notifier_block *nb, unsigned long event,
> +			     void *data)
> +{
> +	int ret = 0;
> +	struct clk_regmap_mux_div *md = container_of(nb,
> +						     struct clk_regmap_mux_div,
> +						     clk_nb);
> +	if (event == PRE_RATE_CHANGE)
> +		/* set the mux and divider to safe frequency (400mhz) */
> +		ret = __mux_div_set_src_div(md, 4, 3);
> +
> +	return notifier_from_errno(ret);
> +}
> +
> +static int qcom_apcs_msm8916_clk_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device *parent = dev->parent;
> +	struct clk_regmap_mux_div *a53cc;
> +	struct regmap *regmap;
> +	struct clk_init_data init = { };
> +	int ret;
> +
> +	regmap = dev_get_regmap(parent, NULL);
> +	if (IS_ERR(regmap)) {
> +		ret = PTR_ERR(regmap);
> +		dev_err(dev, "failed to get regmap: %d\n", ret);
> +		return ret;
> +	}
> +
> +	a53cc = devm_kzalloc(dev, sizeof(*a53cc), GFP_KERNEL);
> +	if (!a53cc)
> +		return -ENOMEM;
> +
> +	init.name = "a53mux";
> +	init.parent_names = gpll0_a53cc;
> +	init.num_parents = ARRAY_SIZE(gpll0_a53cc);
> +	init.ops = &clk_regmap_mux_div_ops;
> +	init.flags = CLK_SET_RATE_PARENT;
> +
> +	a53cc->clkr.hw.init = &init;
> +	a53cc->clkr.regmap = regmap;
> +	a53cc->reg_offset = 0x50;
> +	a53cc->hid_width = 5;
> +	a53cc->hid_shift = 0;
> +	a53cc->src_width = 3;
> +	a53cc->src_shift = 8;
> +	a53cc->parent_map = gpll0_a53cc_map;
> +
> +	a53cc->pclk = devm_clk_get(parent, NULL);
> +	if (IS_ERR(a53cc->pclk)) {
> +		ret = PTR_ERR(a53cc->pclk);
> +		dev_err(dev, "failed to get clk: %d\n", ret);
> +		return ret;
> +	}
> +
> +	a53cc->clk_nb.notifier_call = a53cc_notifier_cb;
> +	ret = clk_notifier_register(a53cc->pclk, &a53cc->clk_nb);
> +	if (ret) {
> +		dev_err(dev, "failed to register clock notifier: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = devm_clk_register_regmap(dev, &a53cc->clkr);
> +	if (ret) {
> +		dev_err(dev, "failed to register regmap clock: %d\n", ret);
> +		goto err;
> +	}
> +
> +	ret = of_clk_add_hw_provider(parent->of_node, of_clk_hw_simple_get,
> +				     &a53cc->clkr.hw);
> +	if (ret) {
> +		dev_err(dev, "failed to add clock provider: %d\n", ret);
> +		goto err;
> +	}
> +
> +	platform_set_drvdata(pdev, a53cc);
> +
> +	return 0;
> +
> +err:
> +	clk_notifier_unregister(a53cc->pclk, &a53cc->clk_nb);
> +	return ret;
> +}
> +
> +static int qcom_apcs_msm8916_clk_remove(struct platform_device *pdev)
> +{
> +	struct clk_regmap_mux_div *a53cc = platform_get_drvdata(pdev);
> +	struct device *parent = pdev->dev.parent;
> +
> +	clk_notifier_unregister(a53cc->pclk, &a53cc->clk_nb);
> +	of_clk_del_provider(parent->of_node);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver qcom_apcs_msm8916_clk_driver = {
> +	.probe = qcom_apcs_msm8916_clk_probe,
> +	.remove = qcom_apcs_msm8916_clk_remove,
> +	.driver = {
> +		.name = "qcom-apcs-msm8916-clk",
> +	},
> +};
> +module_platform_driver(qcom_apcs_msm8916_clk_driver);
> +
> +MODULE_AUTHOR("Georgi Djakov <georgi.djakov@linaro.org>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Qualcomm MSM8916 APCS clock driver");
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
> This patchset adds support for the A53 CPU clock on MSM8916 platforms
> and allows scaling of the CPU frequency on msm8916 based platforms.

Though it currently needs some additional patches (that'll follow
soon), FWIW, Tested-by: Amit Kucheria <amit.kucheria@linaro.org>

> Changes since v10 (https://lkml.org/lkml/2017/12/1/577)
> * Addressed Bjorn's comments on APCS clock driver.
> * Picked Acks from Rob and Bjorn.
>
> Changes since v9 (https://lkml.org/lkml/2017/9/21/511)
> * Added the clock properties to the APCS DT node, instead of adding a subnode
> and also replaced patch "mailbox: qcom: Populate APCS child platform devices"
> with "mailbox: qcom: Create APCS child device for clock controller".
> * Dropped patch "mailbox: qcom: Move the apcs struct into a separate header",
> and use dev_get_regmap(dev->parent) in the child driver.
> * Addressed Bjorn's comments on a53-pll and apcs-clk drivers.
> * Added SPDX copyright identifiers.
>
> Changes since v8 (https://lkml.org/lkml/2017/6/23/476)
>  * Converted APCS mailbox driver to use regmap and to populate child
>  platform devices that will handle the rest of the functionality
>  provided by APCS block.
>  * Picked Rob's Ack for the PLL binding.
>  * Changed the APCS binding and put it into a separate patch.
>  * Addressed review comments.
>  * Minor changes.
>
> Changes since v7 (https://lkml.org/lkml/2016/10/31/296)
>  * Add the APCS clock controller to the APCS driver to expose both the
>  mailbox and clock controller functionality as discussed earlier:
>  https://lkml.org/lkml/2016/11/14/860
>  * Changed the a53pll compatible string as suggested by Rob.
>
> Changes since v6 (https://lkml.org/lkml/2016/9/7/347)
>  * Addressed various comments from Stephen Boyd
>
> Changes since v5 (https://lkml.org/lkml/2016/2/1/407)
>  * Rebase to clk-next and update according to the recent API changes.
>
> Changes since v4 (https://lkml.org/lkml/2015/12/14/367)
>  * Convert to builtin drivers as now __clk_lookup() is used
>
> Changes since v3 (https://lkml.org/lkml/2015/8/12/585)
>  * Split driver into two parts - and separate A53 PLL and
>    A53 clock controller drivers.
>  * Drop the safe switch hook patch. Add a clock notifier in
>    the clock provider to handle switching via safe mux and
>    divider configuration.
>
> Changes since v2 (https://lkml.org/lkml/2015/7/24/526)
>  * Drop gpll0_vote patch.
>  * Switch to the new clk_hw_* APIs.
>  * Rebase to the current clk-next.
>
> Changes since v1 (https://lkml.org/lkml/2015/6/12/193)
>  * Drop SR2 PLL patch, as it is already applied.
>  * Add gpll0_vote rate propagation patch.
>  * Update/rebase patches to the current clk-next.
>
> Georgi Djakov (6):
>   mailbox: qcom: Convert APCS IPC driver to use regmap
>   mailbox: qcom: Create APCS child device for clock controller
>   clk: qcom: Add A53 PLL support
>   clk: qcom: Add regmap mux-div clocks support
>   dt-bindings: mailbox: qcom: Document the APCS clock binding
>   clk: qcom: Add APCS clock controller support
>
>  .../devicetree/bindings/clock/qcom,a53pll.txt      |  22 ++
>  .../bindings/mailbox/qcom,apcs-kpss-global.txt     |  18 ++
>  drivers/clk/qcom/Kconfig                           |  21 ++
>  drivers/clk/qcom/Makefile                          |   3 +
>  drivers/clk/qcom/a53-pll.c                         | 110 ++++++++++
>  drivers/clk/qcom/apcs-msm8916.c                    | 149 ++++++++++++++
>  drivers/clk/qcom/clk-regmap-mux-div.c              | 229 +++++++++++++++++++++
>  drivers/clk/qcom/clk-regmap-mux-div.h              |  46 +++++
>  drivers/mailbox/qcom-apcs-ipc-mailbox.c            |  35 +++-
>  9 files changed, 628 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53pll.txt
>  create mode 100644 drivers/clk/qcom/a53-pll.c
>  create mode 100644 drivers/clk/qcom/apcs-msm8916.c
>  create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.c
>  create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.h
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Dec 05, 2017 at 05:46:55PM +0200, Georgi Djakov wrote:
> This patchset adds support for the A53 CPU clock on MSM8916 platforms
> and allows scaling of the CPU frequency on msm8916 based platforms.
> 
> Changes since v10 (https://lkml.org/lkml/2017/12/1/577)
> * Addressed Bjorn's comments on APCS clock driver.
> * Picked Acks from Rob and Bjorn.

Errr, really?

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Amit,

On 12/06/2017 07:51 AM, Amit Kucheria wrote:
> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
>> This patchset adds support for the A53 CPU clock on MSM8916 platforms
>> and allows scaling of the CPU frequency on msm8916 based platforms.
> 
> Though it currently needs some additional patches (that'll follow
> soon), FWIW, Tested-by: Amit Kucheria <amit.kucheria@linaro.org>

Thanks for testing! I will submit the platform specific dts changes as
separate follow-up patches when this is merged.

BR,
Georgi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 12/06/2017 11:08 PM, Rob Herring wrote:
> On Tue, Dec 05, 2017 at 05:46:55PM +0200, Georgi Djakov wrote:
>> This patchset adds support for the A53 CPU clock on MSM8916 platforms
>> and allows scaling of the CPU frequency on msm8916 based platforms.
>>
>> Changes since v10 (https://lkml.org/lkml/2017/12/1/577)
>> * Addressed Bjorn's comments on APCS clock driver.
>> * Picked Acks from Rob and Bjorn.
> 
> Errr, really?

Oops sorry, it was a Reviewed-by for the mailbox binding change and not
an Ack. Thank you for reviewing the constantly changing binding in this
patchset. I hope that it will not change anymore.

BR,
Georgi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 12/05, Georgi Djakov wrote:
> This patchset adds support for the A53 CPU clock on MSM8916 platforms
> and allows scaling of the CPU frequency on msm8916 based platforms.

Ok. I will apply just the clk ones? Patches 3,4, and 6?

On 22.12.17 г. 2:49, Stephen Boyd wrote:
> On 12/05, Georgi Djakov wrote:
>> This patchset adds support for the A53 CPU clock on MSM8916 platforms
>> and allows scaling of the CPU frequency on msm8916 based platforms.
> 
> Ok. I will apply just the clk ones? Patches 3,4, and 6?
> 

Yes, i think this would be best. The rest should go through the mailbox tree.
Jassi, are you ok with this?

Thanks,
Georgi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
> There is a clock controller functionality provided by the APCS hardware
> block of msm8916 devices. The device-tree would represent an APCS node
> with both mailbox and clock provider properties.
>
The spec might depict a 'clock' box and 'mailbox' box inside the
bigger APCS box. However, from the code I see in this patchset, they
are orthogonal and can & should be represented as independent DT
nodes.
Patch-1 is ok, though.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote:

> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
> > There is a clock controller functionality provided by the APCS hardware
> > block of msm8916 devices. The device-tree would represent an APCS node
> > with both mailbox and clock provider properties.
> >
> The spec might depict a 'clock' box and 'mailbox' box inside the
> bigger APCS box. However, from the code I see in this patchset, they
> are orthogonal and can & should be represented as independent DT
> nodes.

The APCS consists of a number of different hardware blocks, one of them
being the "APCS global" block, which is what this node and drivers
relate to. On 8916 this contains both the IPC register and clock
control. But it's still just one block according to the hardware
specification.

As such DT should describe the one hardware block by one node IMHO. The
fact that we in Linux split this into two different drivers is an
unrelated implementation detail.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 12/22, Georgi Djakov wrote:
> On 22.12.17 г. 2:49, Stephen Boyd wrote:
> > On 12/05, Georgi Djakov wrote:
> >> This patchset adds support for the A53 CPU clock on MSM8916 platforms
> >> and allows scaling of the CPU frequency on msm8916 based platforms.
> > 
> > Ok. I will apply just the clk ones? Patches 3,4, and 6?
> > 
> 
> Yes, i think this would be best. The rest should go through the mailbox tree.
> 

Ok. I made some changes. I'll comment one patch too. But I
applied them to clk-next.

On 12/05, Georgi Djakov wrote:
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include "clk-regmap.h"
> +#include "clk-regmap-mux-div.h"
> +
> +enum {
> +	P_GPLL0,
> +	P_A53PLL,
> +};

This is always 0, 1.

> +
> +static const struct parent_map gpll0_a53cc_map[] = {
> +	{ P_GPLL0, 4 },
> +	{ P_A53PLL, 5 },

And then this is not really doing much. So I wonder why we really
even need a parent_map? More like we need a map from parent_names
to mux number. We don't need to map some random enum into another
number space like we do for RCGs. I think we may have the same
problem with another qcom clk patch (see commit df964016490b in
clk-next). We really don't need the rcg version of parent_map in
either case, more like we just need a u8 *table (or u32
whatever), and then we're done. I'm going to make that change now
because otherwise we get into a mess with the parent_map stuff in
the other branch. I'll go clean up that too so we don't move
parent_map around.

On 12/05, Georgi Djakov wrote:
> Add support for hardware that can switch both parent clock and divider
> at the same time. This avoids generating intermediate frequencies from
> either the old parent clock and new divider or new parent clock and
> old divider combinations.
> 
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---

Applied to clk-next

Hi Bjorn,

On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote:
>
>> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
>> > There is a clock controller functionality provided by the APCS hardware
>> > block of msm8916 devices. The device-tree would represent an APCS node
>> > with both mailbox and clock provider properties.
>> >
>> The spec might depict a 'clock' box and 'mailbox' box inside the
>> bigger APCS box. However, from the code I see in this patchset, they
>> are orthogonal and can & should be represented as independent DT
>> nodes.
>
> The APCS consists of a number of different hardware blocks, one of them
> being the "APCS global" block, which is what this node and drivers
> relate to. On 8916 this contains both the IPC register and clock
> control. But it's still just one block according to the hardware
> specification.
>
> As such DT should describe the one hardware block by one node IMHO.
>
In my even humbler opinion, DT should describe a h/w functional unit
which _could_ be seen as a standalone component.
For example, if this APCS had a mac controller, would we also populate
a netdev from mailbox driver? And what if next revision moves/drops
this clock controller out of APCS, keeping mailbox controller exactly
same?

Maybe some DT maintainer could enlighten either of us.

Cheers!
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Jassi,

On 12/29/2017 08:14 AM, Jassi Brar wrote:
> Hi Bjorn,
> 
> On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
>> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote:
>>
>>> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>> There is a clock controller functionality provided by the APCS hardware
>>>> block of msm8916 devices. The device-tree would represent an APCS node
>>>> with both mailbox and clock provider properties.
>>>>
>>> The spec might depict a 'clock' box and 'mailbox' box inside the
>>> bigger APCS box. However, from the code I see in this patchset, they
>>> are orthogonal and can & should be represented as independent DT
>>> nodes.
>>
>> The APCS consists of a number of different hardware blocks, one of them
>> being the "APCS global" block, which is what this node and drivers
>> relate to. On 8916 this contains both the IPC register and clock
>> control. But it's still just one block according to the hardware
>> specification.
>>
>> As such DT should describe the one hardware block by one node IMHO.
>>
> In my even humbler opinion, DT should describe a h/w functional unit
> which _could_ be seen as a standalone component.

The APCS is one separate register block related to the CPU cluster. I
haven't seen any strict guidelines for such cases in the DT docs, and
during the discussion got the impression that this is the preferred
binding. Rob has also reviewed the binding, so we should be fine to move
forward with this one.

> For example, if this APCS had a mac controller, would we also populate
> a netdev from mailbox driver? And what if next revision moves/drops
> this clock controller out of APCS, keeping mailbox controller exactly
> same?

The clock controller may change in some next SoC architecture and that's
why the SoC version is also part of the the compatible string.

Thanks,
Georgi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 12/05/2017 05:46 PM, Georgi Djakov wrote:
> This patchset adds support for the A53 CPU clock on MSM8916 platforms
> and allows scaling of the CPU frequency on msm8916 based platforms.
> 
> Changes since v10 (https://lkml.org/lkml/2017/12/1/577)
> * Addressed Bjorn's comments on APCS clock driver.
> * Picked Acks from Rob and Bjorn.
> 
[..]
> 
> Georgi Djakov (6):
>   mailbox: qcom: Convert APCS IPC driver to use regmap
>   mailbox: qcom: Create APCS child device for clock controller
>   clk: qcom: Add A53 PLL support
>   clk: qcom: Add regmap mux-div clocks support
>   dt-bindings: mailbox: qcom: Document the APCS clock binding
>   clk: qcom: Add APCS clock controller support
> 

Hi Jassi,

Do you want me to re-send the pending mailbox patches?

Thanks,
Georgi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, Jan 4, 2018 at 10:26 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
> Hi Jassi,
>
> On 12/29/2017 08:14 AM, Jassi Brar wrote:
>> Hi Bjorn,
>>
>> On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson
>> <bjorn.andersson@linaro.org> wrote:
>>> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote:
>>>
>>>> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>>> There is a clock controller functionality provided by the APCS hardware
>>>>> block of msm8916 devices. The device-tree would represent an APCS node
>>>>> with both mailbox and clock provider properties.
>>>>>
>>>> The spec might depict a 'clock' box and 'mailbox' box inside the
>>>> bigger APCS box. However, from the code I see in this patchset, they
>>>> are orthogonal and can & should be represented as independent DT
>>>> nodes.
>>>
>>> The APCS consists of a number of different hardware blocks, one of them
>>> being the "APCS global" block, which is what this node and drivers
>>> relate to. On 8916 this contains both the IPC register and clock
>>> control. But it's still just one block according to the hardware
>>> specification.
>>>
>>> As such DT should describe the one hardware block by one node IMHO.
>>>
>> In my even humbler opinion, DT should describe a h/w functional unit
>> which _could_ be seen as a standalone component.
>
> The APCS is one separate register block related to the CPU cluster. I
> haven't seen any strict guidelines for such cases in the DT docs, and
> during the discussion got the impression that this is the preferred
> binding. Rob has also reviewed the binding, so we should be fine to move
> forward with this one.
>
Well, I can't overrule Rob. But I am really not happy with random
device spawning from mailbox drivers. I know there are such instances
already in the kernel but that doesn't make it legit... unless there
is some hard dependency. Is there?

>> For example, if this APCS had a mac controller, would we also populate
>> a netdev from mailbox driver? And what if next revision moves/drops
>> this clock controller out of APCS, keeping mailbox controller exactly
>> same?
>
> The clock controller may change in some next SoC architecture and that's
> why the SoC version is also part of the the compatible string.
>
So the mailbox driver will be updated to spawn yet another type of clock?
And again for next revision and so on... I know that is unlikely but
the point is why not have separate clock drivers for independent h/w
clocks?
I'll let Rob take the final call.

Cheers!
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Jassi,

On 01/27/2018 05:44 AM, Jassi Brar wrote:
> On Thu, Jan 4, 2018 at 10:26 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
>> Hi Jassi,
>>
>> On 12/29/2017 08:14 AM, Jassi Brar wrote:
>>> Hi Bjorn,
>>>
>>> On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson
>>> <bjorn.andersson@linaro.org> wrote:
>>>> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote:
>>>>
>>>>> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>>>> There is a clock controller functionality provided by the APCS hardware
>>>>>> block of msm8916 devices. The device-tree would represent an APCS node
>>>>>> with both mailbox and clock provider properties.
>>>>>>
>>>>> The spec might depict a 'clock' box and 'mailbox' box inside the
>>>>> bigger APCS box. However, from the code I see in this patchset, they
>>>>> are orthogonal and can & should be represented as independent DT
>>>>> nodes.
>>>>
>>>> The APCS consists of a number of different hardware blocks, one of them
>>>> being the "APCS global" block, which is what this node and drivers
>>>> relate to. On 8916 this contains both the IPC register and clock
>>>> control. But it's still just one block according to the hardware
>>>> specification.
>>>>
>>>> As such DT should describe the one hardware block by one node IMHO.
>>>>
>>> In my even humbler opinion, DT should describe a h/w functional unit
>>> which _could_ be seen as a standalone component.
>>
>> The APCS is one separate register block related to the CPU cluster. I
>> haven't seen any strict guidelines for such cases in the DT docs, and
>> during the discussion got the impression that this is the preferred
>> binding. Rob has also reviewed the binding, so we should be fine to move
>> forward with this one.
>>
> Well, I can't overrule Rob. But I am really not happy with random
> device spawning from mailbox drivers. I know there are such instances
> already in the kernel but that doesn't make it legit... unless there
> is some hard dependency. Is there?

The dependency is that on this SoC, these functionalities are combined
into this "CPU subsystem" block.

Initially APCS was a syscon and it was discussed it an year ago in this
mail thread [1] and we are trying to move away from the syscon and come
up with some bindings. During v8 and v9 of this patchset i have switched
from multiple child nodes to a single node as this seem to be the
preferred form.

>>> For example, if this APCS had a mac controller, would we also populate
>>> a netdev from mailbox driver? And what if next revision moves/drops
>>> this clock controller out of APCS, keeping mailbox controller exactly
>>> same?
>>
>> The clock controller may change in some next SoC architecture and that's
>> why the SoC version is also part of the the compatible string.
>>
> So the mailbox driver will be updated to spawn yet another type of clock?
> And again for next revision and so on... I know that is unlikely but
> the point is why not have separate clock drivers for independent h/w
> clocks?

Each revision re-shuffles the APCS block, so at least the offsets would
be different. I don't see anything bad with spawning a child device, but
what are the other options? Should we go back on the bindings and
suggest something new all over again? Or do you have any other idea?
Could you please explain your point further?

Thanks,
Georgi

[1] https://lkml.org/lkml/2017/3/20/991
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, Feb 1, 2018 at 12:10 AM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
>
> Hi Jassi,
>
> On 01/27/2018 05:44 AM, Jassi Brar wrote:
> > On Thu, Jan 4, 2018 at 10:26 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
> >> Hi Jassi,
> >>
> >> On 12/29/2017 08:14 AM, Jassi Brar wrote:
> >>> Hi Bjorn,
> >>>
> >>> On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson
> >>> <bjorn.andersson@linaro.org> wrote:
> >>>> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote:
> >>>>
> >>>>> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
> >>>>>> There is a clock controller functionality provided by the APCS hardware
> >>>>>> block of msm8916 devices. The device-tree would represent an APCS node
> >>>>>> with both mailbox and clock provider properties.
> >>>>>>
> >>>>> The spec might depict a 'clock' box and 'mailbox' box inside the
> >>>>> bigger APCS box. However, from the code I see in this patchset, they
> >>>>> are orthogonal and can & should be represented as independent DT
> >>>>> nodes.
> >>>>
> >>>> The APCS consists of a number of different hardware blocks, one of them
> >>>> being the "APCS global" block, which is what this node and drivers
> >>>> relate to. On 8916 this contains both the IPC register and clock
> >>>> control. But it's still just one block according to the hardware
> >>>> specification.
> >>>>
> >>>> As such DT should describe the one hardware block by one node IMHO.
> >>>>
> >>> In my even humbler opinion, DT should describe a h/w functional unit
> >>> which _could_ be seen as a standalone component.
> >>
> >> The APCS is one separate register block related to the CPU cluster. I
> >> haven't seen any strict guidelines for such cases in the DT docs, and
> >> during the discussion got the impression that this is the preferred
> >> binding. Rob has also reviewed the binding, so we should be fine to move
> >> forward with this one.
> >>
> > Well, I can't overrule Rob. But I am really not happy with random
> > device spawning from mailbox drivers. I know there are such instances
> > already in the kernel but that doesn't make it legit... unless there
> > is some hard dependency. Is there?
>
> The dependency is that on this SoC, these functionalities are combined
> into this "CPU subsystem" block.
>
I see the register space is shared between mailbox and the clock. So I
guess, yes, simply creating a device here and passing the common
regmap is tidier. Which patches are already picked up?

Cheers!
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 02/01/2018 08:57 AM, Jassi Brar wrote:
> On Thu, Feb 1, 2018 at 12:10 AM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>
>> Hi Jassi,
>>
>> On 01/27/2018 05:44 AM, Jassi Brar wrote:
>>> On Thu, Jan 4, 2018 at 10:26 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>> Hi Jassi,
>>>>
>>>> On 12/29/2017 08:14 AM, Jassi Brar wrote:
>>>>> Hi Bjorn,
>>>>>
>>>>> On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson
>>>>> <bjorn.andersson@linaro.org> wrote:
>>>>>> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote:
>>>>>>
>>>>>>> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>>>>>> There is a clock controller functionality provided by the APCS hardware
>>>>>>>> block of msm8916 devices. The device-tree would represent an APCS node
>>>>>>>> with both mailbox and clock provider properties.
>>>>>>>>
>>>>>>> The spec might depict a 'clock' box and 'mailbox' box inside the
>>>>>>> bigger APCS box. However, from the code I see in this patchset, they
>>>>>>> are orthogonal and can & should be represented as independent DT
>>>>>>> nodes.
>>>>>>
>>>>>> The APCS consists of a number of different hardware blocks, one of them
>>>>>> being the "APCS global" block, which is what this node and drivers
>>>>>> relate to. On 8916 this contains both the IPC register and clock
>>>>>> control. But it's still just one block according to the hardware
>>>>>> specification.
>>>>>>
>>>>>> As such DT should describe the one hardware block by one node IMHO.
>>>>>>
>>>>> In my even humbler opinion, DT should describe a h/w functional unit
>>>>> which _could_ be seen as a standalone component.
>>>>
>>>> The APCS is one separate register block related to the CPU cluster. I
>>>> haven't seen any strict guidelines for such cases in the DT docs, and
>>>> during the discussion got the impression that this is the preferred
>>>> binding. Rob has also reviewed the binding, so we should be fine to move
>>>> forward with this one.
>>>>
>>> Well, I can't overrule Rob. But I am really not happy with random
>>> device spawning from mailbox drivers. I know there are such instances
>>> already in the kernel but that doesn't make it legit... unless there
>>> is some hard dependency. Is there?
>>
>> The dependency is that on this SoC, these functionalities are combined
>> into this "CPU subsystem" block.
>>
> I see the register space is shared between mailbox and the clock. So I
> guess, yes, simply creating a device here and passing the common
> regmap is tidier. Which patches are already picked up?

Patches 3, 4 and 6 are already picked into the clk tree. Still pending
are patches 1, 2 and 5.

Thanks,
Georgi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html