* [PATCH 0/2] support USB2 PHY OTG port for rk3399
From: William Wu @ 2016-11-02 7:42 UTC (permalink / raw)
To: kishon, heiko
Cc: linux-kernel, linux-arm-kernel, linux-rockchip, devicetree,
robh+dt, frank.wang, huangtao, dianders, briannorris, groeck,
wulf
This series add support for rk3399 USB2 PHY0 and PHY1 OTG port.
rk3399 has two USB2 PHYs, and each USB2 PHY is comprised of one
Host port and one OTG port. We have supported Host port before,
and try to support OTG port now.
Test on rk3399-evb board.
William Wu (2):
phy: rockchip-inno-usb2: support otg-port for rk3399
arm64: dts: rockchip: add usb2-phy otg-port support for rk3399
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 21 ++
drivers/phy/phy-rockchip-inno-usb2.c | 609 +++++++++++++++++++++++++++++--
2 files changed, 599 insertions(+), 31 deletions(-)
--
2.0.0
^ permalink raw reply
* Re: [PATCH v2 0/5] ARM: dts: imx: update Boundary Devices boards support
From: Shawn Guo @ 2016-11-02 7:40 UTC (permalink / raw)
To: Gary Bisson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
fabio.estevam-KZfg59tc24xl57MIdRCFDg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-lFZ/pmaqli7XmaaqVzeoHQ
In-Reply-To: <20161101171006.24594-1-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
On Tue, Nov 01, 2016 at 06:10:01PM +0100, Gary Bisson wrote:
> Gary Bisson (5):
> ARM: dts: imx: add Boundary Devices Nitrogen6_SOM2 support
> ARM: dts: imx6qdl-sabrelite: use hyphens for nodes name
> ARM: dts: imx6qdl-nitrogen6x: use hyphens for nodes name
> ARM: dts: imx6qdl-nit6xlite: use hyphens for nodes name
> ARM: dts: imx6qdl-nitrogen6_max: use hyphens for nodes name
Applied all, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] ARM: dts: imx: add Boundary Devices Nitrogen6_SOM2 support
From: Shawn Guo @ 2016-11-02 7:35 UTC (permalink / raw)
To: Gary Bisson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer, Rob Herring,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Russell King
In-Reply-To: <CAAMH-yugLeHjaSwMx9ZoJ9qm44VKXcgO64xdsO=HBj59pj5cUA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Nov 01, 2016 at 03:54:31PM +0100, Gary Bisson wrote:
> Hi Shawn,
>
> On Tue, Nov 1, 2016 at 3:13 PM, Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Tue, Oct 25, 2016 at 11:19:51PM +0200, Gary Bisson wrote:
> >> SoM based on i.MX6 Quad with 1GB of DDR3.
> >>
> >> https://boundarydevices.com/product/nit6x-som-v2/
> >>
> >> Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
> >> ---
> >> arch/arm/boot/dts/Makefile | 1 +
> >> arch/arm/boot/dts/imx6q-nitrogen6_som2.dts | 53 ++
> >> arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 770 ++++++++++++++++++++++++++
> >> 3 files changed, 824 insertions(+)
> >> create mode 100644 arch/arm/boot/dts/imx6q-nitrogen6_som2.dts
> >> create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
> >
> > <snip>
> >
> >> +/ {
> >> + chosen {
> >> + stdout-path = &uart2;
> >> + };
> >> +
> >> + memory {
> >> + reg = <0x10000000 0x40000000>;
> >> + };
> >> +
> >> + backlight_lcd: backlight_lcd {
> >
> > Please use hyphen instead of underscore in node name. Please check
> > through the patch series.
>
> Sorry about that, forgot (again). Just to make sure, the label can
> have underscore but not the name right? Or is it better to have hypens
> everywhere?
Hyphen cannot be used in labels. Otherwise, DTC will complain.
> So I guess I need to make a pass on current boards as well.
I'm fine with the current boards and only expect it to be right with the
boards to be added.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
From: Vivek Gautam @ 2016-11-02 7:27 UTC (permalink / raw)
To: Rob Herring
Cc: kishon, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161026211819.kwlx56ic5cmahwjm@rob-hp-laptop>
On Thu, Oct 27, 2016 at 2:48 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Oct 19, 2016 at 04:13:47PM +0530, Vivek Gautam wrote:
>> Qualcomm SOCs have QMP phy controller that provides support
>> to a number of controller, viz. PCIe, UFS, and USB.
>> Add a new driver, based on generic phy framework, for this
>> phy controller.
>>
>> USB3-phy changes: Based on phy-msm-ssusb-qmp driver available on
>> msm-4.4 kernel @codeaurora[1].
>> PCIe-phy changes: Based on msm8996-pcie-phy driver posted by
>> Srinivas [2].
>>
>> [1] https://source.codeaurora.org/quic/la/kernel/msm-4.4/log/?h=caf/3.18/msm-3.18
>> [2] https://patchwork.kernel.org/patch/9318947/
>>
>> Signed-off-by: Vivek Gautam <vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Cc: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
>> ---
>> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 61 ++
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks Rob.
Regards
Vivek
--
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
From: Vivek Gautam @ 2016-11-02 7:26 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: kishon, robh+dt, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <a969a6be-472d-a463-790b-1e2f373d19b2-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Srini,
On Wed, Oct 26, 2016 at 7:27 PM, Srinivas Kandagatla
<srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Hi Vivek,
>
> Thanks for consolidating qmp phy support for both usb and pcie.
On vacation, so responses are bit late. Please bear with me.
>
> On 19/10/16 11:43, Vivek Gautam wrote:
>>
>> Qualcomm SOCs have QMP phy controller that provides support
>> to a number of controller, viz. PCIe, UFS, and USB.
>> Add a new driver, based on generic phy framework, for this
>> phy controller.
>>
>> USB3-phy changes: Based on phy-msm-ssusb-qmp driver available on
>> msm-4.4 kernel @codeaurora[1].
>> PCIe-phy changes: Based on msm8996-pcie-phy driver posted by
>> Srinivas [2].
>>
>> [1]
>> https://source.codeaurora.org/quic/la/kernel/msm-4.4/log/?h=caf/3.18/msm-3.18
>> [2] https://patchwork.kernel.org/patch/9318947/
>>
>> Signed-off-by: Vivek Gautam <vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Cc: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
>
>
> very few minor nits which needs fixing in next version.
>
> I have tested this patch on DB820c PCIE with ethernet and SATA ports.
>
> Tested-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Thanks for testing the patch.
>
>
>> ---
>> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 61 ++
>> drivers/phy/Kconfig | 8 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-qcom-qmp.c | 1154
>> ++++++++++++++++++++
>> 4 files changed, 1224 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> create mode 100644 drivers/phy/phy-qcom-qmp.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> new file mode 100644
>> index 0000000..90214aa
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> @@ -0,0 +1,61 @@
>> +Qualcomm QMP PHY
>> +----------------
>> +
>> +QMP phy controller supports physical layer functionality for a number of
>> +controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
>> +
>> +Required properties:
>> + - compatible: compatible list, contains:
>> + "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
>> + "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
>> + - reg: offset and length of the PHY register set.
>> + - #phy-cells: must be 1
>> + - Cell after phy phandle should be the port (lane) number.
>> + - clocks: a list of phandles and clock-specifier pairs,
>> + one for each entry in clock-names.
>> + - clock-names: must be "cfg_ahb" for phy config clock,
>> + "aux" for phy aux clock,
>> + "ref_clk" for 19.2 MHz ref clk,
>> + "ref_clk_src" for reference clock source,
>> + "pipe<port-number>" for pipe clock specific to
>> + each port/lane (Optional).
>
>
>> + - resets: a list of phandles and reset controller specifier pairs,
>> + one for each entry in reset-names.
>> + - reset-names: must be "phy" for reset of phy block,
>> + "common" for phy common block reset,
>> + "cfg" for phy's ahb cfg block reset (Optional).
>> + "port<port-number>" for reset specific to
>> + each port/lane. (Optional)
>> + - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
>> + - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll
>> block.
>> +
>> +Optional properties:
>> + - vddp-ref-clk-supply: Phandle to a regulator supply to any specific
>> refclk
>> + pll block.
>> +
>> +Example:
>> + pcie_phy: pciephy@34000 {
>> + compatible = "qcom,qmp-14nm-pcie-phy";
>
>
> Fix this according to the compatibilities listed above.
Sure, will fix this.
>
>
>> + reg = <0x034000 0x3fff>;
>> + #phy-cells = <1>;
>> +
>> + clocks = <&gcc GCC_PCIE_PHY_AUX_CLK>,
>> + <&gcc GCC_PCIE_PHY_CFG_AHB_CLK>,
>> + <&gcc GCC_PCIE_0_PIPE_CLK>,
>> + <&gcc GCC_PCIE_1_PIPE_CLK>,
>> + <&gcc GCC_PCIE_2_PIPE_CLK>;
>> + clock-names = "aux", "cfg_ahb",
>> + "pipe0", "pipe1", "pipe2";
>> +
>> + vdda-phy-supply = <&pm8994_l28>;
>> + vdda-pll-supply = <&pm8994_l12>;
>> +
>> + resets = <&gcc GCC_PCIE_PHY_BCR>,
>> + <&gcc GCC_PCIE_PHY_COM_BCR>,
>> + <&gcc GCC_PCIE_PHY_COM_NOCSR_BCR>,
>> + <&gcc GCC_PCIE_0_PHY_BCR>,
>> + <&gcc GCC_PCIE_1_PHY_BCR>,
>> + <&gcc GCC_PCIE_2_PHY_BCR>;
>> + reset-names = "phy", "common", "cfg",
>> + "lane0", "lane1", "lane2";
>> + };
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 5547984..d5e2b50f 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -446,6 +446,14 @@ config PHY_STIH41X_USB
>> Enable this to support the USB transceiver that is part of
>> STMicroelectronics STiH41x SoC series.
>>
>> +config PHY_QCOM_QMP
>> + tristate "Qualcomm QMP PHY Driver"
>> + depends on OF && (ARCH_QCOM || COMPILE_TEST)
>> + select GENERIC_PHY
>> + help
>> + Enable this to support the QMP PHY transceiver that is used
>> + with controllers such as PCIe, UFS, and USB on Qualcomm chips.
>> +
>> config PHY_QCOM_QUSB2
>> tristate "Qualcomm QUSB2 PHY Driver"
>> depends on OF && (ARCH_QCOM || COMPILE_TEST)
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 848489d..fde9fba 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -51,6 +51,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) +=
>> phy-spear1340-miphy.o
>> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
>> obj-$(CONFIG_PHY_STIH407_USB) += phy-stih407-usb.o
>> obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
>> +obj-$(CONFIG_PHY_QCOM_QMP) += phy-qcom-qmp.o
>> obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o
>> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
>> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
>> diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c
>> new file mode 100644
>> index 0000000..7e89179
>> --- /dev/null
>> +++ b/drivers/phy/phy-qcom-qmp.c
>> @@ -0,0 +1,1154 @@
>> +/*
>> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/phy/phy.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regulator/consumer.h>
>> +#include <linux/reset.h>
>> +#include <linux/slab.h>
>> +
>> +#include <dt-bindings/phy/phy.h>
>
> We would not need this once you have proper flags in cfg.
We can probably use the PHY_TYPE_{*} macros for pipe_clk.
Please see my comments in the related section below.
>
>
>> +
>> +
>> +static inline void qphy_setbits(u32 bitmask, void __iomem *reg)
>> +{
>> + u32 val;
>> +
>> + val = readl_relaxed(reg);
>> + val |= bitmask;
>> + writel_relaxed(val, reg);
>> +}
>> +
>> +static inline void qphy_clrbits(u32 bitmask, void __iomem *reg)
>> +{
>> + u32 val;
>> +
>> + val = readl_relaxed(reg);
>> + val &= ~bitmask;
>> + writel_relaxed(val, reg);
>> +}
>> +
>> +unsigned int msm8996_pciephy_tx_offsets[] = { 0x1000, 0x2000, 0x3000 };
>> +unsigned int msm8996_pciephy_rx_offsets[] = { 0x1200, 0x2200, 0x3200 };
>> +unsigned int msm8996_pciephy_pcs_offsets[] = { 0x1400, 0x2400, 0x3400 };
>> +
>> +unsigned int msm8996_usb3phy_tx_offsets[] = { 0x200 };
>> +unsigned int msm8996_usb3phy_rx_offsets[] = { 0x400 };
>> +unsigned int msm8996_usb3phy_pcs_offsets[] = { 0x600 };
>> +
>> +const struct qmp_phy_init_cfg pciephy_init_cfg = {
>> + .type = PHY_TYPE_PCIE,
>> + .nlanes = 3,
>> + .tx_offsets = msm8996_pciephy_tx_offsets,
>> + .rx_offsets = msm8996_pciephy_rx_offsets,
>> + .pcs_offsets = msm8996_pciephy_pcs_offsets,
>> +
>> + .phy_init_serdes_tbl = pciephy_serdes_init_tbl,
>> + .phy_init_serdes_tbl_sz = ARRAY_SIZE(pciephy_serdes_init_tbl),
>> + .phy_init_tx_tbl = pciephy_tx_init_tbl,
>> + .phy_init_tx_tbl_sz = ARRAY_SIZE(pciephy_tx_init_tbl),
>> + .phy_init_rx_tbl = pciephy_rx_init_tbl,
>> + .phy_init_rx_tbl_sz = ARRAY_SIZE(pciephy_rx_init_tbl),
>> + .phy_init_pcs_tbl = pciephy_pcs_init_tbl,
>> + .phy_init_pcs_tbl_sz = ARRAY_SIZE(pciephy_pcs_init_tbl),
>> + .has_phy_com_ctrl = true,
>> + .regs = pciephy_regs_layout,
>> + .mask_start_ctrl = (PHY_PCS_START | PHY_PLL_READY_GATE_EN),
>> + .mask_pwr_dn_ctrl = (PHY_SW_PWRDN | PHY_REFCLK_DRV_DSBL),
>> +};
>> +
>> +const struct qmp_phy_init_cfg usb3phy_init_cfg = {
>> + .type = PHY_TYPE_USB3,
>> + .nlanes = 1,
>> + .tx_offsets = msm8996_usb3phy_tx_offsets,
>> + .rx_offsets = msm8996_usb3phy_rx_offsets,
>> + .pcs_offsets = msm8996_usb3phy_pcs_offsets,
>> +
>> + .phy_init_serdes_tbl = usb3phy_serdes_init_tbl,
>> + .phy_init_serdes_tbl_sz = ARRAY_SIZE(usb3phy_serdes_init_tbl),
>> + .phy_init_tx_tbl = usb3phy_tx_init_tbl,
>> + .phy_init_tx_tbl_sz = ARRAY_SIZE(usb3phy_tx_init_tbl),
>> + .phy_init_rx_tbl = usb3phy_rx_init_tbl,
>> + .phy_init_rx_tbl_sz = ARRAY_SIZE(usb3phy_rx_init_tbl),
>> + .phy_init_pcs_tbl = usb3phy_pcs_init_tbl,
>> + .phy_init_pcs_tbl_sz = ARRAY_SIZE(usb3phy_pcs_init_tbl),
>> + .regs = usb3phy_regs_layout,
>> + .mask_start_ctrl = (PHY_SERDES_START | PHY_PCS_START),
>> + .mask_pwr_dn_ctrl = PHY_SW_PWRDN,
>> +};
>> +
>> +static void qcom_qmp_phy_configure(void __iomem *base,
>> + unsigned int *regs_layout,
>> + struct qmp_phy_init_tbl init_tbl[],
>> + int init_tbl_sz)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < init_tbl_sz; i++) {
>> + if (init_tbl[i].in_layout)
>> + writel_relaxed(init_tbl[i].cfg_val,
>> + base +
>> regs_layout[init_tbl[i].reg_offset]);
>> + else
>> + writel_relaxed(init_tbl[i].cfg_val,
>> + base + init_tbl[i].reg_offset);
>> + }
>> +
>> + /* flush buffered writes */
>> + mb();
>> +}
>> +
>> +static int qcom_qmp_phy_poweron(struct phy *phy)
>> +{
>> + struct qmp_phy_desc *phydesc = phy_get_drvdata(phy);
>> + struct qcom_qmp_phy *qphy = phydesc->qphy;
>> + int ret;
>> +
>> + dev_info(&phy->dev, "Powering on QMP phy\n");
>> +
>> + ret = regulator_enable(qphy->vdda_phy);
>> + if (ret) {
>> + dev_err(qphy->dev, "%s: vdda-phy enable failed, err=%d\n",
>> + __func__, ret);
>> + return ret;
>> + }
>> +
>> + ret = regulator_enable(qphy->vdda_pll);
>> + if (ret) {
>> + dev_err(qphy->dev, "%s: vdda-pll enable failed, err=%d\n",
>> + __func__, ret);
>> + goto err_vdda_pll;
>> + }
>> +
>> + if (qphy->vddp_ref_clk) {
>> + ret = regulator_enable(qphy->vddp_ref_clk);
>> + if (ret) {
>> + dev_err(qphy->dev, "%s: vdda-ref-clk enable
>> failed, err=%d\n",
>> + __func__, ret);
>> + goto err_vddp_refclk;
>> + }
>> + }
>> +
>> + if (!qphy->clk_enabled) {
>> + clk_prepare_enable(qphy->ref_clk_src);
>> + clk_prepare_enable(qphy->ref_clk);
>> + clk_prepare_enable(phydesc->pipe_clk);
>> + qphy->clk_enabled = true;
>> + }
>> +
>> + return 0;
>> +
>> +err_vddp_refclk:
>> + regulator_disable(qphy->vdda_pll);
>> +err_vdda_pll:
>> + regulator_disable(qphy->vdda_phy);
>> + return ret;
>> +}
>> +
>> +static int qcom_qmp_phy_poweroff(struct phy *phy)
>> +{
>> + struct qmp_phy_desc *phydesc = phy_get_drvdata(phy);
>> + struct qcom_qmp_phy *qphy = phydesc->qphy;
>> +
>> + if (qphy->clk_enabled) {
>> + clk_disable_unprepare(qphy->ref_clk_src);
>> + clk_disable_unprepare(qphy->ref_clk);
>> + clk_disable_unprepare(phydesc->pipe_clk);
>> + qphy->clk_enabled = false;
>> + }
>> +
>> + if (qphy->vddp_ref_clk)
>> + regulator_disable(qphy->vddp_ref_clk);
>> +
>> + regulator_disable(qphy->vdda_pll);
>> + regulator_disable(qphy->vdda_phy);
>> +
>> + return 0;
>> +}
>> +
>> +static int qcom_qmp_phy_is_ready(struct qcom_qmp_phy *qphy,
>> + void __iomem *pcs_status, u32 mask)
>> +{
>> + unsigned int init_timeout;
>> +
>> + init_timeout = PHY_READY_TIMEOUT_COUNT;
>> + do {
>> + if (readl_relaxed(pcs_status) & mask)
>> + break;
>> +
>> + usleep_range(REFCLK_STABILIZATION_DELAY_US_MIN,
>> + REFCLK_STABILIZATION_DELAY_US_MAX);
>> + } while (--init_timeout);
>> +
>> + if (!init_timeout)
>> + return -EBUSY;
>> +
>> + return 0;
>> +}
>> +
>> +static int qcom_qmp_phy_com_init(struct qcom_qmp_phy *qphy)
>> +{
>> + const struct qmp_phy_init_cfg *cfg = qphy->cfg;
>> + void __iomem *serdes = qphy->serdes;
>> + int ret;
>> +
>> + mutex_lock(&qphy->phy_mutex);
>> + if (qphy->init_count++) {
>> + mutex_unlock(&qphy->phy_mutex);
>> + return 0;
>> + }
>> +
>> + ret = reset_control_deassert(qphy->phy_rst);
>> + if (ret) {
>> + dev_err(qphy->dev, "phy reset deassert failed\n");
>
> mutex unlock
Yes, will add one.
>
>> + return ret;
>> + }
>> +
>> + ret = reset_control_deassert(qphy->phycom_rst);
>> + if (ret) {
>> + dev_err(qphy->dev, "common reset deassert failed\n");
>> + goto err_phycom_rst;
>> + }
>> +
>> + if (qphy->phycfg_rst) {
>> + ret = reset_control_deassert(qphy->phycfg_rst);
>> + if (ret) {
>> + dev_err(qphy->dev, "common reset deassert
>> failed\n");
>> + goto err_phycfg_rst;
>> + }
>> + }
>> +
>> + if (cfg->has_phy_com_ctrl) {
>> + qphy_setbits(PHY_SW_PWRDN,
>> + serdes + cfg->regs[QPHY_COM_POWER_DOWN_CONTROL]);
>> + /* Make sure that above write is completed */
>> + mb();
>> + }
>> +
>> + /* Serdes configuration */
>> + qcom_qmp_phy_configure(serdes, cfg->regs,
>> cfg->phy_init_serdes_tbl,
>> + cfg->phy_init_serdes_tbl_sz);
>> +
>> + if (cfg->has_phy_com_ctrl) {
>> + qphy_clrbits(PHY_SW_RESET, serdes +
>> + cfg->regs[QPHY_COM_SW_RESET]);
>> + qphy_setbits(PHY_SERDES_START | PHY_PCS_START,
>> + serdes +
>> cfg->regs[QPHY_COM_START_CONTROL]);
>> + /* Make sure that above write is completed */
>> + mb();
>> +
>> + ret = qcom_qmp_phy_is_ready(qphy, serdes +
>> +
>> cfg->regs[QPHY_COM_PCS_READY_STATUS],
>> + MASK_COM_PCS_READY);
>> + if (ret) {
>> + dev_err(qphy->dev,
>> + "common control block init timed-out\n");
>> + goto err_phy_comctrl;
>> + }
>> + }
>> +
>> + mutex_unlock(&qphy->phy_mutex);
>> +
>> + return 0;
>> +
>> +err_phy_comctrl:
>
> mutex unlock
Right, here as well.
>
>> + if (qphy->phycfg_rst)
>> + reset_control_assert(qphy->phycfg_rst);
>> +err_phycfg_rst:
>> + reset_control_assert(qphy->phycom_rst);
>> +err_phycom_rst:
>> + reset_control_assert(qphy->phy_rst);
>> + return ret;
>> +}
>> +
>> +static int qcom_qmp_phy_com_exit(struct qcom_qmp_phy *qphy)
>> +{
>> + const struct qmp_phy_init_cfg *cfg = qphy->cfg;
>> + void __iomem *serdes = qphy->serdes;
>> +
>> + mutex_lock(&qphy->phy_mutex);
>> + if (--qphy->init_count) {
>> + mutex_unlock(&qphy->phy_mutex);
>> + return 0;
>> + }
>> +
>> + if (cfg->has_phy_com_ctrl) {
>> + qphy_setbits(PHY_SERDES_START | PHY_PCS_START,
>> + serdes +
>> cfg->regs[QPHY_COM_START_CONTROL]);
>> + qphy_clrbits(PHY_SW_RESET, serdes +
>> + cfg->regs[QPHY_COM_SW_RESET]);
>> + qphy_setbits(PHY_SW_PWRDN,
>> + serdes + cfg->regs[QPHY_COM_POWER_DOWN_CONTROL]);
>> +
>> + /* Make sure that above writes are completed */
>> + mb();
>> + }
>> +
>> + reset_control_assert(qphy->phy_rst);
>> + reset_control_assert(qphy->phycom_rst);
>> + if (qphy->phycfg_rst)
>> + reset_control_assert(qphy->phycfg_rst);
>> +
>> + mutex_unlock(&qphy->phy_mutex);
>> +
>> + return 0;
>> +}
>> +
>> +/* PHY Initialization */
>> +static int qcom_qmp_phy_init(struct phy *phy)
>> +{
>> + struct qmp_phy_desc *phydesc = phy_get_drvdata(phy);
>> + struct qcom_qmp_phy *qphy = phydesc->qphy;
>> + const struct qmp_phy_init_cfg *cfg = qphy->cfg;
>> + void __iomem *tx = phydesc->tx;
>> + void __iomem *rx = phydesc->rx;
>> + void __iomem *pcs = phydesc->pcs;
>> + int ret;
>> +
>> + dev_info(qphy->dev, "Initializing QMP phy\n");
>> +
>> + /* enable interface clocks to program phy */
>> + clk_prepare_enable(qphy->aux_clk);
>> + clk_prepare_enable(qphy->cfg_ahb_clk);
>> +
>> + ret = qcom_qmp_phy_com_init(qphy);
>> + if (ret)
>> + goto err;
>> +
>> + if (phydesc->lane_rst) {
>> + ret = reset_control_deassert(phydesc->lane_rst);
>> + if (ret) {
>> + dev_err(qphy->dev, "lane<%d> reset deassert
>> failed\n",
>> + phydesc->index);
>> + goto err_lane_rst;
>> + }
>> + }
>> +
>> + /* Tx, Rx, and PCS configurations */
>> + qcom_qmp_phy_configure(tx, cfg->regs, cfg->phy_init_tx_tbl,
>> + cfg->phy_init_tx_tbl_sz);
>> + qcom_qmp_phy_configure(rx, cfg->regs, cfg->phy_init_rx_tbl,
>> + cfg->phy_init_rx_tbl_sz);
>> + qcom_qmp_phy_configure(pcs, cfg->regs, cfg->phy_init_pcs_tbl,
>> + cfg->phy_init_pcs_tbl_sz);
>> +
>> + /*
>> + * Pull out PHY from POWER DOWN state:
>> + * This is active low enable signal to power-down PHY.
>> + */
>> + qphy_setbits(cfg->mask_pwr_dn_ctrl,
>> + pcs + QPHY_POWER_DOWN_CONTROL);
>> + /* XXX: 10 us delay; given in PCIE HPG only */
>> + usleep_range(POWER_DOWN_DELAY_US_MIN, POWER_DOWN_DELAY_US_MAX);
>> +
>> + /* start SerDes and Phy-Coding-Sublayer */
>> + qphy_setbits(cfg->mask_start_ctrl, pcs + QPHY_START_CTRL);
>> +
>> + /* Pull PHY out of reset state */
>> + qphy_clrbits(PHY_SW_RESET, pcs + QPHY_SW_RESET);
>> + /* Make sure that above writes are completed */
>> + mb();
>> +
>> + ret = qcom_qmp_phy_is_ready(qphy, pcs +
>> + cfg->regs[QPHY_PCS_READY_STATUS],
>> + MASK_PHYSTATUS);
>> + if (ret) {
>> + dev_err(qphy->dev, "phy initialization timed-out\n");
>> + goto err_pcs_ready;
>> + }
>> +
>> + return 0;
>> +
>> +err_pcs_ready:
>> + if (phydesc->lane_rst)
>> + reset_control_assert(phydesc->lane_rst);
>> +err_lane_rst:
>> + qcom_qmp_phy_com_exit(qphy);
>> +err:
>> + clk_disable_unprepare(qphy->cfg_ahb_clk);
>> + clk_disable_unprepare(qphy->aux_clk);
>> + return ret;
>> +}
>> +
>> +static int qcom_qmp_phy_exit(struct phy *phy)
>> +{
>> + struct qmp_phy_desc *phydesc = phy_get_drvdata(phy);
>> + struct qcom_qmp_phy *qphy = phydesc->qphy;
>> + const struct qmp_phy_init_cfg *cfg = qphy->cfg;
>> +
>> + /* PHY reset */
>> + qphy_setbits(PHY_SW_RESET, phydesc->pcs + QPHY_SW_RESET);
>> +
>> + /* stop SerDes and Phy-Coding-Sublayer */
>> + qphy_clrbits(cfg->mask_start_ctrl, phydesc->pcs +
>> QPHY_START_CTRL);
>> +
>> + /* Put PHY into POWER DOWN state: active low */
>> + qphy_clrbits(cfg->mask_pwr_dn_ctrl,
>> + phydesc->pcs + QPHY_POWER_DOWN_CONTROL);
>> +
>> + /* Make sure that above writes are completed */
>> + mb();
>> +
>> + if (phydesc->lane_rst)
>> + reset_control_assert(phydesc->lane_rst);
>> +
>> + qcom_qmp_phy_com_exit(qphy);
>> +
>> + clk_disable_unprepare(qphy->aux_clk);
>> + clk_disable_unprepare(qphy->cfg_ahb_clk);
>> +
>> + return 0;
>> +}
>> +
>> +
>> +static int qcom_qmp_phy_regulator_init(struct device *dev)
>> +{
>> + struct qcom_qmp_phy *qphy = dev_get_drvdata(dev);
>> + int ret = 0;
>> +
>> + qphy->vdda_phy = devm_regulator_get(dev, "vdda-phy");
>> + if (IS_ERR(qphy->vdda_phy)) {
>> + ret = PTR_ERR(qphy->vdda_phy);
>> + dev_err(dev, "failed to get vdda-phy, %d\n", ret);
>> + return ret;
>> + }
>> +
>> + qphy->vdda_pll = devm_regulator_get(dev, "vdda-pll");
>> + if (IS_ERR(qphy->vdda_pll)) {
>> + ret = PTR_ERR(qphy->vdda_pll);
>> + dev_err(dev, "failed to get vdda-pll, %d\n", ret);
>> + return ret;
>> + }
>> +
>> + /* optional regulator */
>> + qphy->vddp_ref_clk = devm_regulator_get(dev, "vddp-ref-clk");
>
>
> Should mention this in bindings too.
Right, missed this one. Will add.
>
>
>> + if (IS_ERR(qphy->vddp_ref_clk)) {
>> + ret = PTR_ERR(qphy->vddp_ref_clk);
>> + dev_info(dev, "failed to get vddp-ref-clk, %d\n", ret);
>> + qphy->vddp_ref_clk = NULL;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int qcom_qmp_phy_clk_init(struct device *dev)
>> +{
>> + struct qcom_qmp_phy *qphy = dev_get_drvdata(dev);
>> + int ret;
>> +
>> + qphy->aux_clk = devm_clk_get(dev, "aux");
>> + if (IS_ERR(qphy->aux_clk)) {
>> + ret = PTR_ERR(qphy->aux_clk);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev, "failed to get aux_clk\n");
>> + return ret;
>> + }
>> +
>> + qphy->cfg_ahb_clk = devm_clk_get(dev, "cfg_ahb");
>> + if (IS_ERR(qphy->cfg_ahb_clk)) {
>> + ret = PTR_ERR(qphy->cfg_ahb_clk);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev, "failed to get cfg_ahb_clk\n");
>> + return ret;
>> + }
>> +
>> + /*
>> + * ref_clk and ref_clk_src handles may not be available in
>> + * all hardwares. So we don't return error in these cases.
>> + */
>
>
> This thing has to be mentioned in the bindings too.
All current chips have and future chips will have these clocks available
with them. So, I think we can make these clocks mandatory (not Optional).
>
>
>> + qphy->ref_clk_src = devm_clk_get(dev, "ref_clk_src");
>> + if (IS_ERR(qphy->ref_clk_src)) {
>> + ret = PTR_ERR(qphy->ref_clk_src);
>> + if (ret != -EPROBE_DEFER) {
>> + qphy->ref_clk_src = NULL;
>> + dev_dbg(dev, "failed to get ref_clk_src\n");
>> + } else {
>> + return ret;
>> + }
>> + }
>> +
>> + qphy->ref_clk = devm_clk_get(dev, "ref_clk");
>> + if (IS_ERR(qphy->ref_clk)) {
>> + ret = PTR_ERR(qphy->ref_clk);
>> + if (ret != -EPROBE_DEFER) {
>> + qphy->ref_clk = NULL;
>> + dev_dbg(dev, "failed to get ref_clk\n");
>> + } else {
>> + return ret;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static struct phy *qcom_qmp_phy_xlate(struct device *dev,
>> + struct of_phandle_args *args)
>> +{
>> + struct qcom_qmp_phy *qphy = dev_get_drvdata(dev);
>> + int i;
>> +
>> + if (WARN_ON(args->args[0] >= qphy->cfg->nlanes))
>> + return ERR_PTR(-ENODEV);
>> +
>> + for (i = 0; i < qphy->cfg->nlanes; i++) {
>> + if (qphy->phys[i]->index == args->args[0])
>> + break;
>> + }
>> +
>> + if (i == qphy->cfg->nlanes)
>> + return ERR_PTR(-ENODEV);
>> +
>> + return qphy->phys[i]->phy;
>> +}
>> +
>> +static const struct phy_ops qcom_qmp_phy_gen_ops = {
>> + .init = qcom_qmp_phy_init,
>> + .exit = qcom_qmp_phy_exit,
>> + .power_on = qcom_qmp_phy_poweron,
>> + .power_off = qcom_qmp_phy_poweroff,
>> + .owner = THIS_MODULE,
>> +};
>> +
>> +static const struct of_device_id qcom_qmp_phy_of_match_table[] = {
>> + {
>> + .compatible = "qcom,msm8996-qmp-pcie-phy",
>> + .data = &pciephy_init_cfg,
>> + }, {
>> + .compatible = "qcom,msm8996-qmp-usb3-phy",
>> + .data = &usb3phy_init_cfg,
>> + },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(of, qcom_qmp_phy_of_match_table);
>> +
>> +static int qcom_qmp_phy_probe(struct platform_device *pdev)
>> +{
>> + struct qcom_qmp_phy *qphy;
>> + struct device *dev = &pdev->dev;
>> + struct device_node *child;
>> + struct phy_provider *phy_provider;
>> + struct resource *res;
>> + const struct of_device_id *match;
>> + void __iomem *base;
>> + int ret = 0;
>> + int id;
>> +
>> + qphy = devm_kzalloc(dev, sizeof(*qphy), GFP_KERNEL);
>> + if (!qphy)
>> + return -ENOMEM;
>
> new line
Ok.
>>
>> + qphy->dev = dev;
>> + dev_set_drvdata(dev, qphy);
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + return -ENODEV;
>
> new line
Sure,
>
>> + base = devm_ioremap_resource(dev, res);
>> + if (IS_ERR(base))
>> + return PTR_ERR(base);
>> +
>> + /* per PHY serdes; usually located at base address */
>> + qphy->serdes = base;
>> +
>> + mutex_init(&qphy->phy_mutex);
>> +
>> + /* Get the specific init parameters of QMP phy */
>> + match = of_match_node(qcom_qmp_phy_of_match_table, dev->of_node);
>> + qphy->cfg = match->data;
>> +
>> + ret = qcom_qmp_phy_clk_init(dev);
>> + if (ret) {
>> + dev_err(dev, "clock init failed\n");
>> + return ret;
>> + }
>> +
>> + ret = qcom_qmp_phy_regulator_init(dev);
>> + if (ret) {
>> + dev_err(dev, "regulator init failed\n");
>> + return ret;
>> + }
>> +
>> + qphy->phy_rst = devm_reset_control_get(dev, "phy");
>> + if (IS_ERR(qphy->phy_rst)) {
>> + dev_err(dev, "failed to get phy core reset\n");
>> + return PTR_ERR(qphy->phy_rst);
>> + }
>> +
>> + qphy->phycom_rst = devm_reset_control_get(dev, "common");
>> + if (IS_ERR(qphy->phycom_rst)) {
>> + dev_err(dev, "failed to get phy common reset\n");
>> + return PTR_ERR(qphy->phycom_rst);
>> + }
>> +
>> + qphy->phycfg_rst = devm_reset_control_get(dev, "cfg");
>> + if (IS_ERR(qphy->phycfg_rst)) {
>> + dev_err(dev, "failed to get phy ahb cfg reset\n");
>> + qphy->phycfg_rst = NULL;
>> + }
>> +
>> + qphy->phys = devm_kcalloc(dev, qphy->cfg->nlanes,
>> + sizeof(*qphy->phys), GFP_KERNEL);
>> + if (!qphy->phys)
>> + return -ENOMEM;
>> +
>> + for (id = 0; id < qphy->cfg->nlanes; id++) {
>> + struct phy *generic_phy;
>> + struct qmp_phy_desc *phy_desc;
>> + char prop_name[MAX_PROP_NAME];
>> +
>> + phy_desc = devm_kzalloc(dev, sizeof(*phy_desc),
>> GFP_KERNEL);
>> + if (!phy_desc) {
>> + ret = -ENOMEM;
>> + goto put_child;
>> + }
>> +
>> + phy_desc->tx = base + qphy->cfg->tx_offsets[id];
>> + phy_desc->rx = base + qphy->cfg->rx_offsets[id];
>> + phy_desc->pcs = base + qphy->cfg->pcs_offsets[id];
>> +
>> + /*
>> + * Get PHY's Pipe clock, if any; USB3 and PCIe are PIPE
>> + * based phys, so they essentially have pipe clock
>> + */
>> + memset(&prop_name, 0, sizeof(prop_name));
>> + snprintf(prop_name, MAX_PROP_NAME, "pipe%d", id);
>> + phy_desc->pipe_clk = devm_clk_get(dev, prop_name);
>> + if (IS_ERR(phy_desc->pipe_clk)) {
>> + if (qphy->cfg->type == PHY_TYPE_PCIE ||
>> + qphy->cfg->type == PHY_TYPE_USB3) {
>> + ret = PTR_ERR(phy_desc->pipe_clk);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev,
>> + "failed to get lane%d pipe_clk\n",
>> id);
>> + return ret;
>> + } else {
>> + phy_desc->pipe_clk = NULL;
>> + }
>> + }
>
>
> Do we need to really need phy type for this?
> You should proably make a flag in cfg to mark this rather then using phy
> type. Hopefully it will also simplify the logic.
The pipe clock is something that's specific to PCIe and USB3 type
phys (both are PIPE3 specs based phys). So i think it is okay
to use the PHY_TYPE_{*} macros here. Looks a bit cleaner rather
than having a cfg flag. No ?
Using PHY_TYPE_{*} macros will also keep the doors open to
other PHY types that are added at a later point in time.
>
>
>> +
>> + /* Get lane reset, if any */
>> + memset(&prop_name, 0, sizeof(prop_name));
>> + snprintf(prop_name, MAX_PROP_NAME, "lane%d", id);
>> + phy_desc->lane_rst = devm_reset_control_get(dev,
>> prop_name);
>> + if (IS_ERR(phy_desc->lane_rst)) {
>> + if (qphy->cfg->type == PHY_TYPE_PCIE) {
>> + dev_err(dev, "failed to get lane%d
>> reset\n",
>> +
>> id);
>> + ret = PTR_ERR(phy_desc->lane_rst);
>> + goto put_child;
>> + } else {
>> + phy_desc->lane_rst = NULL;
>> + }
>> + }
>
>
> Same comment as above.
Correct, here we can add the cfg flag as you suggested.
>
>
>
>> +
>> + generic_phy = devm_phy_create(dev, NULL,
>> &qcom_qmp_phy_gen_ops);
>> + if (IS_ERR(generic_phy)) {
>> + ret = PTR_ERR(generic_phy);
>> + dev_err(dev, "failed to create qphy %d\n", ret);
>> + goto put_child;
>> + }
>> +
>> + phy_desc->phy = generic_phy;
>> + phy_desc->index = id;
>> + phy_desc->qphy = qphy;
>> + phy_set_drvdata(generic_phy, phy_desc);
>> + qphy->phys[id] = phy_desc;
>> + }
>> +
>> + phy_provider = devm_of_phy_provider_register(dev,
>> qcom_qmp_phy_xlate);
>> + if (IS_ERR(phy_provider)) {
>> + ret = PTR_ERR(phy_provider);
>> + dev_err(dev, "failed to register qphy %d\n", ret);
>> + goto put_child;
>> + }
>> +
>> +put_child:
>> + of_node_put(child);
>> + return ret;
>> +}
>> +
>> +static struct platform_driver qcom_qmp_phy_driver = {
>> + .probe = qcom_qmp_phy_probe,
>> + .driver = {
>> + .name = "qcom_qmp_phy",
>> + .of_match_table =
>> of_match_ptr(qcom_qmp_phy_of_match_table),
>> + },
>> +};
>> +
>> +module_platform_driver(qcom_qmp_phy_driver);
>> +
>> +MODULE_AUTHOR("Vivek Gautam <vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>");
>> +MODULE_DESCRIPTION("Qualcomm QMP PHY driver");
>> +MODULE_LICENSE("GPL v2");
>>
>
Thanks
Vivek
--
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 3/3] clk: imx: clk-imx6ul: add clk support for imx6ull
From: Peter Chen @ 2016-11-02 6:45 UTC (permalink / raw)
To: Stephen Boyd
Cc: shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Fabio Estevam,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jacky Bai,
Peng Fan
In-Reply-To: <20161102001205.GA16026-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>
>On 11/01, Peter Chen wrote:
>> clks[IMX6UL_CLK_USDHC1] = imx_clk_gate2("usdhc1",
> "usdhc1_podf", base + 0x80, 2);
>> clks[IMX6UL_CLK_USDHC2] = imx_clk_gate2("usdhc2",
> "usdhc2_podf", base + 0x80, 4);
>> - clks[IMX6UL_CLK_SIM1] = imx_clk_gate2("sim1",
> "sim_sel", base + 0x80, 6);
>> - clks[IMX6UL_CLK_SIM2] = imx_clk_gate2("sim2",
> "sim_sel", base + 0x80, 8);
>> + if (clk_on_imx6ul()) {
>> + clks[IMX6UL_CLK_SIM1] = imx_clk_gate2("sim1",
> "sim_sel", base + 0x80, 6);
>> + clks[IMX6UL_CLK_SIM2] = imx_clk_gate2("sim2",
> "sim_sel", base + 0x80, 8);
>> + }
>> clks[IMX6UL_CLK_EIM] = imx_clk_gate2("eim",
> "eim_slow_podf", base + 0x80, 10);
>> clks[IMX6UL_CLK_PWM8] = imx_clk_gate2("pwm8",
> "perclk", base + 0x80, 16);
>> clks[IMX6UL_CLK_UART8_IPG] = imx_clk_gate2("uart8_ipg", "ipg",
> base + 0x80, 14);
>> @@ -430,6 +478,7 @@ static void __init imx6ul_clocks_init(struct device_node
>*ccm_node)
>> clk_set_rate(clks[IMX6UL_CLK_ENET_REF], 50000000);
>> clk_set_rate(clks[IMX6UL_CLK_ENET2_REF], 50000000);
>> clk_set_rate(clks[IMX6UL_CLK_CSI], 24000000);
>> + clk_set_rate(clks[IMX6UL_CLK_PLL3_PFD2], 320000000);
>
>Can you use assigned clock rates for this instead?
>
Thanks, I will move it to dts.
Peter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v2] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Wenyou.Yang-UWL1GkI3JZL3oGB3hsPCZA @ 2016-11-02 5:46 UTC (permalink / raw)
To: lkp-ral2JQCrhuEAvxtiuMwx3w
Cc: kbuild-all-JC7UmRfGjtg, nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-lFZ/pmaqli7XmaaqVzeoHQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <201611021345.WcgqcfPD%fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 2237 bytes --]
> -----Original Message-----
> From: kbuild test robot [mailto:lkp@intel.com]
> Sent: 2016Äê11ÔÂ2ÈÕ 13:28
> To: Wenyou Yang - A41535 <Wenyou.Yang@microchip.com>
> Cc: kbuild-all@01.org; Nicolas Ferre <nicolas.ferre@atmel.com>; Alexandre
> Belloni <alexandre.belloni@free-electrons.com>; Russell King
> <linux@arm.linux.org.uk>; Rob Herring <robh+dt@kernel.org>; Pawel Moll
> <pawel.moll@arm.com>; Mark Rutland <mark.rutland@arm.com>; Ian Campbell
> <ijc+devicetree@hellion.org.uk>; Kumar Gala <galak@codeaurora.org>; linux-
> kernel@vger.kernel.org; Wenyou Yang - A41535
> <Wenyou.Yang@microchip.com>; devicetree@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; Wenyou Yang - A41535
> <Wenyou.Yang@microchip.com>
> Subject: Re: [PATCH v2] ARM: at91/dt: add dts file for sama5d36ek CMP board
>
> Hi Wenyou,
>
> [auto build test ERROR on at91/at91-next] [also build test ERROR on v4.9-rc3
> next-20161028] [if your patch is applied to the wrong git tree, please drop us a
> note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Wenyou-Yang/ARM-at91-dt-add-
> dts-file-for-sama5d36ek-CMP-board/20161102-111152
> base: https://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git at91-
> next
> config: arm-at91_dt_defconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-
> tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm
>
> All errors (new ones prefixed by >>):
>
> >> Error: arch/arm/boot/dts/sama5d3xmb_cmp.dtsi:143.17-18 syntax error
> FATAL ERROR: Unable to parse input tree
Oh, this patch is based on the patch I sent before.
[PATCH] pinctrl: at91: add support for OUTPUT config
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/464354.html
I forgot adding this information.
Sorry.
Best Regards,
Wenyou Yang
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* Re: [PATCH v2 4/9] regulator: lp873x: Add support for populating input supply
From: Lokesh Vutla @ 2016-11-02 5:28 UTC (permalink / raw)
To: Rob Herring
Cc: Tony Lindgren, Linux OMAP Mailing List, Tero Kristo, Sekhar Nori,
Nishanth Menon, Device Tree Mailing List, Linux ARM Mailing List,
Lee Jones, Keerthy
In-Reply-To: <20161030204118.ojeetnxl5qsi6lp7@rob-hp-laptop>
On Monday 31 October 2016 02:11 AM, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 04:08:36PM +0530, Lokesh Vutla wrote:
>> In order to have a proper topology of regulators for a platform, each
>> registering regulator needs to populate supply_name field for identifying
>> its supply's name. Add supply_name field for lp873x regulators.
>>
>> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Cc: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
>> Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
>> drivers/regulator/lp873x-regulator.c | 1 +
>> 2 files changed, 9 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
>> index 52766c2..998837a 100644
>> --- a/Documentation/devicetree/bindings/mfd/lp873x.txt
>> +++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
>> @@ -7,6 +7,9 @@ Required properties:
>> - #gpio-cells: Should be two. The first cell is the pin number and
>> the second cell is used to specify flags.
>> See ../gpio/gpio.txt for more information.
>> + - xxx-in-supply: Phandle to parent supply node of each regulator
>> + populated under regulators node. xxx should match
>> + the supply_name populated in driver.
>
> The driver is irrelevant. This should reference a list in this document.
okay. See if the below updated patch is fine.
-----------------------------8<----------------------------8<----------------------------
>From 666f925423fa35c7bfcc77fa3c883cbea5d8ef8e Mon Sep 17 00:00:00 2001
From: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
Date: Wed, 21 Sep 2016 11:50:49 +0530
Subject: [PATCH v3] regulator: lp873x: Add support for populating input
supply
In order to have a proper topology of regulators for a platform, each
registering regulator needs to populate supply_name field for identifying
its supply's name. Add supply_name field for lp873x regulators.
Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
---
Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
drivers/regulator/lp873x-regulator.c | 1 +
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt
b/Documentation/devicetree/bindings/mfd/lp873x.txt
index 52766c2..ae9cf39 100644
--- a/Documentation/devicetree/bindings/mfd/lp873x.txt
+++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
@@ -7,6 +7,9 @@ Required properties:
- #gpio-cells: Should be two. The first cell is the pin number and
the second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
+ - xxx-in-supply: Phandle to parent supply node of each regulator
+ populated under regulators node. xxx can be
+ buck0, buck1, ldo0 or ldo1.
- regulators: List of child nodes that specify the regulator
initialization data.
Example:
@@ -17,6 +20,11 @@ pmic: lp8733@60 {
gpio-controller;
#gpio-cells = <2>;
+ buck0-in-supply = <&vsys_3v3>;
+ buck1-in-supply = <&vsys_3v3>;
+ ldo0-in-supply = <&vsys_3v3>;
+ ldo1-in-supply = <&vsys_3v3>;
+
regulators {
lp8733_buck0: buck0 {
regulator-name = "lp8733-buck0";
diff --git a/drivers/regulator/lp873x-regulator.c
b/drivers/regulator/lp873x-regulator.c
index e504b91..70e3df6 100644
--- a/drivers/regulator/lp873x-regulator.c
+++ b/drivers/regulator/lp873x-regulator.c
@@ -24,6 +24,7 @@
[_id] = { \
.desc = { \
.name = _name, \
+ .supply_name = _of "-in", \
.id = _id, \
.of_match = of_match_ptr(_of), \
.regulators_node = of_match_ptr("regulators"),\
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: kbuild test robot @ 2016-11-02 5:28 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, Nicolas Ferre, Alexandre Belloni,
Russell King, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Wenyou Yang,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wenyou Yang
In-Reply-To: <1478055958-8463-1-git-send-email-wenyou.yang-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]
Hi Wenyou,
[auto build test ERROR on at91/at91-next]
[also build test ERROR on v4.9-rc3 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Wenyou-Yang/ARM-at91-dt-add-dts-file-for-sama5d36ek-CMP-board/20161102-111152
base: https://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git at91-next
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/sama5d3xmb_cmp.dtsi:143.17-18 syntax error
FATAL ERROR: Unable to parse input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 21326 bytes --]
^ permalink raw reply
* Re: [PATCH V4] pinctrl: qcom: Add msm8994 pinctrl driver
From: Michael Scott @ 2016-11-02 5:15 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-gpio, linux-arm-msm, devicetree, linux-kernel,
Linus Walleij, Rob Herring, Mark Rutland, Andy Gross, David Brown,
Bjorn Andersson, Joonwoo Park, Jeremy McNicoll
In-Reply-To: <20161101235344.GX16026@codeaurora.org>
On 11/01/2016 04:53 PM, Stephen Boyd wrote:
> On 10/31, Michael Scott wrote:
>> +
>> +static const struct msm_pingroup msm8994_groups[] = {
>> + PINGROUP(0, blsp_spi1, blsp_uart1, blsp_uim1, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
> I see an hdmi_rcv group here after blsp_uim1. Please add it for
> this gpio.
Hi Stephen,
Thank you for reviewing the data-- this is really tedious stuff.
I'd like to make sure that we're both using tech data for msm8994. I
don't see the hdmi_rcv function at all in my docs.
>
>> + PINGROUP(1, blsp_spi1, blsp_uart1, blsp_uim1, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(2, blsp_spi1, blsp_uart1, blsp_i2c1, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(3, blsp_spi1, blsp_uart1, blsp_i2c1, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(4, blsp_spi2, blsp_uart2, blsp_uim2, qdss_cti_trig_out_b,
>> + NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(5, blsp_spi2, blsp_uart2, blsp_uim2, qdss_cti_trig_in_b, NA,
> The qdss_cti_* is in function 5 for both of these, not function
> 4.
These are indeed wrong, but my docs both show as function 7.
>
>> + NA, NA, NA, NA, NA, NA),
>> + PINGROUP(6, blsp_spi2, blsp_uart2, blsp_i2c2, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(7, blsp_spi2, blsp_uart2, blsp_i2c2, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(8, blsp_spi3, blsp_uart3, blsp_uim3, blsp_spi1_cs1, NA, NA,
>> + NA, NA, NA, NA, NA),
>> + PINGROUP(9, blsp_spi3, blsp_uart3, blsp_uim3, blsp_spi1_cs2, NA, NA,
>> + NA, NA, NA, NA, NA),
>> + PINGROUP(10, mdp_vsync, blsp_spi3, blsp_uart3, blsp_i2c3,
>> + blsp_spi1_cs3, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(11, mdp_vsync, blsp_spi3, blsp_uart3, blsp_i2c3,
>> + blsp_spi1_cs2, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(12, mdp_vsync, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(13, cam_mclk0, NA, NA, qdss_tracedata_b, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(14, cam_mclk1, NA, NA, qdss_tracedata_b, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(15, cam_mclk2, NA, qdss_tracedata_b, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(16, cam_mclk3, NA, qdss_tracedata_b, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(17, cci_i2c0, blsp_spi4, blsp_uart4, blsp_uim4, NA,
>> + qdss_tracedata_b, NA, NA, NA, NA, NA),
>> + PINGROUP(18, cci_i2c0, blsp_spi4, blsp_uart4, blsp_uim4, NA,
>> + qdss_tracedata_b, NA, NA, NA, NA, NA),
>> + PINGROUP(19, cci_i2c1, blsp_spi4, blsp_uart4, blsp_i2c4, NA,
>> + qdss_tracedata_b, NA, NA, NA, NA, NA),
>> + PINGROUP(20, cci_i2c1, blsp_spi4, blsp_uart4, blsp_i2c4, NA, NA, NA,
>> + NA, NA, NA, NA),
>> + PINGROUP(21, cci_timer0, blsp_spi5, blsp_uart5, blsp_uim5, NA,
>> + qdss_tracedata_b, NA, NA, NA, NA, NA),
>> + PINGROUP(22, cci_timer1, blsp_spi5, blsp_uart5, blsp_uim5, NA,
>> + qdss_tracedata_b, NA, NA, NA, NA, NA),
>> + PINGROUP(23, cci_timer2, blsp_spi5, blsp_uart5, blsp_i2c5, NA, NA,
>> + qdss_tracedata_b, NA, NA, NA, NA),
>> + PINGROUP(24, cci_timer3, cci_async_in1, blsp_spi5, blsp_uart5,
>> + blsp_i2c5, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(25, cci_timer4, cci_async_in2, blsp_spi6, blsp_uart6,
>> + blsp_uim6, NA, NA, qdss_tracedata_b, NA, NA, NA),
>> + PINGROUP(26, cci_async_in0, blsp_spi6, blsp_uart6, blsp_uim6, gp0_clk,
>> + NA, qdss_tracedata_b, NA, NA, NA, NA),
>> + PINGROUP(27, blsp_spi6, blsp_uart6, blsp_i2c6, gp1_clk,
>> + qdss_tracectl_a, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(28, blsp_spi6, blsp_uart6, blsp_i2c6, qdss_traceclk_a, NA,
>> + NA, NA, NA, NA, NA, NA),
>> + PINGROUP(29, gp_mn, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(30, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(31, hdmi_cec, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(32, hdmi_ddc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(33, hdmi_ddc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(34, hdmi_hpd, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(35, uim3, pci_e1, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(36, uim3, pci_e1, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(37, uim3, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(38, uim3, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(39, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(40, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(41, blsp_spi7, blsp_uart7, blsp_uim7, qdss_cti_trig_out_c,
>> + NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(42, blsp_spi7, blsp_uart7, blsp_uim7, qdss_cti_trig_in_c, NA,
>> + NA, NA, NA, NA, NA, NA),
>> + PINGROUP(43, blsp_spi7, blsp_uart7, blsp_i2c7, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(44, blsp_spi7, blsp_uart7, blsp_i2c7, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(45, blsp_spi8, blsp_uart8, blsp_uim8, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(46, blsp_spi8, blsp_uart8, blsp_uim8, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(47, blsp_spi8, blsp_uart8, blsp_i2c8, blsp_spi10_cs1, NA, NA,
>> + NA, NA, NA, NA, NA),
>> + PINGROUP(48, blsp_spi8, blsp_uart8, blsp_i2c8, blsp_spi10_cs2, NA, NA,
>> + NA, NA, NA, NA, NA),
>> + PINGROUP(49, uim2, blsp_spi9, blsp_uart9, blsp_uim9, NA, NA, NA, NA,
>> + NA, NA, NA),
>> + PINGROUP(50, uim2, blsp_spi9, blsp_uart9, blsp_uim9, NA, NA, NA, NA,
>> + NA, NA, NA),
>> + PINGROUP(51, uim2, blsp_spi9, blsp_uart9, blsp_i2c9, NA, NA, NA, NA,
>> + NA, NA, NA),
>> + PINGROUP(52, uim2, blsp_spi9, blsp_uart9, blsp_i2c9, NA, NA, NA, NA,
>> + NA, NA, NA),
>> + PINGROUP(53, uim4, pci_e0, blsp_spi10, blsp_uart10, blsp_uim10, NA,
>> + NA, NA, NA, qdss_tracedata_a, NA),
> qdss_tracedata_a is at function 8.
I show function 10 here.
>
>> + PINGROUP(54, uim4, pci_e0, blsp_spi10, blsp_uart10, blsp_uim10,
>> + gp_pdm0, NA, NA, NA, NA, qdss_tracedata_a),
> qdss_tracedata_a is at function 9.
And function 11 here.
>
>> + PINGROUP(55, uim4, blsp_spi10, blsp_uart10, blsp_i2c10, NA, NA, NA,
>> + NA, NA, qdss_cti_trig_in_a, NA),
> qdss_cti_trig_in_a is at function 8.
10 here for me.
>
>> + PINGROUP(56, uim4, blsp_spi10, blsp_uart10, blsp_i2c10, NA, NA, NA,
>> + NA, qdss_cti_trig_out_a, NA, NA),
> qdss_cti_trig_out_a is at function 7.
9 here for me.
>
>> + PINGROUP(57, qua_mi2s, gcc_gp_clk1, NA, NA, NA, NA, qdss_tracedata_b,
>> + NA, NA, NA, NA),
> qdss_tracedata_b is at function 5.
function 7 here.
>
>> + PINGROUP(58, qua_mi2s, gcc_gp_clk2, NA, NA, NA, NA, qdss_tracedata_b,
>> + NA, NA, NA, NA),
> qdss_tracedata_b is at function 5.
And function 7 here as well.
>
>> + PINGROUP(59, qua_mi2s, gcc_gp_clk3, NA, NA, NA, NA, NA, NA, NA, NA,
>> + NA),
>> + PINGROUP(60, qua_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(61, qua_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(62, qua_mi2s, blsp_spi2_cs1, NA, NA, NA, NA, NA, NA, NA, NA,
>> + NA),
>> + PINGROUP(63, qua_mi2s, blsp_spi2_cs2, gp_pdm2, NA, NA, NA, NA, NA,
>> + qdss_tracedata_a, NA, NA),
>> + PINGROUP(64, pri_mi2s, NA, NA, NA, NA, NA, qdss_tracedata_a, NA, NA,
>> + NA, NA),
>> + PINGROUP(65, pri_mi2s, NA, NA, NA, NA, NA, qdss_tracedata_a, NA, NA,
>> + NA, NA),
> qdss_tracedata_a is at function 5 for both of the above.
Both of these show function 7 for me.
>
>> + PINGROUP(66, pri_mi2s, blsp_spi2_cs3, NA, NA, NA, NA, NA,
>> + qdss_tracedata_a, NA, NA, NA),
>> + PINGROUP(67, pri_mi2s, blsp_spi10_cs1, NA, NA, NA, NA, NA,
>> + qdss_tracedata_a, NA, NA, NA),
> qdss_tracedata_a is at function 6 for both of the above.
Function 8 here.
>
>> + PINGROUP(68, pri_mi2s, blsp_spi10_cs2, NA, NA, NA, NA, NA, NA, NA, NA,
>> + NA),
>> + PINGROUP(69, spkr_mi2s, audio_ref_clk, NA, NA, NA, NA, NA, NA, NA, NA,
>> + NA),
>> + PINGROUP(70, slimbus, spkr_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(71, slimbus, spkr_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(72, spkr_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> Perahps *_mi2s should just be *_i2s here. I don't see any m except for
> mclk, which means master and sometimes there are sck for slaves
> here.
Good catch. Changing this to spkr_i2s.
>
>> + PINGROUP(73, ter_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(74, ter_mi2s, gp_pdm1, NA, NA, NA, NA, NA, qdss_tracedata_a,
> These have mi2s though which is fine. Also qdss_tracedata_a is at
> function 6.
qdss_* is function 8 here for me.
>> + NA, NA, NA),
>> + PINGROUP(75, ter_mi2s, NA, NA, NA, NA, qdss_tracedata_a, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(76, ter_mi2s, NA, NA, NA, NA, qdss_tracedata_a, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(77, ter_mi2s, NA, NA, NA, NA, qdss_tracedata_a, NA, NA, NA,
>> + NA, NA),
> qdss_tracedata_a is at function 4 for the above 3 gpios.
Showing as function 6 for me.
>
>> + PINGROUP(78, sec_mi2s, gcc_gp_clk1, NA, NA, NA, NA, NA, NA, NA, NA,
>> + NA),
>> + PINGROUP(79, sec_mi2s, gp_pdm2, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(80, sec_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(81, sec_mi2s, blsp_spi11, blsp_uart11, blsp_uim11,
>> + gcc_gp_clk2, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(82, sec_mi2s, blsp_spi11, blsp_uart11, blsp_uim11,
>> + gcc_gp_clk3, NA, NA, NA, NA, NA, NA),
> I'd do gcc_gp3_clk and gcc_gp2_clk instead. The number is on the
> GP instance. Also, we have _a and _b in the 8996 driver, which
> should be copied into here?
Good catch, fixing 78, 81 and 82: # is on the GP instance for me as well
and I'll add the _a and _b instances.
>
>> + PINGROUP(83, blsp_spi11, blsp_uart11, blsp_i2c11, NA, NA, NA, NA, NA,
>> + NA, NA, NA),
>> + PINGROUP(84, blsp_spi11, blsp_uart11, blsp_i2c11, NA, NA, NA, NA, NA,
>> + NA, NA, NA),
>> + PINGROUP(85, blsp_spi12, blsp_uart12, blsp_uim12, NA, NA,
>> + qdss_tracedata_a, NA, NA, NA, NA, NA),
>> + PINGROUP(86, blsp_spi12, blsp_uart12, blsp_uim12, gp_pdm1, NA,
>> + qdss_tracedata_a, NA, NA, NA, NA, NA),
>> + PINGROUP(87, blsp_spi12, blsp_uart12, blsp_i2c12, NA,
>> + qdss_tracedata_a, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(88, blsp_spi12, blsp_uart12, blsp_i2c12, NA, NA, NA, NA, NA,
>> + NA, NA, NA),
>> + PINGROUP(89, tsif1, NA, qdss_tracedata_a, NA, NA, NA, NA, NA, NA, NA,
>> + NA),
>> + PINGROUP(90, tsif1, blsp_spi10_cs3, qdss_tracedata_a, NA, NA, NA, NA,
>> + NA, NA, NA, NA),
>> + PINGROUP(91, tsif1, sdc4, NA, NA, NA, NA, qdss_traceclk_b, NA, NA, NA,
>> + NA),
>> + PINGROUP(92, tsif2, sdc4, NA, NA, qdss_tracedata_b, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(93, tsif2, sdc4, NA, NA, NA, NA, qdss_tracedata_b, NA, NA,
>> + NA, NA),
>> + PINGROUP(94, tsif2, sdc4, NA, NA, NA, NA, qdss_tracectl_b, NA, NA, NA,
>> + NA),
>> + PINGROUP(95, tsif2, sdc4, gp_pdm0, NA, NA, NA, qdss_cti_trig_out_d,
>> + NA, NA, NA, NA),
>> + PINGROUP(96, tsif2, sdc4, qdss_cti_trig_in_d, NA, NA, NA, NA, NA, NA,
>> + NA, NA),
>> + PINGROUP(97, uim1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(98, uim1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(99, uim1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(100, uim1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(101, uim_batt_alarm, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(102, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(103, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(104, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(105, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(106, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(107, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(108, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(109, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(110, tsif1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(111, tsif1, blsp11_uart_tx_b, NA, NA, NA, NA, NA, NA, NA, NA,
>> + NA),
>> + PINGROUP(112, blsp11_uart_rx_b, NA, NA, NA, NA, NA, NA, NA, NA, NA,
>> + NA),
>> + PINGROUP(113, blsp11_i2c_sda_b, NA, NA, NA, NA, NA, NA, NA, NA, NA,
>> + NA),
>> + PINGROUP(114, blsp11_i2c_scl_b, NA, NA, NA, NA, NA, NA, NA, NA, NA,
>> + NA),
>> + PINGROUP(115, grfc, rffe6, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(116, grfc, rffe6, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(117, grfc, rffe7, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(118, grfc, rffe7, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(119, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(120, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(121, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(122, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(123, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(124, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(125, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(126, grfc, gsm_tx, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(127, grfc, nav_tsync, nav_pps, NA, NA, NA, NA, NA, NA, NA,
>> + NA),
>> + PINGROUP(128, NA, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(129, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(130, gps_tx, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(131, gsm_tx, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(132, gsm_tx, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(133, gsm_tx, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(134, mss_lte, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(135, mss_lte, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(136, rffe1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(137, rffe1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(138, rffe2, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(139, rffe2, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(140, rffe3, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(141, rffe3, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(142, rffe4, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(143, rffe4, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(144, rffe5, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
>> + PINGROUP(145, rffe5, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> We've typically left out rffe*, and grfc from this driver. I'd
> just leave them out here as well.
Ack, will remove rffe*
>
>> + SDC_PINGROUP(sdc1_rclk, 0x2044, 15, 0),
>> + SDC_PINGROUP(sdc1_clk, 0x2044, 13, 6),
>> + SDC_PINGROUP(sdc1_cmd, 0x2044, 11, 3),
>> + SDC_PINGROUP(sdc1_data, 0x2044, 9, 0),
>> + SDC_PINGROUP(sdc2_clk, 0x2048, 14, 6),
>> + SDC_PINGROUP(sdc2_cmd, 0x2048, 11, 3),
>> + SDC_PINGROUP(sdc2_data, 0x2048, 9, 0),
>> + SDC_PINGROUP(sdc3_clk, 0x206c, 14, 6),
>> + SDC_PINGROUP(sdc3_cmd, 0x206c, 11, 3),
>> + SDC_PINGROUP(sdc3_data, 0x206c, 9, 0),
>> +};
>> +
>> +#define NUM_GPIO_PINGROUPS 146
>> +
>> +static const struct msm_pinctrl_soc_data msm8994_pinctrl = {
>> + .pins = msm8994_pins,
>> + .npins = ARRAY_SIZE(msm8994_pins),
>> + .functions = msm8994_functions,
>> + .nfunctions = ARRAY_SIZE(msm8994_functions),
>> + .groups = msm8994_groups,
>> + .ngroups = ARRAY_SIZE(msm8994_groups),
>> + .ngpios = NUM_GPIO_PINGROUPS,
>> +};
>> +
>> +static int msm8994_pinctrl_probe(struct platform_device *pdev)
>> +{
>> + return msm_pinctrl_probe(pdev, &msm8994_pinctrl);
>> +}
>> +
>> +static const struct of_device_id msm8994_pinctrl_of_match[] = {
>> + { .compatible = "qcom,msm8992-pinctrl", },
>> + { .compatible = "qcom,msm8994-pinctrl", },
>> + { },
> Nitpick: this comma can be removed because this list shouldn't
> have any elements after this terminator.
Fixing this in the next version.
I'll send you a follow-up email directly with my tech data info, so we
can determine where the differences on the qdss_* and hdmi_rcv functions
are coming from.
- Michael Scott
>
^ permalink raw reply
* [PATCH v27 9/9] Documentation: dt: chosen properties for arm64 kdump
From: AKASHI Takahiro @ 2016-11-02 4:54 UTC (permalink / raw)
To: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: james.morse-5wv7dgnIgG8, geoff-wEGCiKHe2LqWVfeAwA7xHQ,
bauerman-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
dyoung-H+wXaHxf7aLQT0dZR+AlfA,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, AKASHI Takahiro
In-Reply-To: <20161102044959.11954-1-takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
From: James Morse <james.morse-5wv7dgnIgG8@public.gmane.org>
Add documentation for
linux,crashkernel-base and crashkernel-size,
linux,usable-memory-range
linux,elfcorehdr
used by arm64 kdump to decribe the kdump reserved area, and
the elfcorehdr's location within it.
Signed-off-by: James Morse <james.morse-5wv7dgnIgG8@public.gmane.org>
[takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org: added "linux,crashkernel-base" and "-size" ]
Signed-off-by: AKASHI Takahiro <takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
---
Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 6ae9d82..7b11516 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, and only needed on
book3e) by some versions of kexec-tools to tell the new kernel that it
is being booted by kexec, as the booting environment may differ (e.g.
a different secondary CPU release mechanism)
+
+linux,crashkernel-base
+linux,crashkernel-size
+----------------------
+
+These properties (currently used on PowerPC and arm64) indicates
+the base address and the size, respectively, of the reserved memory
+range for crash dump kernel.
+e.g.
+
+/ {
+ chosen {
+ linux,crashkernel-base = <0x9 0xf0000000>;
+ linux,crashkernel-size = <0x0 0x10000000>;
+ };
+};
+
+linux,usable-memory-range
+-------------------------
+
+This property (currently used only on arm64) holds the memory range,
+the base address and the size, which can be used as system ram on
+the *current* kernel. Note that, if this property is present, any memory
+regions under "memory" nodes in DT blob or ones marked as "conventional
+memory" in EFI memory map should be ignored.
+e.g.
+
+/ {
+ chosen {
+ linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>;
+ };
+};
+
+The main usage is for crash dump kernel to identify its own usable
+memory and exclude, at its boot time, any other memory areas that are
+part of the panicked kernel's memory.
+
+linux,elfcorehdr
+----------------
+
+This property (currently used only on arm64) holds the memory range,
+the address and the size, of the elf core header which mainly describes
+the panicked kernel's memory layout as PT_LOAD segments of elf format.
+e.g.
+
+/ {
+ chosen {
+ linux,elfcorehdr = <0x9 0xfffff000 0x0 0x800>;
+ };
+};
--
2.10.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 0/4] PXA cpufreq conversion to clock API
From: Viresh Kumar @ 2016-11-02 4:45 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Daniel Mack, Haojian Zhuang, Rob Herring, Mark Rutland,
Rafael J Wysocki, linux-arm-kernel, devicetree, linux-kernel,
linux-pm
In-Reply-To: <1477943696-23477-1-git-send-email-robert.jarzmik@free.fr>
On 31-10-16, 20:54, Robert Jarzmik wrote:
> Hi,
>
> This serie is a preparation to shift the cpufreq of pxa2xx platforms to clocks
> API, next iteration.
>
> The first 3 patches are review and merge material :
> - patch 1/4 for Viresh and Rafael
> - patches 2/4 and 3/4 for me
>
> The 4th on is for review but not merge, as the clock changes must be fully
> reviewed and go in first as a prequisite
>
> Since previous iteration, 2 and 3 were amended per Viresh's suggestion.
>
> Robert Jarzmik (4):
> cpufreq: pxa: use generic platdev driver for device-tree
> ARM: dts: pxa: add pxa25x cpu operating points
> ARM: dts: pxa: add pxa27x cpu operating points
> cpufreq: pxa: convert to clock API
>
> arch/arm/boot/dts/pxa25x.dtsi | 25 +++++
> arch/arm/boot/dts/pxa27x.dtsi | 40 ++++++++
> drivers/cpufreq/cpufreq-dt-platdev.c | 2 +
> drivers/cpufreq/pxa2xx-cpufreq.c | 191 +++++++----------------------------
> 4 files changed, 106 insertions(+), 152 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH v2 5/7] [media] ir-lirc-codec: don't wait any transmitting time for tx only devices
From: Andi Shyti @ 2016-11-02 4:39 UTC (permalink / raw)
To: Sean Young
Cc: David Härdeman, Mauro Carvalho Chehab, Rob Herring,
Mark Rutland, linux-media, devicetree, linux-kernel, Andi Shyti
In-Reply-To: <20161101103408.GA15939@gofer.mess.org>
Hi Sean,
> > > Andi, it would be good to know what the use-case for the original change is.
> >
> > the use case is the ir-spi itself which doesn't need the lirc to
> > perform any waiting on its behalf.
>
> Here is the crux of the problem: in the ir-spi case no wait will actually
> happen here, and certainly no "over-wait". The patch below will not change
> behaviour at all.
>
> In the ir-spi case, "towait" will be 0 and no wait happens.
>
> I think the code is already in good shape but somehow there is a
> misunderstanding. Did I miss something?
We can just drop this patch, it's just something small that is
bothering me.
I will send a new patchset without this one.
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v3 3/3] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
From: Viresh Kumar @ 2016-11-02 4:03 UTC (permalink / raw)
To: Dave Gerlach
Cc: Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafael J . Wysocki,
Tony Lindgren, Nishanth Menon
In-Reply-To: <20161027214131.1725-4-d-gerlach-l0cyMroinI0@public.gmane.org>
On 27-10-16, 16:41, Dave Gerlach wrote:
> Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families,
> have different OPPs available for the MPU depending on which specific
> variant of the SoC is in use. This can be determined through use of the
> revision and an eFuse register present in the silicon. Introduce a
> ti-cpufreq driver that can read the aformentioned values and provide
> them as version matching data to the opp framework. Through this the
> opp-supported-hw dt binding that is part of the operating-points-v2
> table can be used to indicate availability of OPPs for each device.
>
> This driver also creates the "cpufreq-dt" platform_device after passing
> the version matching data to the OPP framework so that the cpufreq-dt
> handles the actual cpufreq implementation. Even without the necessary
> data to pass the version matching data the driver will still create this
> device to maintain backwards compatibility with operating-points v1
> tables.
>
> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> ---
> v2-v3:
> - Use common ti compatible as described in binding and then match
> against machine type for platform data.
> - Use newly exposed dev_pm_opp_of_get_opp_desc_node to get
> operating-points-v2 table now that properties needed by driver are
> there.
> - Parse syscon properties from operating-points-v2 node rather
> than cpu node.
> - Do not make ti-cpufreq a module-platform-driver and do not allow
> building as module.
>
> drivers/cpufreq/Kconfig.arm | 11 ++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/ti-cpufreq.c | 288 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 300 insertions(+)
> create mode 100644 drivers/cpufreq/ti-cpufreq.c
Acked-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: dt: add bindings for ti-cpufreq
From: Viresh Kumar @ 2016-11-02 3:59 UTC (permalink / raw)
To: Dave Gerlach
Cc: Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafael J . Wysocki,
Tony Lindgren, Nishanth Menon
In-Reply-To: <20161027214131.1725-3-d-gerlach-l0cyMroinI0@public.gmane.org>
On 27-10-16, 16:41, Dave Gerlach wrote:
> Add the device tree bindings document for the TI CPUFreq/OPP driver
> on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us
> to provide an opp-supported-hw property for each OPP to define when
> it is available. This driver is responsible for reading and parsing
> registers to determine which OPPs can be selectively enabled based
> on the specific SoC in use by matching against the opp-supported-hw
> data.
>
> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> ---
> v2->v3:
> - Move ti,syscon-* properties under opp table instead of cpu node, as
> that is a better location for them.
> - For the opp table do not use platform specific compatible strings
> but instead a operating-points-v2-ti-cpu
>
> .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 132 +++++++++++++++++++++
> 1 file changed, 132 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> new file mode 100644
> index 000000000000..467ad29c75c9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> @@ -0,0 +1,132 @@
> +TI CPUFreq and OPP bindings
> +================================
> +
> +Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
> +families support different OPPs depending on the silicon variant in use.
> +The ti_cpufreq driver can use revision and an efuse value from the SoC to
> +provide the OPP framework with supported hardware information. This is
> +used to determine which OPPs from the operating-points-v2 table get enabled
> +when it is parsed by the OPP framework.
> +
> +Required properties:
> +--------------------
> +In 'cpus' nodes:
> +- operating-points-v2: Phandle to the operating-points-v2 table to use.
> +
> +In 'operating-points-v2' table:
> +- compatible: Should be 'operating-points-v2-ti-cpu' for am335x, am43xx,
> + and dra7xx/am57xx SoCs
> +- ti,syscon-efuse: Syscon phandle, offset to efuse register, efuse register
> + mask, and efuse register shift to get the relevant bits
> + that describe OPP availability.
> +- ti,syscon-rev: Syscon and offset used to look up revision value on SoC.
> +
> +Optional properties:
> +--------------------
> +For each opp entry in 'operating-points-v2' table:
> +- opp-supported-hw: Two bitfields indicating:
> + 1. Which revision of the SoC the OPP is supported by
> + 2. Which eFuse bits indicate this OPP is available
> +
> + A bitwise AND is performed against these values and if any bit
> + matches, the OPP gets enabled. Not providing the property for an
> + entry indicates that an OPP is always supported.
> +
> +Example:
> +--------
> +
> +/* From arch/arm/boot/dts/am33xx.dtsi */
> +cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu@0 {
> + compatible = "arm,cortex-a8";
> + device_type = "cpu";
> + reg = <0>;
> +
> + operating-points-v2 = <&cpu0_opp_table>;
> +
> + clocks = <&dpll_mpu_ck>;
> + clock-names = "cpu";
> +
> + clock-latency = <300000>; /* From omap-cpufreq driver */
> + };
> +};
> +
> +/*
> + * cpu0 has different OPPs depending on SoC revision and some on revisions
> + * 0x2 and 0x4 have eFuse bits that indicate if they are available or not
> + */
> +cpu0_opp_table: opp_table0 {
> + compatible = "operating-points-v2-ti-am3352-cpu";
> + ti,syscon-efuse = <&scm_conf 0x7fc 0x1fff 0>;
> + ti,syscon-rev = <&scm_conf 0x600>;
> +
> + /*
> + * The three following nodes are marked with opp-suspend
> + * because they can not be enabled simultaneously on a
> + * single SoC.
> + */
> + opp50@300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + opp-microvolt = <950000 931000 969000>;
> + opp-supported-hw = <0x06 0x0010>;
> + opp-suspend;
> + };
> +
> + opp100@275000000 {
> + opp-hz = /bits/ 64 <275000000>;
> + opp-microvolt = <1100000 1078000 1122000>;
> + opp-supported-hw = <0x01 0x00FF>;
> + opp-suspend;
> + };
> +
> + opp100@300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + opp-microvolt = <1100000 1078000 1122000>;
> + opp-supported-hw = <0x06 0x0020>;
> + opp-suspend;
Only one OPP in the table can be marked as suspend OPP.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Wenyou Yang @ 2016-11-02 3:05 UTC (permalink / raw)
To: Nicolas Ferre, Alexandre Belloni, Russell King, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Cc: linux-kernel, Wenyou Yang, devicetree, linux-arm-kernel,
Wenyou Yang
The sama5d36ek CMP board is the variant of sama5d3xek board.
It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and
some power rail. Its main purpose is used to measure the power
consumption.
The difference of the sama5d36ek CMP dts from sama5d36ek dts
is listed as below.
1. The USB host nodes are removed, that is, the USB host is disabled.
2. The gpio_keys node is added to wake up from the sleep.
3. The LCD isn't supported due to the pins for LCD are conflicted
with gpio_keys.
4. The adc0 node support the pinctrl sleep state to fix the over
consumption on VDDANA.
As said in errata, "When the USB host ports are used in high speed
mode (EHCI), it is not possible to suspend the ports if no device is
attached on each port. This leads to increased power consumption even
if the system is in a low power mode." That is why the the USB host
is disabled.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
Changes in v2:
- Add the pinctrl sleep state for adc0 node to fix the over
consumption on VDDANA.
- Improve the commit log.
arch/arm/boot/dts/sama5d36ek_cmp.dts | 51 +++++++
arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 166 +++++++++++++++++++++
arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 265 ++++++++++++++++++++++++++++++++++
3 files changed, 482 insertions(+)
create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
diff --git a/arch/arm/boot/dts/sama5d36ek_cmp.dts b/arch/arm/boot/dts/sama5d36ek_cmp.dts
new file mode 100644
index 0000000..fd6bcd6
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d36ek_cmp.dts
@@ -0,0 +1,51 @@
+/*
+ * sama5d36ek_cmp.dts - Device Tree file for SAMA5D36-EK CMP board
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include "sama5d36.dtsi"
+#include "sama5d3xmb_cmp.dtsi"
+
+/ {
+ model = "Atmel SAMA5D36-EK";
+ compatible = "atmel,sama5d36ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ spi0: spi@f0004000 {
+ status = "okay";
+ };
+
+ ssc0: ssc@f0008000 {
+ status = "okay";
+ };
+
+ can0: can@f000c000 {
+ status = "okay";
+ };
+
+ i2c0: i2c@f0014000 {
+ status = "okay";
+ };
+
+ i2c1: i2c@f0018000 {
+ status = "okay";
+ };
+
+ macb0: ethernet@f0028000 {
+ status = "okay";
+ };
+
+ macb1: ethernet@f802c000 {
+ status = "okay";
+ };
+ };
+ };
+
+ sound {
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
new file mode 100644
index 0000000..77638c3
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
@@ -0,0 +1,166 @@
+/*
+ * sama5d3xcm_cmp.dtsi - Device Tree Include file for SAMA5D36 CMP CPU Module
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+/ {
+ compatible = "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x20000000 0x20000000>;
+ };
+
+ clocks {
+ slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal {
+ clock-frequency = <12000000>;
+ };
+ };
+
+ ahb {
+ apb {
+ spi0: spi@f0004000 {
+ cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
+ };
+
+ macb0: ethernet@f0028000 {
+ phy-mode = "rgmii";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@1 {
+ reg = <0x1>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+
+ ethernet-phy@7 {
+ reg = <0x7>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+ };
+
+ i2c1: i2c@f0018000 {
+ pmic: act8865@5b {
+ compatible = "active-semi,act8865";
+ reg = <0x5b>;
+ status = "disabled";
+
+ regulators {
+ vcc_1v8_reg: DCDC_REG1 {
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ vcc_1v2_reg: DCDC_REG2 {
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+ };
+
+ vcc_3v3_reg: DCDC_REG3 {
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vddana_reg: LDO_REG1 {
+ regulator-name = "VDDANA";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vddfuse_reg: LDO_REG2 {
+ regulator-name = "FUSE_2V5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+ };
+ };
+ };
+ };
+
+ nand0: nand@60000000 {
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+ status = "okay";
+
+ at91bootstrap@0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ bootloader@40000 {
+ label = "bootloader";
+ reg = <0x40000 0x80000>;
+ };
+
+ bootloaderenv@c0000 {
+ label = "bootloader env";
+ reg = <0xc0000 0xc0000>;
+ };
+
+ dtb@180000 {
+ label = "device tree";
+ reg = <0x180000 0x80000>;
+ };
+
+ kernel@200000 {
+ label = "kernel";
+ reg = <0x200000 0x600000>;
+ };
+
+ rootfs@800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ d2 {
+ label = "d2";
+ gpios = <&pioE 25 GPIO_ACTIVE_LOW>; /* PE25, conflicts with A25, RXD2 */
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
new file mode 100644
index 0000000..62c6230
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
@@ -0,0 +1,265 @@
+/*
+ * sama5d3xmb_cmp.dts - Device Tree file for SAMA5D3x CMP mother board
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * Licensed under GPLv2 or later.
+ */
+#include "sama5d3xcm_cmp.dtsi"
+
+/ {
+ compatible = "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ mmc0: mmc@f0000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
+ status = "okay";
+ slot@0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioD 17 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ spi0: spi@f0004000 {
+ dmas = <0>, <0>; /* Do not use DMA for spi0 */
+
+ m25p80@0 {
+ compatible = "atmel,at25df321a";
+ spi-max-frequency = <50000000>;
+ reg = <0>;
+ };
+ };
+
+ ssc0: ssc@f0008000 {
+ atmel,clk-from-rk-pin;
+ };
+
+ /*
+ * i2c0 conflicts with ISI:
+ * disable it to allow the use of ISI
+ * can not enable audio when i2c0 disabled
+ */
+ i2c0: i2c@f0014000 {
+ wm8904: wm8904@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ clocks = <&pck0>;
+ clock-names = "mclk";
+ };
+ };
+
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = "ovti,ov2640";
+ reg = <0x30>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck1_as_isi_mck &pinctrl_sensor_power &pinctrl_sensor_reset>;
+ resetb-gpios = <&pioE 24 GPIO_ACTIVE_LOW>;
+ pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
+ /* use pck1 for the master clock of ov2640 */
+ clocks = <&pck1>;
+ clock-names = "xvclk";
+ assigned-clocks = <&pck1>;
+ assigned-clock-rates = <25000000>;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = <&isi_0>;
+ bus-width = <8>;
+ };
+ };
+ };
+ };
+
+ usart1: serial@f0020000 {
+ dmas = <0>, <0>; /* Do not use DMA for usart1 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+ status = "okay";
+ };
+
+ isi: isi@f0034000 {
+ port {
+ isi_0: endpoint {
+ remote-endpoint = <&ov2640_0>;
+ bus-width = <8>;
+ vsync-active = <1>;
+ hsync-active = <1>;
+ };
+ };
+ };
+
+ mmc1: mmc@f8000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
+ status = "okay";
+ slot@0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioD 18 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ adc0: adc@f8018000 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <
+ &pinctrl_adc0_adtrg
+ &pinctrl_adc0_ad0
+ &pinctrl_adc0_ad1
+ &pinctrl_adc0_ad2
+ &pinctrl_adc0_ad3
+ &pinctrl_adc0_ad4
+ >;
+ pinctrl-1 = <
+ &pinctrl_adc0_adtrg_sleep
+ &pinctrl_adc0_ad0_sleep
+ &pinctrl_adc0_ad1_sleep
+ &pinctrl_adc0_ad2_sleep
+ &pinctrl_adc0_ad3_sleep
+ &pinctrl_adc0_ad4_sleep
+ >;
+ status = "okay";
+ };
+
+ macb1: ethernet@f802c000 {
+ phy-mode = "rmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@1 {
+ /*interrupt-parent = <&pioE>;*/
+ /*interrupts = <30 IRQ_TYPE_EDGE_FALLING>;*/
+ reg = <1>;
+ };
+ };
+
+ pinctrl@fffff200 {
+ adc0 {
+ pinctrl_adc0_adtrg_sleep: adc0_adtrg_1 {
+ atmel,pins =
+ <AT91_PIOD 19 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD19 GPIO output 0 */
+ };
+ pinctrl_adc0_ad0_sleep: adc0_ad0_1 {
+ atmel,pins =
+ <AT91_PIOD 20 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD20 GPIO output 0 */
+ };
+ pinctrl_adc0_ad1_sleep: adc0_ad1_1 {
+ atmel,pins =
+ <AT91_PIOD 21 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD21 GPIO output 0 */
+ };
+ pinctrl_adc0_ad2_sleep: adc0_ad2_1 {
+ atmel,pins =
+ <AT91_PIOD 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD22 GPIO output 0 */
+ };
+ pinctrl_adc0_ad3_sleep: adc0_ad3_1 {
+ atmel,pins =
+ <AT91_PIOD 23 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD23 GPIO output 0 */
+ };
+ pinctrl_adc0_ad4_sleep: adc0_ad4_1 {
+ atmel,pins =
+ <AT91_PIOD 24 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD24 GPIO output 0 */
+ };
+ };
+
+ board {
+ pinctrl_gpio_keys: gpio_keys {
+ atmel,pins =
+ <AT91_PIOE 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
+ };
+
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins =
+ <AT91_PIOD 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD17 GPIO with pullup deglitch */
+ };
+
+ pinctrl_mmc1_cd: mmc1_cd {
+ atmel,pins =
+ <AT91_PIOD 18 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD18 GPIO with pullup deglitch */
+ };
+
+ pinctrl_pck0_as_audio_mck: pck0_as_audio_mck {
+ atmel,pins =
+ <AT91_PIOD 30 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD30 periph B */
+ };
+
+ pinctrl_pck1_as_isi_mck: pck1_as_isi_mck-0 {
+ atmel,pins =
+ <AT91_PIOD 31 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD31 periph B ISI_MCK */
+ };
+
+ pinctrl_sensor_reset: sensor_reset-0 {
+ atmel,pins =
+ <AT91_PIOE 24 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE24 gpio */
+ };
+
+ pinctrl_sensor_power: sensor_power-0 {
+ atmel,pins =
+ <AT91_PIOE 29 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE29 gpio */
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins =
+ <AT91_PIOD 29 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PD29 GPIO with deglitch */
+ };
+ };
+ };
+
+ dbgu: serial@ffffee00 {
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+ status = "okay";
+ };
+
+ watchdog@fffffe40 {
+ status = "okay";
+ };
+ };
+
+ usb0: gadget@00500000 {
+ atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ status = "okay";
+ };
+ };
+
+ sound {
+ compatible = "atmel,asoc-wm8904";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck0_as_audio_mck>;
+
+ atmel,model = "wm8904 @ SAMA5D3EK";
+ atmel,audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Mic", "MICBIAS",
+ "IN1L", "Mic";
+
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8904>;
+
+ status = "disabled";
+ };
+
+ /* Conflict with LCD pins */
+ gpio_keys {
+ compatible = "gpio-keys";
+ status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ pb_user1 {
+ label = "pb_user1";
+ gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
+ linux,code = <0x100>;
+ gpio-key,wakeup;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v4] Documentation: dtb: lm87: Add hwmon binding documentation.
From: Mahoda Ratnayaka @ 2016-11-02 2:58 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, devicetree, linux-hwmon
Cc: Chris Packham, Mahoda Ratnayaka
This patch adds lm87 hwmon device tree node documentation.
Signed-off-by: Mahoda Ratnayaka <mahoda.ratnayaka@alliedtelesis.co.nz>
---
Notes:
Changes since v1:
As suggested include all the changes are moved in
to the same patch and the all the optional properties
are now defined instead of using a single variable to
indicate those properties.
Changes since v2:
Changed has-vcc-5v to use regulator binding and fixed
a minor copy paste mistake.
Changes since v3:
Update the vcc-supply description.
Documentation/devicetree/bindings/hwmon/lm87.txt | 30 ++++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/lm87.txt
diff --git a/Documentation/devicetree/bindings/hwmon/lm87.txt b/Documentation/devicetree/bindings/hwmon/lm87.txt
new file mode 100644
index 0000000..e1b7990
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/lm87.txt
@@ -0,0 +1,30 @@
+*LM87 hwmon sensor.
+
+Required properties:
+- compatible: Should be
+ "ti,lm87"
+
+- reg: I2C address
+
+optional properties:
+- has-temp3: This configures pins 18 and 19 to be used as a second
+ remote temperature sensing channel. By default the pins
+ are configured as voltage input pins in0 and in5.
+
+- has-in6: When set, pin 5 is configured to be used as voltage input
+ in6. Otherwise the pin is set as FAN1 input.
+
+- has-in7: When set, pin 6 is configured to be used as voltage input
+ in7. Otherwise the pin is set as FAN2 input.
+
+- vcc-supply: a Phandle for the regulator supplying power, can be
+ cofigured to measure 5.0V power supply. Default is 3.3V.
+
+Example:
+
+lm87@2e {
+ compatible = "ti,lm87";
+ reg = <0x2e>;
+ has-temp3;
+ vcc-supply = <®_5v0>;
+};
--
2.10.2
^ permalink raw reply related
* Re: Re: [PATCH v3 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
From: Chen-Yu Tsai @ 2016-11-02 1:33 UTC (permalink / raw)
To: Rob Herring
Cc: Chen-Yu Tsai, Maxime Ripard, David Airlie, Mark Rutland,
dri-devel, linux-arm-kernel, linux-kernel, devicetree,
linux-sunxi
In-Reply-To: <20161031062836.mnzdprqfezrfkx4g@rob-hp-laptop>
On Mon, Oct 31, 2016 at 2:28 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Sat, Oct 29, 2016 at 07:06:10PM +0800, Chen-Yu Tsai wrote:
>> Some dumb VGA DACs are active components which require external power.
>> Add support for specifying a regulator as its power supply.
>>
>> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> ---
>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>
> For the binding,
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> One code comment below...
>
>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 35 ++++++++++++++++++++++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> index 003bc246a270..164cbb15f04c 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> @@ -16,6 +16,8 @@ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
>> - Video port 0 for RGB input
>> - Video port 1 for VGA output
>>
>> +Optional properties:
>> +- vdd-supply: Power supply for DAC
>>
>> Example
>> -------
>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> index afec232185a7..59781e031220 100644
>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> @@ -12,6 +12,7 @@
>>
>> #include <linux/module.h>
>> #include <linux/of_graph.h>
>> +#include <linux/regulator/consumer.h>
>>
>> #include <drm/drmP.h>
>> #include <drm/drm_atomic_helper.h>
>> @@ -23,6 +24,7 @@ struct dumb_vga {
>> struct drm_connector connector;
>>
>> struct i2c_adapter *ddc;
>> + struct regulator *vdd;
>> };
>>
>> static inline struct dumb_vga *
>> @@ -124,8 +126,33 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>> return 0;
>> }
>>
>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> + int ret;
>> +
>> + if (!IS_ERR(vga->vdd)) {
>
> if (IS_ERR())
> return;
>
> ...will save some intentation.
I thought about that, though if someone were to add more stuff to
this, such as an enable GPIO, they might have to rework it. A standalone
block of code would be easier to work with. I'm OK either way though.
ChenYu
>
>> + ret = regulator_enable(vga->vdd);
>> +
>> + if (ret) {
>> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>> + return;
>> + }
>> + }
>> +}
>> +
>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +
>> + if (!IS_ERR(vga->vdd))
>> + regulator_disable(vga->vdd);
>> +}
>> +
>> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>> .attach = dumb_vga_attach,
>> + .enable = dumb_vga_enable,
>> + .disable = dumb_vga_disable,
>> };
>>
>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>> @@ -169,6 +196,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
>> return -ENOMEM;
>> platform_set_drvdata(pdev, vga);
>>
>> + vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
>> + if (IS_ERR(vga->vdd)) {
>> + ret = PTR_ERR(vga->vdd);
>> + if (ret == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> + dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
>> + }
>> +
>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>> if (IS_ERR(vga->ddc)) {
>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>> --
>> 2.9.3
>>
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 7/7] clk: qcom: ipq4019: changed i2c freq table
From: Stephen Boyd @ 2016-11-02 1:29 UTC (permalink / raw)
To: Abhishek Sahu
Cc: andy.gross, david.brown, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, mturquette, galak, pradeepb, mmcclint, varada,
sricharan, architt, ntelkar, linux-arm-msm, linux-soc, linux-clk,
linux-kernel, devicetree
In-Reply-To: <1474460512-31994-8-git-send-email-absahu@codeaurora.org>
On 09/21, Abhishek Sahu wrote:
> The current I2C freq table uses MND values which is not
> applicable for I2C since its RCG does not have MND
> counter. This patch updates the freq table for 19.05
> MHz clk frequency with FEPLL_200 parent.
That's concerning given that we read the registers, but I guess
it works out?
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v3 6/7] clk: qcom: ipq4019: changed the frequency value for ddr pll
From: Stephen Boyd @ 2016-11-02 1:27 UTC (permalink / raw)
To: Abhishek Sahu
Cc: andy.gross, david.brown, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, mturquette, galak, pradeepb, mmcclint, varada,
sricharan, architt, ntelkar, linux-arm-msm, linux-soc, linux-clk,
linux-kernel, devicetree
In-Reply-To: <1474460512-31994-7-git-send-email-absahu@codeaurora.org>
On 09/21, Abhishek Sahu wrote:
> diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
> index b2decd5..a2809db 100644
> --- a/drivers/clk/qcom/gcc-ipq4019.c
> +++ b/drivers/clk/qcom/gcc-ipq4019.c
> @@ -546,7 +546,7 @@ static const struct freq_tbl ftbl_gcc_sdcc1_apps_clk[] = {
> F(25000000, P_FEPLL500, 1, 1, 20),
> F(50000000, P_FEPLL500, 1, 1, 10),
> F(100000000, P_FEPLL500, 1, 1, 5),
> - F(190000000, P_DDRPLL, 1, 0, 0),
> + F(192000000, P_DDRPLL, 1, 0, 0),
Change from 193 to 190 to 192.... please do it once.
> { }
> };
>
> @@ -567,18 +567,18 @@ static struct clk_rcg2 sdcc1_apps_clk_src = {
> static const struct freq_tbl ftbl_gcc_apps_clk[] = {
> F(48000000, P_XO, 1, 0, 0),
> F(200000000, P_FEPLL200, 1, 0, 0),
> - F(380000000, P_DDRPLLAPSS, 1, 0, 0),
> - F(409000000, P_DDRPLLAPSS, 1, 0, 0),
> - F(444000000, P_DDRPLLAPSS, 1, 0, 0),
> - F(484000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(384000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(413000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(448000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(488000000, P_DDRPLLAPSS, 1, 0, 0),
> F(500000000, P_FEPLL500, 1, 0, 0),
> - F(507000000, P_DDRPLLAPSS, 1, 0, 0),
> - F(532000000, P_DDRPLLAPSS, 1, 0, 0),
> - F(560000000, P_DDRPLLAPSS, 1, 0, 0),
> - F(592000000, P_DDRPLLAPSS, 1, 0, 0),
> - F(626000000, P_DDRPLLAPSS, 1, 0, 0),
> - F(666000000, P_DDRPLLAPSS, 1, 0, 0),
> - F(710000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(512000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(537000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(565000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(597000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(632000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(672000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(716000000, P_DDRPLLAPSS, 1, 0, 0),
Didn't this patch series introduce table updates already? Why
can't this patch be squashed with that one?
> { }
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v3 5/7] clk: qcom: ipq4019: corrected sdcc frequency and parent name
From: Stephen Boyd @ 2016-11-02 1:26 UTC (permalink / raw)
To: Abhishek Sahu
Cc: andy.gross, david.brown, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, mturquette, galak, pradeepb, mmcclint, varada,
sricharan, architt, ntelkar, linux-arm-msm, linux-soc, linux-clk,
linux-kernel, devicetree
In-Reply-To: <1474460512-31994-6-git-send-email-absahu@codeaurora.org>
On 09/21, Abhishek Sahu wrote:
> 1. The parent for sdcc clock is sdccpll so corrected the same
> in its parent map.
> 2. The frequency value was wrong so changed to correct
> frequency.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
> drivers/clk/qcom/gcc-ipq4019.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
> index 160e0cf..b2decd5 100644
> --- a/drivers/clk/qcom/gcc-ipq4019.c
> +++ b/drivers/clk/qcom/gcc-ipq4019.c
> @@ -120,7 +120,7 @@ static struct parent_map gcc_xo_sdcc1_500_map[] = {
>
> static const char * const gcc_xo_sdcc1_500[] = {
> "xo",
> - "ddrpll",
> + "ddrpllsdcc",
> "fepll500",
> };
>
> @@ -540,13 +540,13 @@ static struct clk_branch gcc_gp3_clk = {
> };
>
> static const struct freq_tbl ftbl_gcc_sdcc1_apps_clk[] = {
> - F(144000, P_XO, 1, 3, 240),
> - F(400000, P_XO, 1, 1, 0),
> - F(20000000, P_FEPLL500, 1, 1, 25),
> - F(25000000, P_FEPLL500, 1, 1, 20),
> - F(50000000, P_FEPLL500, 1, 1, 10),
> - F(100000000, P_FEPLL500, 1, 1, 5),
None of these changed? Please leave them alone then.
> - F(193000000, P_DDRPLL, 1, 0, 0),
> + F(144000, P_XO, 1, 3, 240),
> + F(400000, P_XO, 1, 1, 0),
> + F(20000000, P_FEPLL500, 1, 1, 25),
> + F(25000000, P_FEPLL500, 1, 1, 20),
> + F(50000000, P_FEPLL500, 1, 1, 10),
> + F(100000000, P_FEPLL500, 1, 1, 5),
> + F(190000000, P_DDRPLL, 1, 0, 0),
And tab out this one appropriately so that it lines up. Then the
diff is very clear.
> { }
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v3 4/7] clk: qcom: ipq4019: Added all the frequencies for apps cpu
From: Stephen Boyd @ 2016-11-02 1:24 UTC (permalink / raw)
To: Abhishek Sahu
Cc: andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
mturquette-rdvid1DuHRBWk0Htik3J/w, galak-sgV2jX0FEOL9JmXXK+q4OQ,
pradeepb-sgV2jX0FEOL9JmXXK+q4OQ, mmcclint-sgV2jX0FEOL9JmXXK+q4OQ,
varada-sgV2jX0FEOL9JmXXK+q4OQ, sricharan-sgV2jX0FEOL9JmXXK+q4OQ,
architt-sgV2jX0FEOL9JmXXK+q4OQ, ntelkar-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474460512-31994-5-git-send-email-absahu-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 09/21, Abhishek Sahu wrote:
> The APPS CPU clock does not contain all the frequencies in its
> frequency table so this patch adds the same.
>
> Signed-off-by: Abhishek Sahu <absahu-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> drivers/clk/qcom/gcc-ipq4019.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
> index 211c68c..160e0cf 100644
> --- a/drivers/clk/qcom/gcc-ipq4019.c
> +++ b/drivers/clk/qcom/gcc-ipq4019.c
> @@ -565,10 +565,20 @@ static struct clk_rcg2 sdcc1_apps_clk_src = {
> };
>
> static const struct freq_tbl ftbl_gcc_apps_clk[] = {
> - F(48000000, P_XO, 1, 0, 0),
> + F(48000000, P_XO, 1, 0, 0),
> F(200000000, P_FEPLL200, 1, 0, 0),
> + F(380000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(409000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(444000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(484000000, P_DDRPLLAPSS, 1, 0, 0),
> F(500000000, P_FEPLL500, 1, 0, 0),
> + F(507000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(532000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(560000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(592000000, P_DDRPLLAPSS, 1, 0, 0),
> F(626000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(666000000, P_DDRPLLAPSS, 1, 0, 0),
> + F(710000000, P_DDRPLLAPSS, 1, 0, 0),
> { }
> };
Can't we have the determine_rate callback know the speeds of the
"fixed" PLLs and use those first if the rate hits exactly? And
then if that doesn't happen go try ddrpllapps and set the rate on
it? I'm hoping we can get rid of this frequency table.
--
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/7] clk: qcom: ipq4019: Added the clock nodes and operations for pll
From: Stephen Boyd @ 2016-11-02 1:22 UTC (permalink / raw)
To: Abhishek Sahu
Cc: andy.gross, david.brown, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, mturquette, galak, pradeepb, mmcclint, varada,
sricharan, architt, ntelkar, linux-arm-msm, linux-soc, linux-clk,
linux-kernel, devicetree
In-Reply-To: <1474460512-31994-2-git-send-email-absahu@codeaurora.org>
On 09/21, Abhishek Sahu wrote:
> The current ipq4019 clock driver registered the PLL clocks and
> dividers as fixed clock. These fixed clock needs to be removed
> from driver probe function and same need to be registered with
> clock framework. These PLL clocks should be programmed only
> once and the same are being programmed already by the boot
> loader so the set rate operation is not required for these
> clocks. Only the rate can be calculated by clock operations
> in clock driver file so this patch adds the same.
>
> The PLL takes the reference clock from XO and generates the
> intermediate VCO frequency. This VCO frequency will be divided
> down by different PLL internal dividers. Some of the PLL
> internal dividers are fixed while other are programmable.
>
> This patch does the following changes.
This should never be in the commit text. What a patch does should
be obvious from the patch itself. Why we're doing it is much more
important to express.
> 1. Operation for calculating PLL intermediate VCO frequency by
> reading the reference clock divider and feedback divider from
> register. Since VCO frequency falls outside the limit of
> unsigned long for IPQ4019, so this operation will return the
> VCO frequency in kHz.
>
> 2. Operation for calculating the internal PLL divider clock
> frequency. Clock Divider node should give either fixed
> divider value or divider table(maps the register divider
> value to actual divider value).
>
> 3. Adds and registers clock nodes for VCO(APPS DDR PLL and FE
> PLL) and PLL internal dividers(SDCC, FEPLL 500 MHz, FEPLL
> 200 MHz, FEPLL 125 MHz, FEPLL 125 MHz with delay,
> programmable WCSS 2G and 5G).
>
> 4. Changes the regmap limit from 0x2dffff to 0x2ffff for
> supporting the PLL registers read.
Yep that's obvious from the patch.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
> drivers/clk/qcom/gcc-ipq4019.c | 292 ++++++++++++++++++++++++++-
> include/dt-bindings/clock/qcom,gcc-ipq4019.h | 9 +
> 2 files changed, 290 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
> index 3cd1af0..9251457 100644
> --- a/drivers/clk/qcom/gcc-ipq4019.c
> +++ b/drivers/clk/qcom/gcc-ipq4019.c
> @@ -28,6 +28,16 @@
> #include "clk-rcg.h"
> #include "clk-branch.h"
> #include "reset.h"
> +#include "clk-regmap-divider.h"
> +
> +#define to_clk_regmap_div(_hw) container_of(to_clk_regmap(_hw),\
> + struct clk_regmap_div, clkr)
> +
> +#define to_clk_pll_div(_hw) container_of((to_clk_regmap_div(_hw)),\
> + struct clk_pll_div, cdiv)
> +
> +#define to_clk_pll_vco(_hw) container_of((to_clk_regmap_div(_hw)),\
> + struct clk_pll_vco, cdiv)
>
Please remove double parenthesis around to_clk_regmap_div()
unlesss there's some reason for that?
> enum {
> P_XO,
> @@ -40,6 +50,35 @@ enum {
> P_DDRPLLAPSS,
> };
>
> +/*
> + * struct clk_pll_vco - vco feedback divider corresponds to PLL_DIV register
> + * @fdbkdiv_shift: lowest bit for FDBKDIV
> + * @fdbkdiv_width: number of bits in FDBKDIV
> + * @cdiv: divider values for PLL_DIV
> + */
> +struct clk_pll_vco {
> + u32 fdbkdiv_shift;
> + u32 fdbkdiv_width;
> + struct clk_regmap_div cdiv;
> +};
> +
> +/*
> + * struct clk_pll_div - clk divider corresponds to PLL_DIV register
> + * @fixed_div: fixed divider value if divider is fixed
> + * @parent_map: map from software's parent index to hardware's src_sel field
> + * @cdiv: divider values for PLL_DIV
> + * @div_table: mapping for actual divider value to register divider value
> + * in case of non fixed divider
> + * @freq_tbl: frequency table
> + */
> +struct clk_pll_div {
s/clk_pll_div/clk_fepll/?
> + u32 fixed_div;
> + const u8 *parent_map;
> + struct clk_regmap_div cdiv;
> + const struct clk_div_table *div_table;
> + const struct freq_tbl *freq_tbl;
> +};
> +
> static struct parent_map gcc_xo_200_500_map[] = {
> { P_XO, 0 },
> { P_FEPLL200, 1 },
> @@ -1155,6 +1194,238 @@ static struct clk_branch gcc_wcss5g_rtc_clk = {
> },
> };
>
> +/*
> + * Calculates the rate from parent rate and divider and round the rate
> + * in MHz. This function takes the parent rate in kHz and returns the
> + * rate in Hz.
> + */
> +static unsigned long clk_calc_divider_rate(unsigned long parent_rate,
Umm... parent_rate should be in Hz here.
> + unsigned int div)
> +{
> + u32 rate;
> +
> + rate = parent_rate / div;
> +
> + /*
> + * This rate is in kHz and returned value should be rounded
> + * in MHz. So divide the value with 1000 and multiply it with
> + * 1000(rate value was divided with 1000) * 1000(kHz to MHz).
> + */
> + rate /= 1000;
> + rate *= 1000000;
Is this some complicated mechanism to round down to the nearest
MHz? Why? Also, can this function be rolled into the single
caller?
> +
> + return rate;
> +}
> +
> +/*
> + * Calculates the VCO rate for PLL.
> + * VCO rate value is greater than unsigned long limit. Since this is an
> + * intermediate clock node for actual PLL dividers, so it returns the
> + * rate in kHz. The child nodes will return the value in Hz after its
> + * divide operation.
> + */
> +static unsigned long clk_regmap_vco_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct clk_pll_vco *rcg = to_clk_pll_vco(hw);
> + u32 fdbkdiv, refclkdiv, cdiv, vco;
> +
> + regmap_read(rcg->cdiv.clkr.regmap, rcg->cdiv.reg, &cdiv);
> + refclkdiv = (cdiv >> rcg->cdiv.shift) & (BIT(rcg->cdiv.width) - 1);
> + fdbkdiv = (cdiv >> rcg->fdbkdiv_shift) & (BIT(rcg->fdbkdiv_width) - 1);
> +
> + vco = parent_rate / refclkdiv;
> + vco /= 1000;
> + vco *= 2;
> + vco *= fdbkdiv;
> +
> + return vco;
Urgh. Bad. We shouldn't be changing the units in this case
because unsigned long is limiting. One solution is to make a
"mega clock" and do the division as well in one recalc_rate
function. That circumvents the need to pass large frequencies as
khz to get around the limit of unsigned long on 32 bit platforms.
Otherwise, we need to go ahead and make the "rate" member of
struct clk_rate_request be u64 and then this problem doesn't
exist inside the clk drivers (just with the consumer APIs).
> +}
> +
> +static const struct clk_ops clk_regmap_vco_ops = {
> + .recalc_rate = clk_regmap_vco_recalc_rate,
> +};
> +
> +static struct clk_pll_vco gcc_apps_ddrpll_vco = {
> + .fdbkdiv_shift = 16,
> + .fdbkdiv_width = 8,
> + .cdiv.reg = 0x2e020,
> + .cdiv.shift = 24,
> + .cdiv.width = 5,
> + .cdiv.clkr = {
> + .hw.init = &(struct clk_init_data){
> + .name = "gcc_apps_ddrpll_vco",
> + .parent_names = (const char *[]){
> + "xo",
> + },
> + .num_parents = 1,
> + .ops = &clk_regmap_vco_ops,
> + },
> + },
> +};
> +
> +static struct clk_pll_vco gcc_fepll_vco = {
> + .fdbkdiv_shift = 16,
> + .fdbkdiv_width = 8,
> + .cdiv.reg = 0x2f020,
> + .cdiv.shift = 24,
> + .cdiv.width = 5,
> + .cdiv.clkr = {
> + .hw.init = &(struct clk_init_data){
> + .name = "gcc_fepll_vco",
> + .parent_names = (const char *[]){
> + "xo",
> + },
> + .num_parents = 1,
> + .ops = &clk_regmap_vco_ops,
> + },
> + },
> +};
> +
> +/*
> + * Calculates the rate for PLL divider.
> + * If the divider value is not fixed then it gets the actual divider value
> + * from divider table. Then, it calculate the clock rate by dividing the
> + * parent rate with actual divider value.
> + */
> +static unsigned long clk_regmap_clk_div_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct clk_pll_div *rcg = to_clk_pll_div(hw);
> + u32 cdiv, pre_div = 1;
> + const struct clk_div_table *clkt;
> +
> + if (rcg->fixed_div) {
> + pre_div = rcg->fixed_div;
> + } else {
> + regmap_read(rcg->cdiv.clkr.regmap, rcg->cdiv.reg, &cdiv);
> + cdiv = (cdiv >> rcg->cdiv.shift) & (BIT(rcg->cdiv.width) - 1);
> +
> + for (clkt = rcg->div_table; clkt->div; clkt++) {
> + if (clkt->val == cdiv)
> + pre_div = clkt->div;
> + }
> + }
> +
> + return clk_calc_divider_rate(parent_rate, pre_div);
> +};
> +
> +static const struct clk_ops clk_regmap_clk_div_ops = {
clk_fepll_div_ops?
> + .recalc_rate = clk_regmap_clk_div_recalc_rate,
> +};
> +
> +static struct clk_pll_div gcc_apps_sdcc_clk = {
> + .fixed_div = 28,
> + .cdiv.clkr = {
> + .hw.init = &(struct clk_init_data){
> + .name = "ddrpllsdcc",
> + .parent_names = (const char *[]){
> + "gcc_apps_ddrpll_vco",
> + },
> + .num_parents = 1,
> + .ops = &clk_regmap_clk_div_ops,
> + },
> + },
> +};
> +
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 3/3] clk: imx: clk-imx6ul: add clk support for imx6ull
From: Stephen Boyd @ 2016-11-02 0:12 UTC (permalink / raw)
To: Peter Chen
Cc: shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, fabio.estevam-3arQi8VN3Tc,
mark.rutland-5wv7dgnIgG8, linux-clk-u79uwXL29TY76Z2rM5mHXA,
Bai Ping, Peng Fan
In-Reply-To: <1477969343-19887-4-git-send-email-peter.chen-3arQi8VN3Tc@public.gmane.org>
On 11/01, Peter Chen wrote:
> clks[IMX6UL_CLK_USDHC1] = imx_clk_gate2("usdhc1", "usdhc1_podf", base + 0x80, 2);
> clks[IMX6UL_CLK_USDHC2] = imx_clk_gate2("usdhc2", "usdhc2_podf", base + 0x80, 4);
> - clks[IMX6UL_CLK_SIM1] = imx_clk_gate2("sim1", "sim_sel", base + 0x80, 6);
> - clks[IMX6UL_CLK_SIM2] = imx_clk_gate2("sim2", "sim_sel", base + 0x80, 8);
> + if (clk_on_imx6ul()) {
> + clks[IMX6UL_CLK_SIM1] = imx_clk_gate2("sim1", "sim_sel", base + 0x80, 6);
> + clks[IMX6UL_CLK_SIM2] = imx_clk_gate2("sim2", "sim_sel", base + 0x80, 8);
> + }
> clks[IMX6UL_CLK_EIM] = imx_clk_gate2("eim", "eim_slow_podf", base + 0x80, 10);
> clks[IMX6UL_CLK_PWM8] = imx_clk_gate2("pwm8", "perclk", base + 0x80, 16);
> clks[IMX6UL_CLK_UART8_IPG] = imx_clk_gate2("uart8_ipg", "ipg", base + 0x80, 14);
> @@ -430,6 +478,7 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
> clk_set_rate(clks[IMX6UL_CLK_ENET_REF], 50000000);
> clk_set_rate(clks[IMX6UL_CLK_ENET2_REF], 50000000);
> clk_set_rate(clks[IMX6UL_CLK_CSI], 24000000);
> + clk_set_rate(clks[IMX6UL_CLK_PLL3_PFD2], 320000000);
Can you use assigned clock rates for this instead?
>
> /* keep all the clks on just for bringup */
--
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4] pinctrl: qcom: Add msm8994 pinctrl driver
From: Stephen Boyd @ 2016-11-01 23:53 UTC (permalink / raw)
To: Michael Scott
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Rob Herring,
Mark Rutland, Andy Gross, David Brown, Bjorn Andersson,
Joonwoo Park, Jeremy McNicoll
In-Reply-To: <20161031160009.20472-1-michael.scott-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 10/31, Michael Scott wrote:
> +
> +static const struct msm_pingroup msm8994_groups[] = {
> + PINGROUP(0, blsp_spi1, blsp_uart1, blsp_uim1, NA, NA, NA, NA, NA, NA,
> + NA, NA),
I see an hdmi_rcv group here after blsp_uim1. Please add it for
this gpio.
> + PINGROUP(1, blsp_spi1, blsp_uart1, blsp_uim1, NA, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(2, blsp_spi1, blsp_uart1, blsp_i2c1, NA, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(3, blsp_spi1, blsp_uart1, blsp_i2c1, NA, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(4, blsp_spi2, blsp_uart2, blsp_uim2, qdss_cti_trig_out_b,
> + NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(5, blsp_spi2, blsp_uart2, blsp_uim2, qdss_cti_trig_in_b, NA,
The qdss_cti_* is in function 5 for both of these, not function
4.
> + NA, NA, NA, NA, NA, NA),
> + PINGROUP(6, blsp_spi2, blsp_uart2, blsp_i2c2, NA, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(7, blsp_spi2, blsp_uart2, blsp_i2c2, NA, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(8, blsp_spi3, blsp_uart3, blsp_uim3, blsp_spi1_cs1, NA, NA,
> + NA, NA, NA, NA, NA),
> + PINGROUP(9, blsp_spi3, blsp_uart3, blsp_uim3, blsp_spi1_cs2, NA, NA,
> + NA, NA, NA, NA, NA),
> + PINGROUP(10, mdp_vsync, blsp_spi3, blsp_uart3, blsp_i2c3,
> + blsp_spi1_cs3, NA, NA, NA, NA, NA, NA),
> + PINGROUP(11, mdp_vsync, blsp_spi3, blsp_uart3, blsp_i2c3,
> + blsp_spi1_cs2, NA, NA, NA, NA, NA, NA),
> + PINGROUP(12, mdp_vsync, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(13, cam_mclk0, NA, NA, qdss_tracedata_b, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(14, cam_mclk1, NA, NA, qdss_tracedata_b, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(15, cam_mclk2, NA, qdss_tracedata_b, NA, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(16, cam_mclk3, NA, qdss_tracedata_b, NA, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(17, cci_i2c0, blsp_spi4, blsp_uart4, blsp_uim4, NA,
> + qdss_tracedata_b, NA, NA, NA, NA, NA),
> + PINGROUP(18, cci_i2c0, blsp_spi4, blsp_uart4, blsp_uim4, NA,
> + qdss_tracedata_b, NA, NA, NA, NA, NA),
> + PINGROUP(19, cci_i2c1, blsp_spi4, blsp_uart4, blsp_i2c4, NA,
> + qdss_tracedata_b, NA, NA, NA, NA, NA),
> + PINGROUP(20, cci_i2c1, blsp_spi4, blsp_uart4, blsp_i2c4, NA, NA, NA,
> + NA, NA, NA, NA),
> + PINGROUP(21, cci_timer0, blsp_spi5, blsp_uart5, blsp_uim5, NA,
> + qdss_tracedata_b, NA, NA, NA, NA, NA),
> + PINGROUP(22, cci_timer1, blsp_spi5, blsp_uart5, blsp_uim5, NA,
> + qdss_tracedata_b, NA, NA, NA, NA, NA),
> + PINGROUP(23, cci_timer2, blsp_spi5, blsp_uart5, blsp_i2c5, NA, NA,
> + qdss_tracedata_b, NA, NA, NA, NA),
> + PINGROUP(24, cci_timer3, cci_async_in1, blsp_spi5, blsp_uart5,
> + blsp_i2c5, NA, NA, NA, NA, NA, NA),
> + PINGROUP(25, cci_timer4, cci_async_in2, blsp_spi6, blsp_uart6,
> + blsp_uim6, NA, NA, qdss_tracedata_b, NA, NA, NA),
> + PINGROUP(26, cci_async_in0, blsp_spi6, blsp_uart6, blsp_uim6, gp0_clk,
> + NA, qdss_tracedata_b, NA, NA, NA, NA),
> + PINGROUP(27, blsp_spi6, blsp_uart6, blsp_i2c6, gp1_clk,
> + qdss_tracectl_a, NA, NA, NA, NA, NA, NA),
> + PINGROUP(28, blsp_spi6, blsp_uart6, blsp_i2c6, qdss_traceclk_a, NA,
> + NA, NA, NA, NA, NA, NA),
> + PINGROUP(29, gp_mn, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(30, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(31, hdmi_cec, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(32, hdmi_ddc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(33, hdmi_ddc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(34, hdmi_hpd, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(35, uim3, pci_e1, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(36, uim3, pci_e1, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(37, uim3, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(38, uim3, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(39, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(40, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(41, blsp_spi7, blsp_uart7, blsp_uim7, qdss_cti_trig_out_c,
> + NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(42, blsp_spi7, blsp_uart7, blsp_uim7, qdss_cti_trig_in_c, NA,
> + NA, NA, NA, NA, NA, NA),
> + PINGROUP(43, blsp_spi7, blsp_uart7, blsp_i2c7, NA, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(44, blsp_spi7, blsp_uart7, blsp_i2c7, NA, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(45, blsp_spi8, blsp_uart8, blsp_uim8, NA, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(46, blsp_spi8, blsp_uart8, blsp_uim8, NA, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(47, blsp_spi8, blsp_uart8, blsp_i2c8, blsp_spi10_cs1, NA, NA,
> + NA, NA, NA, NA, NA),
> + PINGROUP(48, blsp_spi8, blsp_uart8, blsp_i2c8, blsp_spi10_cs2, NA, NA,
> + NA, NA, NA, NA, NA),
> + PINGROUP(49, uim2, blsp_spi9, blsp_uart9, blsp_uim9, NA, NA, NA, NA,
> + NA, NA, NA),
> + PINGROUP(50, uim2, blsp_spi9, blsp_uart9, blsp_uim9, NA, NA, NA, NA,
> + NA, NA, NA),
> + PINGROUP(51, uim2, blsp_spi9, blsp_uart9, blsp_i2c9, NA, NA, NA, NA,
> + NA, NA, NA),
> + PINGROUP(52, uim2, blsp_spi9, blsp_uart9, blsp_i2c9, NA, NA, NA, NA,
> + NA, NA, NA),
> + PINGROUP(53, uim4, pci_e0, blsp_spi10, blsp_uart10, blsp_uim10, NA,
> + NA, NA, NA, qdss_tracedata_a, NA),
qdss_tracedata_a is at function 8.
> + PINGROUP(54, uim4, pci_e0, blsp_spi10, blsp_uart10, blsp_uim10,
> + gp_pdm0, NA, NA, NA, NA, qdss_tracedata_a),
qdss_tracedata_a is at function 9.
> + PINGROUP(55, uim4, blsp_spi10, blsp_uart10, blsp_i2c10, NA, NA, NA,
> + NA, NA, qdss_cti_trig_in_a, NA),
qdss_cti_trig_in_a is at function 8.
> + PINGROUP(56, uim4, blsp_spi10, blsp_uart10, blsp_i2c10, NA, NA, NA,
> + NA, qdss_cti_trig_out_a, NA, NA),
qdss_cti_trig_out_a is at function 7.
> + PINGROUP(57, qua_mi2s, gcc_gp_clk1, NA, NA, NA, NA, qdss_tracedata_b,
> + NA, NA, NA, NA),
qdss_tracedata_b is at function 5.
> + PINGROUP(58, qua_mi2s, gcc_gp_clk2, NA, NA, NA, NA, qdss_tracedata_b,
> + NA, NA, NA, NA),
qdss_tracedata_b is at function 5.
> + PINGROUP(59, qua_mi2s, gcc_gp_clk3, NA, NA, NA, NA, NA, NA, NA, NA,
> + NA),
> + PINGROUP(60, qua_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(61, qua_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(62, qua_mi2s, blsp_spi2_cs1, NA, NA, NA, NA, NA, NA, NA, NA,
> + NA),
> + PINGROUP(63, qua_mi2s, blsp_spi2_cs2, gp_pdm2, NA, NA, NA, NA, NA,
> + qdss_tracedata_a, NA, NA),
> + PINGROUP(64, pri_mi2s, NA, NA, NA, NA, NA, qdss_tracedata_a, NA, NA,
> + NA, NA),
> + PINGROUP(65, pri_mi2s, NA, NA, NA, NA, NA, qdss_tracedata_a, NA, NA,
> + NA, NA),
qdss_tracedata_a is at function 5 for both of the above.
> + PINGROUP(66, pri_mi2s, blsp_spi2_cs3, NA, NA, NA, NA, NA,
> + qdss_tracedata_a, NA, NA, NA),
> + PINGROUP(67, pri_mi2s, blsp_spi10_cs1, NA, NA, NA, NA, NA,
> + qdss_tracedata_a, NA, NA, NA),
qdss_tracedata_a is at function 6 for both of the above.
> + PINGROUP(68, pri_mi2s, blsp_spi10_cs2, NA, NA, NA, NA, NA, NA, NA, NA,
> + NA),
> + PINGROUP(69, spkr_mi2s, audio_ref_clk, NA, NA, NA, NA, NA, NA, NA, NA,
> + NA),
> + PINGROUP(70, slimbus, spkr_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(71, slimbus, spkr_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(72, spkr_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
Perahps *_mi2s should just be *_i2s here. I don't see any m except for
mclk, which means master and sometimes there are sck for slaves
here.
> + PINGROUP(73, ter_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(74, ter_mi2s, gp_pdm1, NA, NA, NA, NA, NA, qdss_tracedata_a,
These have mi2s though which is fine. Also qdss_tracedata_a is at
function 6.
> + NA, NA, NA),
> + PINGROUP(75, ter_mi2s, NA, NA, NA, NA, qdss_tracedata_a, NA, NA, NA,
> + NA, NA),
> + PINGROUP(76, ter_mi2s, NA, NA, NA, NA, qdss_tracedata_a, NA, NA, NA,
> + NA, NA),
> + PINGROUP(77, ter_mi2s, NA, NA, NA, NA, qdss_tracedata_a, NA, NA, NA,
> + NA, NA),
qdss_tracedata_a is at function 4 for the above 3 gpios.
> + PINGROUP(78, sec_mi2s, gcc_gp_clk1, NA, NA, NA, NA, NA, NA, NA, NA,
> + NA),
> + PINGROUP(79, sec_mi2s, gp_pdm2, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(80, sec_mi2s, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(81, sec_mi2s, blsp_spi11, blsp_uart11, blsp_uim11,
> + gcc_gp_clk2, NA, NA, NA, NA, NA, NA),
> + PINGROUP(82, sec_mi2s, blsp_spi11, blsp_uart11, blsp_uim11,
> + gcc_gp_clk3, NA, NA, NA, NA, NA, NA),
I'd do gcc_gp3_clk and gcc_gp2_clk instead. The number is on the
GP instance. Also, we have _a and _b in the 8996 driver, which
should be copied into here?
> + PINGROUP(83, blsp_spi11, blsp_uart11, blsp_i2c11, NA, NA, NA, NA, NA,
> + NA, NA, NA),
> + PINGROUP(84, blsp_spi11, blsp_uart11, blsp_i2c11, NA, NA, NA, NA, NA,
> + NA, NA, NA),
> + PINGROUP(85, blsp_spi12, blsp_uart12, blsp_uim12, NA, NA,
> + qdss_tracedata_a, NA, NA, NA, NA, NA),
> + PINGROUP(86, blsp_spi12, blsp_uart12, blsp_uim12, gp_pdm1, NA,
> + qdss_tracedata_a, NA, NA, NA, NA, NA),
> + PINGROUP(87, blsp_spi12, blsp_uart12, blsp_i2c12, NA,
> + qdss_tracedata_a, NA, NA, NA, NA, NA, NA),
> + PINGROUP(88, blsp_spi12, blsp_uart12, blsp_i2c12, NA, NA, NA, NA, NA,
> + NA, NA, NA),
> + PINGROUP(89, tsif1, NA, qdss_tracedata_a, NA, NA, NA, NA, NA, NA, NA,
> + NA),
> + PINGROUP(90, tsif1, blsp_spi10_cs3, qdss_tracedata_a, NA, NA, NA, NA,
> + NA, NA, NA, NA),
> + PINGROUP(91, tsif1, sdc4, NA, NA, NA, NA, qdss_traceclk_b, NA, NA, NA,
> + NA),
> + PINGROUP(92, tsif2, sdc4, NA, NA, qdss_tracedata_b, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(93, tsif2, sdc4, NA, NA, NA, NA, qdss_tracedata_b, NA, NA,
> + NA, NA),
> + PINGROUP(94, tsif2, sdc4, NA, NA, NA, NA, qdss_tracectl_b, NA, NA, NA,
> + NA),
> + PINGROUP(95, tsif2, sdc4, gp_pdm0, NA, NA, NA, qdss_cti_trig_out_d,
> + NA, NA, NA, NA),
> + PINGROUP(96, tsif2, sdc4, qdss_cti_trig_in_d, NA, NA, NA, NA, NA, NA,
> + NA, NA),
> + PINGROUP(97, uim1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(98, uim1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(99, uim1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(100, uim1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(101, uim_batt_alarm, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(102, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(103, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(104, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(105, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(106, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(107, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(108, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(109, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(110, tsif1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(111, tsif1, blsp11_uart_tx_b, NA, NA, NA, NA, NA, NA, NA, NA,
> + NA),
> + PINGROUP(112, blsp11_uart_rx_b, NA, NA, NA, NA, NA, NA, NA, NA, NA,
> + NA),
> + PINGROUP(113, blsp11_i2c_sda_b, NA, NA, NA, NA, NA, NA, NA, NA, NA,
> + NA),
> + PINGROUP(114, blsp11_i2c_scl_b, NA, NA, NA, NA, NA, NA, NA, NA, NA,
> + NA),
> + PINGROUP(115, grfc, rffe6, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(116, grfc, rffe6, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(117, grfc, rffe7, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(118, grfc, rffe7, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(119, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(120, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(121, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(122, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(123, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(124, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(125, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(126, grfc, gsm_tx, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(127, grfc, nav_tsync, nav_pps, NA, NA, NA, NA, NA, NA, NA,
> + NA),
> + PINGROUP(128, NA, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(129, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(130, gps_tx, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(131, gsm_tx, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(132, gsm_tx, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(133, gsm_tx, grfc, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(134, mss_lte, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(135, mss_lte, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(136, rffe1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(137, rffe1, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(138, rffe2, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(139, rffe2, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(140, rffe3, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(141, rffe3, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(142, rffe4, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(143, rffe4, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(144, rffe5, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
> + PINGROUP(145, rffe5, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
We've typically left out rffe*, and grfc from this driver. I'd
just leave them out here as well.
> + SDC_PINGROUP(sdc1_rclk, 0x2044, 15, 0),
> + SDC_PINGROUP(sdc1_clk, 0x2044, 13, 6),
> + SDC_PINGROUP(sdc1_cmd, 0x2044, 11, 3),
> + SDC_PINGROUP(sdc1_data, 0x2044, 9, 0),
> + SDC_PINGROUP(sdc2_clk, 0x2048, 14, 6),
> + SDC_PINGROUP(sdc2_cmd, 0x2048, 11, 3),
> + SDC_PINGROUP(sdc2_data, 0x2048, 9, 0),
> + SDC_PINGROUP(sdc3_clk, 0x206c, 14, 6),
> + SDC_PINGROUP(sdc3_cmd, 0x206c, 11, 3),
> + SDC_PINGROUP(sdc3_data, 0x206c, 9, 0),
> +};
> +
> +#define NUM_GPIO_PINGROUPS 146
> +
> +static const struct msm_pinctrl_soc_data msm8994_pinctrl = {
> + .pins = msm8994_pins,
> + .npins = ARRAY_SIZE(msm8994_pins),
> + .functions = msm8994_functions,
> + .nfunctions = ARRAY_SIZE(msm8994_functions),
> + .groups = msm8994_groups,
> + .ngroups = ARRAY_SIZE(msm8994_groups),
> + .ngpios = NUM_GPIO_PINGROUPS,
> +};
> +
> +static int msm8994_pinctrl_probe(struct platform_device *pdev)
> +{
> + return msm_pinctrl_probe(pdev, &msm8994_pinctrl);
> +}
> +
> +static const struct of_device_id msm8994_pinctrl_of_match[] = {
> + { .compatible = "qcom,msm8992-pinctrl", },
> + { .compatible = "qcom,msm8994-pinctrl", },
> + { },
Nitpick: this comma can be removed because this list shouldn't
have any elements after this terminator.
--
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox