Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

On 01/19/2017 06:10 AM, Stephen Boyd wrote:

On 01/18, Bjorn Andersson wrote:

On Tue 17 Jan 22:54 PST 2017, Vivek Gautam wrote:

On 01/16/2017 02:19 PM, Kishon Vijay Abraham I wrote:

On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:

[..]

+   reset-names = "phy", "common", "cfg",
+   "lane0", "lane1", "lane2";

Each lane has a separate clock, separate reset.. why not create sub-nodes for
each lane?

Yes, each lane has separate pipe clock and resets.
I can have a binding such as written below.

+1


Does it makes sense to pull in the tx, rx and pcs offsets as well
to the child node, and iomap the entire address space of the phy ?


Note that you don't have to follow the same structure in your device
driver as you describe your hardware in devicetree.

I would suggest that you replace the lane-offset and various lane
specific resources with subnodes, but keep the driver "as is".


Didn't we already move away from subnodes for lanes in an earlier
revision of these patches? I seem to recall we did that because
lanes are not devices and the whole "phy as a bus" concept not
making sense.


Yea, we started out without having any sub-nodes and we
argued that we don't require them since the qmp device is
represented by the qmp node itself.
The lanes otoh are representative of gen_phys and related properties.

In the driver -
"struct qmp_phy " represents the lanes and holds "struct phy",
"struct qcom_qmp" represents the qmp block as a whole and holds "struct 
device"

Does this make lanes qualify to be childs of qmp ?

"phy as a bus" (just trying to understand here) -
let's say a usb phy controller has one HSIC phy port and one USB2 phy port.
So, should this phy controller be a bus providing two ports (and so we 
will have

couple of child nodes to the phy controller) ?


Regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

On 01/19/2017 06:10 AM, Stephen Boyd wrote:

On 01/18, Bjorn Andersson wrote:

On Tue 17 Jan 22:54 PST 2017, Vivek Gautam wrote:

On 01/16/2017 02:19 PM, Kishon Vijay Abraham I wrote:

On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:

[..]

+   reset-names = "phy", "common", "cfg",
+   "lane0", "lane1", "lane2";

Each lane has a separate clock, separate reset.. why not create sub-nodes for
each lane?

Yes, each lane has separate pipe clock and resets.
I can have a binding such as written below.

+1


Does it makes sense to pull in the tx, rx and pcs offsets as well
to the child node, and iomap the entire address space of the phy ?


Note that you don't have to follow the same structure in your device
driver as you describe your hardware in devicetree.

I would suggest that you replace the lane-offset and various lane
specific resources with subnodes, but keep the driver "as is".


Didn't we already move away from subnodes for lanes in an earlier
revision of these patches? I seem to recall we did that because
lanes are not devices and the whole "phy as a bus" concept not
making sense.


Yea, we started out without having any sub-nodes and we
argued that we don't require them since the qmp device is
represented by the qmp node itself.
The lanes otoh are representative of gen_phys and related properties.

In the driver -
"struct qmp_phy " represents the lanes and holds "struct phy",
"struct qcom_qmp" represents the qmp block as a whole and holds "struct 
device"

Does this make lanes qualify to be childs of qmp ?

"phy as a bus" (just trying to understand here) -
let's say a usb phy controller has one HSIC phy port and one USB2 phy port.
So, should this phy controller be a bus providing two ports (and so we 
will have

couple of child nodes to the phy controller) ?


Regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

Hi Kishon,


On 01/16/2017 02:15 PM, Kishon Vijay Abraham I wrote:

Hi,

On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:

PHY transceiver driver for QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller present on
Qualcomm chipsets.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
---

Changes since v3:
  - Added 'Reviewed-by' from Stephen.
  - Fixed debug message for qusb2_phy_set_tune2_param().
  - Replaced devm_reset_control_get() with devm_reset_control_get_by_index()
since we are requesting only one reset.
  - Updated devm_nvmem_cell_get() with a NULL cell id.
  - Made error labels more idiomatic.
  - Refactored qusb2_setbits() and qusb2_clrbits() a little bit to accept
base address and register offset as two separate arguments.

Changes since v2:
  - Removed selecting 'RESET_CONTROLLER' config.
  - Added error handling for clk_prepare_enable paths.
  - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to
do that since 'xo' is modeled as parent to this clock.
  - Removed 'ref_clk_src' handling. Driver doesn't need to request and
handle this clock.
  - Moved nvmem_cell_get() to probe function.
  - Simplified phy pll status handling.
  - Using of_device_get_match_data() to get match data.
  - Uniformly using lowercase for hex numbers.
  - Fixed sparse warnings.
  - Using shorter variable names in structure and in functions.
  - Handling various comment style shortcomings.

Changes since v1:
  - removed reference to clk_enabled/pwr_enabled.
  - moved clock and regulator enable code to phy_power_on/off() callbacks.
  - fixed return on EPROBE_DEFER in qusb2_phy_probe().
  - fixed phy create and phy register ordering.
  - removed references to non-lkml links from commit message.
  - took care of other minor nits.
  - Fixed coccinelle warnings -
'PTR_ERR applied after initialization to constant'
  - Addressed review comment, regarding qfprom access for tune2 param value.
This driver is now based on qfprom patch[1] that allows byte access now.

  drivers/phy/Kconfig  |  10 +
  drivers/phy/Makefile |   1 +
  drivers/phy/phy-qcom-qusb2.c | 539 +++
  3 files changed, 550 insertions(+)
  create mode 100644 drivers/phy/phy-qcom-qusb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e8eb7f225a88..0ed53d018b23 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -430,6 +430,16 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
  
+config PHY_QCOM_QUSB2

+   tristate "Qualcomm QUSB2 PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
+ controllers on Qualcomm chips. This driver supports the high-speed
+ PHY which is usually paired with either the ChipIdea or Synopsys DWC3
+ USB IPs on MSM SOCs.
+
  config PHY_QCOM_UFS
tristate "Qualcomm UFS PHY driver"
depends on OF && ARCH_QCOM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 65eb2f436a41..dad1682b80e3 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
  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_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
  obj-$(CONFIG_PHY_QCOM_UFS)+= phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
new file mode 100644
index ..c69118610164
--- /dev/null
+++ b/drivers/phy/phy-qcom-qusb2.c
@@ -0,0 +1,539 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define QUSB2PHY_PLL_TEST  0x04
+#define CLK_REF_SELBIT(7)
+
+#define QUSB2PHY_PLL_TUNE  0x08
+#define QUSB2PHY_PLL_USER_C

Re: [PATCH v4 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

Hi Kishon,


On 01/16/2017 02:15 PM, Kishon Vijay Abraham I wrote:

Hi,

On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:

PHY transceiver driver for QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller present on
Qualcomm chipsets.

Signed-off-by: Vivek Gautam 
Reviewed-by: Stephen Boyd 
---

Changes since v3:
  - Added 'Reviewed-by' from Stephen.
  - Fixed debug message for qusb2_phy_set_tune2_param().
  - Replaced devm_reset_control_get() with devm_reset_control_get_by_index()
since we are requesting only one reset.
  - Updated devm_nvmem_cell_get() with a NULL cell id.
  - Made error labels more idiomatic.
  - Refactored qusb2_setbits() and qusb2_clrbits() a little bit to accept
base address and register offset as two separate arguments.

Changes since v2:
  - Removed selecting 'RESET_CONTROLLER' config.
  - Added error handling for clk_prepare_enable paths.
  - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to
do that since 'xo' is modeled as parent to this clock.
  - Removed 'ref_clk_src' handling. Driver doesn't need to request and
handle this clock.
  - Moved nvmem_cell_get() to probe function.
  - Simplified phy pll status handling.
  - Using of_device_get_match_data() to get match data.
  - Uniformly using lowercase for hex numbers.
  - Fixed sparse warnings.
  - Using shorter variable names in structure and in functions.
  - Handling various comment style shortcomings.

Changes since v1:
  - removed reference to clk_enabled/pwr_enabled.
  - moved clock and regulator enable code to phy_power_on/off() callbacks.
  - fixed return on EPROBE_DEFER in qusb2_phy_probe().
  - fixed phy create and phy register ordering.
  - removed references to non-lkml links from commit message.
  - took care of other minor nits.
  - Fixed coccinelle warnings -
'PTR_ERR applied after initialization to constant'
  - Addressed review comment, regarding qfprom access for tune2 param value.
This driver is now based on qfprom patch[1] that allows byte access now.

  drivers/phy/Kconfig  |  10 +
  drivers/phy/Makefile |   1 +
  drivers/phy/phy-qcom-qusb2.c | 539 +++
  3 files changed, 550 insertions(+)
  create mode 100644 drivers/phy/phy-qcom-qusb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e8eb7f225a88..0ed53d018b23 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -430,6 +430,16 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
  
+config PHY_QCOM_QUSB2

+   tristate "Qualcomm QUSB2 PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
+ controllers on Qualcomm chips. This driver supports the high-speed
+ PHY which is usually paired with either the ChipIdea or Synopsys DWC3
+ USB IPs on MSM SOCs.
+
  config PHY_QCOM_UFS
tristate "Qualcomm UFS PHY driver"
depends on OF && ARCH_QCOM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 65eb2f436a41..dad1682b80e3 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
  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_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
  obj-$(CONFIG_PHY_QCOM_UFS)+= phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
new file mode 100644
index ..c69118610164
--- /dev/null
+++ b/drivers/phy/phy-qcom-qusb2.c
@@ -0,0 +1,539 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define QUSB2PHY_PLL_TEST  0x04
+#define CLK_REF_SELBIT(7)
+
+#define QUSB2PHY_PLL_TUNE  0x08
+#define QUSB2PHY_PLL_USER_CTL1 0x0c
+#define QUSB2PHY_PLL_USER_CTL2 0x1

Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Hi Kishon,


On 01/16/2017 02:19 PM, Kishon Vijay Abraham I wrote:

Hi,

On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Rob Herring <r...@kernel.org>
---

Changes since v3:
  - Added #clock-cells = <1>, indicating that phy is a clock provider.

Changes since v2:
  - Removed binding for "ref_clk_src" since we don't request this
clock in the driver.
  - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
  - Using 'phy' for the node name.

Changes since v1:
  - New patch, forked out of the original driver patch:
"phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
  - Added 'Acked-by' from Rob.
  - Updated bindings to include mem resource as a list of
offset - length pair for serdes block and for each lane.
  - Added a new binding for 'lane-offsets' that contains offsets
to tx, rx and pcs blocks from each lane base address.

  .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 76 ++
  1 file changed, 76 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

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 ..6f510fe48f46
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,76 @@
+Qualcomm QMP PHY controller
+===
+
+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: list of offset and length pair of the PHY register sets.
+   at index 0: offset and length of register set for PHY common
+   serdes block.
+   from index 1 - N: offset and length of register set for each lane,
+ for N number of phy lanes (ports).
+ - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
+ - #phy-cells: must be 1
+- Cell after phy phandle should be the port (lane) number.
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+  interface (for pipe based PHYs). These clock are then gate-controlled
+  by gcc.
+ - 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" for 19.2 MHz ref clk,
+   "pipe" 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" 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: phy@34000 {
+   compatible = "qcom,msm8996-qmp-pcie-phy";
+   reg = <0x034000 0x48f>,
+   <0x035000 0x5bf>,
+   <0x036000 0x5bf>,
+   <0x037000 0x5bf>;
+   /* tx, rx, pcs */
+   lane-offsets = <0x0 0x200 0x400>;
+   #phy-cells = <1>;
+   #clock-cells = <1>;
+
+   clocks = < GCC_PCIE_PHY_AUX_CLK>,
+   < GCC_PCIE_PHY_CFG_AHB_CLK>,
+   < GCC_PCIE_CLKREF_CLK>,
+   < GCC_PCIE_0_PIPE_CLK>,
+   < GCC_PCIE_1_PIPE_CLK>,
+   < GCC_PCIE_2_PIPE_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref",
+   "pipe0", "pipe1", "pipe2";
+
+   vdda-phy-supply = <_l28>;
+   vdda-pll-supply = <_l12>;
+
+   resets = < GCC_PCIE_PHY_B

Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Hi Kishon,


On 01/16/2017 02:19 PM, Kishon Vijay Abraham I wrote:

Hi,

On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam 
Acked-by: Rob Herring 
---

Changes since v3:
  - Added #clock-cells = <1>, indicating that phy is a clock provider.

Changes since v2:
  - Removed binding for "ref_clk_src" since we don't request this
clock in the driver.
  - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
  - Using 'phy' for the node name.

Changes since v1:
  - New patch, forked out of the original driver patch:
"phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
  - Added 'Acked-by' from Rob.
  - Updated bindings to include mem resource as a list of
offset - length pair for serdes block and for each lane.
  - Added a new binding for 'lane-offsets' that contains offsets
to tx, rx and pcs blocks from each lane base address.

  .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 76 ++
  1 file changed, 76 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

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 ..6f510fe48f46
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,76 @@
+Qualcomm QMP PHY controller
+===
+
+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: list of offset and length pair of the PHY register sets.
+   at index 0: offset and length of register set for PHY common
+   serdes block.
+   from index 1 - N: offset and length of register set for each lane,
+ for N number of phy lanes (ports).
+ - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
+ - #phy-cells: must be 1
+- Cell after phy phandle should be the port (lane) number.
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+  interface (for pipe based PHYs). These clock are then gate-controlled
+  by gcc.
+ - 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" for 19.2 MHz ref clk,
+   "pipe" 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" 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: phy@34000 {
+   compatible = "qcom,msm8996-qmp-pcie-phy";
+   reg = <0x034000 0x48f>,
+   <0x035000 0x5bf>,
+   <0x036000 0x5bf>,
+   <0x037000 0x5bf>;
+   /* tx, rx, pcs */
+   lane-offsets = <0x0 0x200 0x400>;
+   #phy-cells = <1>;
+   #clock-cells = <1>;
+
+   clocks = < GCC_PCIE_PHY_AUX_CLK>,
+   < GCC_PCIE_PHY_CFG_AHB_CLK>,
+   < GCC_PCIE_CLKREF_CLK>,
+   < GCC_PCIE_0_PIPE_CLK>,
+   < GCC_PCIE_1_PIPE_CLK>,
+   < GCC_PCIE_2_PIPE_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref",
+   "pipe0", "pipe1", "pipe2";
+
+   vdda-phy-supply = <_l28>;
+   vdda-pll-supply = <_l12>;
+
+   resets = < GCC_PCIE_PHY_BCR>,
+   < GCC_PCIE_PHY_COM_BCR>,
+   

Re: [PATCH v4 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Hi,


On 01/11/2017 04:50 AM, Andy Gross wrote:

On Tue, Jan 10, 2017 at 04:21:59PM +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.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Tested-by: Srinivas Kandagatla <srinivas.kandaga...@linaro.org>
---

< snip>


+static const struct of_device_id qcom_qmp_phy_of_match_table[] = {
+   {
+   .compatible = "qcom,msm8996-qmp-pcie-phy",
+   .data = _pciephy_cfg,
+   }, {
+   .compatible = "qcom,msm8996-qmp-usb3-phy",
+   .data = _usb3phy_cfg,
+   },

Which other chips would this driver support?


msm8998 has the same combo PHY IP. We may need
minor changes in the initialization tables to support that.


Regards
Vivek




Regards,

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


--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Hi,


On 01/11/2017 04:50 AM, Andy Gross wrote:

On Tue, Jan 10, 2017 at 04:21:59PM +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.

Signed-off-by: Vivek Gautam 
Tested-by: Srinivas Kandagatla 
---

< snip>


+static const struct of_device_id qcom_qmp_phy_of_match_table[] = {
+   {
+   .compatible = "qcom,msm8996-qmp-pcie-phy",
+   .data = _pciephy_cfg,
+   }, {
+   .compatible = "qcom,msm8996-qmp-usb3-phy",
+   .data = _usb3phy_cfg,
+   },

Which other chips would this driver support?


msm8998 has the same combo PHY IP. We may need
minor changes in the initialization tables to support that.


Regards
Vivek




Regards,

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


--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling

[vivek . gautam]

On 2017-01-10 22:39, Bartlomiej Zolnierkiewicz wrote:

Hi,

On Tuesday, January 10, 2017 09:28:52 AM Shuah Khan wrote:

On 01/10/2017 09:05 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Tuesday, January 10, 2017 07:36:35 AM Shuah Khan wrote:
>> On 01/10/2017 07:16 AM, Shuah Khan wrote:
>>> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
>>>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>>>>> clock is specified. Call clk_disable_unprepare() from remove and probe
>>>>> error path only when susp_clk has been set from remove and probe error
>>>>> paths.
>>>>
>>>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
>>>> for NULL clock.  Also your patch changes susp_clk handling while
>>>> leaves axius_clk handling (which also can be NULL) untouched.
>>>>
>>>> Do you actually see some runtime problem with the current code?
>>>>
>>>> If not then the patch should probably be dropped.
>>>>
>>>> Best regards,
>>>> --
>>>> Bartlomiej Zolnierkiewicz
>>>> Samsung R Institute Poland
>>>> Samsung Electronics
>>>
>>> Hi Bartlomiej,
>>>
>>> I am seeing the "no suspend clk specified" message in dmesg.
>>> After that it sets the exynos->susp_clk = NULL and starts
>>> calling clk_prepare_enable(exynos->susp_clk);
>>>
>>> That can't be good. If you see the logic right above this
>>> one for exynos->clk, it returns error and fails the probe.
>>> This this case it doesn't, but tries to use null susp_clk.
>
> exynos->susp_clk is optional, exynos->clk is not.

Right. That is clear since we don't fail the probe.

>
>>> I believe this patch is necessary.
>>
>> Let me clarify this a bit further. Since we already know
>> susp_clk is null, with this patch we can avoid extra calls
>> to clk_prepare_enable() and clk_disable_unprepare().
>>
>> One can say, it also adds extra checks, hence I will let you
>> decide one way or the other. :)


Hi Shuah Khan,

Like Bartlomiej mentioned below, it is completely fair to call
clk_prepare_enable() with NULL clocks. That's how most of the
optional clocks are handled in the kernel. So, i don't think
there's any need of adding an additional check for the 
'exynos->susp_clk'.


The 'exynos->clk' is the main IP clock that is mandatory, and hence
the probe fails in case that is not present.


>
> I would prefer to leave the things as they are currently.
>
> The code in question is not performance sensitive so extra
> calls are not a problem.  No extra checks means less code.
>
> Also the current code seems to be more in line with the rest
> of the kernel.

What functionality is missing without the suspend clock? Would
it make sense to change the info. message to include what it
means. At the moment it doesn't anything more than "no suspend
clock" which is a very cryptic user visible message. It would be
helpful for it to also include what functionality is impacted.


Well, all I know is what the original commit descriptions says and
that the commit itself comes from patchset adding Exynos7 USB 3.0
support [1]:

commit 72d996fc7a01c2e4d581a15db7d001e2799ffb29
Author: Vivek Gautam <gautam.vi...@samsung.com>
Date:   Fri Nov 21 19:05:46 2014 +0530

usb: dwc3: exynos: Add provision for suspend clock

DWC3 controller on Exynos SoC series have separate control for
suspend clock which replaces pipe3_rx_pclk as clock source to
a small part of DWC3 core that operates when SS PHY is in its
lowest power state (P3) in states SS.disabled and U3.

Suggested-by: Anton Tikhomirov <av.tikhomi...@samsung.com>
Signed-off-by: Vivek Gautam <gautam.vi...@samsung.com>
Signed-off-by: Felipe Balbi <ba...@ti.com>



Hi Bartlomiej,


Anton's & Vivek's Samsung email addresses are no longer valid but
I added current Vivek's email address to Cc:.


Thanks for adding me to the thread.



BTW What is interesting is that the Exynos7 dts patch [2] has never
made it into upstream for some reason.  In the meantime however
Exynos5433 (similar to Exynos7 to some degree) became the user of
susp_clk.


You are right. The exynos7 device tree patches could not make it to
upstream for some reasons. I think there are few guys looking at USB
for Exynos.
If there's something needed on Exynos7 USB side, i have added
Pankaj Dubey <pankaj.du...@samsung.com> to this thread.

Hi Pankaj,
I am adding you to please help us with any future requirements
for exynos USB in the upstream.
Thanks!



[1] https://lkml.org/lkml/2014/11/21/247
[2] https://patchwork.kernel.org/patch/5355161/

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


[snip]


Best Regards
Vivek

Re: [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling

[vivek . gautam]

On 2017-01-10 22:39, Bartlomiej Zolnierkiewicz wrote:

Hi,

On Tuesday, January 10, 2017 09:28:52 AM Shuah Khan wrote:

On 01/10/2017 09:05 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Tuesday, January 10, 2017 07:36:35 AM Shuah Khan wrote:
>> On 01/10/2017 07:16 AM, Shuah Khan wrote:
>>> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
>>>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>>>>> clock is specified. Call clk_disable_unprepare() from remove and probe
>>>>> error path only when susp_clk has been set from remove and probe error
>>>>> paths.
>>>>
>>>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
>>>> for NULL clock.  Also your patch changes susp_clk handling while
>>>> leaves axius_clk handling (which also can be NULL) untouched.
>>>>
>>>> Do you actually see some runtime problem with the current code?
>>>>
>>>> If not then the patch should probably be dropped.
>>>>
>>>> Best regards,
>>>> --
>>>> Bartlomiej Zolnierkiewicz
>>>> Samsung R Institute Poland
>>>> Samsung Electronics
>>>
>>> Hi Bartlomiej,
>>>
>>> I am seeing the "no suspend clk specified" message in dmesg.
>>> After that it sets the exynos->susp_clk = NULL and starts
>>> calling clk_prepare_enable(exynos->susp_clk);
>>>
>>> That can't be good. If you see the logic right above this
>>> one for exynos->clk, it returns error and fails the probe.
>>> This this case it doesn't, but tries to use null susp_clk.
>
> exynos->susp_clk is optional, exynos->clk is not.

Right. That is clear since we don't fail the probe.

>
>>> I believe this patch is necessary.
>>
>> Let me clarify this a bit further. Since we already know
>> susp_clk is null, with this patch we can avoid extra calls
>> to clk_prepare_enable() and clk_disable_unprepare().
>>
>> One can say, it also adds extra checks, hence I will let you
>> decide one way or the other. :)


Hi Shuah Khan,

Like Bartlomiej mentioned below, it is completely fair to call
clk_prepare_enable() with NULL clocks. That's how most of the
optional clocks are handled in the kernel. So, i don't think
there's any need of adding an additional check for the 
'exynos->susp_clk'.


The 'exynos->clk' is the main IP clock that is mandatory, and hence
the probe fails in case that is not present.


>
> I would prefer to leave the things as they are currently.
>
> The code in question is not performance sensitive so extra
> calls are not a problem.  No extra checks means less code.
>
> Also the current code seems to be more in line with the rest
> of the kernel.

What functionality is missing without the suspend clock? Would
it make sense to change the info. message to include what it
means. At the moment it doesn't anything more than "no suspend
clock" which is a very cryptic user visible message. It would be
helpful for it to also include what functionality is impacted.


Well, all I know is what the original commit descriptions says and
that the commit itself comes from patchset adding Exynos7 USB 3.0
support [1]:

commit 72d996fc7a01c2e4d581a15db7d001e2799ffb29
Author: Vivek Gautam 
Date:   Fri Nov 21 19:05:46 2014 +0530

usb: dwc3: exynos: Add provision for suspend clock

DWC3 controller on Exynos SoC series have separate control for
suspend clock which replaces pipe3_rx_pclk as clock source to
a small part of DWC3 core that operates when SS PHY is in its
lowest power state (P3) in states SS.disabled and U3.

Suggested-by: Anton Tikhomirov 
Signed-off-by: Vivek Gautam 
Signed-off-by: Felipe Balbi 



Hi Bartlomiej,


Anton's & Vivek's Samsung email addresses are no longer valid but
I added current Vivek's email address to Cc:.


Thanks for adding me to the thread.



BTW What is interesting is that the Exynos7 dts patch [2] has never
made it into upstream for some reason.  In the meantime however
Exynos5433 (similar to Exynos7 to some degree) became the user of
susp_clk.


You are right. The exynos7 device tree patches could not make it to
upstream for some reasons. I think there are few guys looking at USB
for Exynos.
If there's something needed on Exynos7 USB side, i have added
Pankaj Dubey  to this thread.

Hi Pankaj,
I am adding you to please help us with any future requirements
for exynos USB in the upstream.
Thanks!



[1] https://lkml.org/lkml/2014/11/21/247
[2] https://patchwork.kernel.org/patch/5355161/

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


[snip]


Best Regards
Vivek

[PATCH v4 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

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.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Tested-by: Srinivas Kandagatla <srinivas.kandaga...@linaro.org>
---

Changes since v3:
 - Renamed 'struct qcom_qmp_phy' to 'struct qcom_qmp' and
   'struct qmp_phy_desc' to 'struct qmp_phy' to avoid any confusion
   in distinguishing between QMP phy block and per-lane phy which is
   the actual phy in Linux eyes (suggested by Bjorn Andersson).
 - Made error labels more idiomatic.
 - Modified status checking for phy pcs.
 - Fixed power_down_delay check.
 - Refactored phy_pipe_clk_register() to register the pipe clock source
   using devm_clk_hw_register() (suggested by Stephen).
 - qcom_qmp_phy_xlate() function:
   - Removed unnecessary 'for loop'.
   - Added additional check for '0' or -ve args_count.
 - Fixed the mixed tabs and spaces in pipe_clk_src diagram.
 - Removed instances of memset() since we use snprintf() for the
   buffers.
 - Refactored qphy_setbits() and qphy_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Using readl_poll_timeout() to simplify pcs ready status polling.
   Also fixed the polling condition for pcs block ready status:
   'Common block ready status bit is set on phy init completion, while
   PCS block ready status bit (PHYSTATUS) is reset on phy init
   completion.'
 - Moved out the per-lane phy creation from probe() to separate
   function.
 - Registering pipe clock source as a fixed rate clock that comes
   out of the PLL block of QMP phy. These source clocks serve as
   parent to 'pipe_clks' that are requested by pcie or usb3 phys.
 - Using of_device_get_match_data() to get match data.
 - Fixed sparse warnings for 'static' and 'const'.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - Fixed missing mutex_unlock() calls in error cases, reported by
   Julia Lawall.
 - Selecting CONFIG_RESET_CONTROLLER when this driver is enabled.
 - Added a boolean property to check if the phy has individual lane
   reset available.
 - Took care or EPROBE_DEFER, dev_vdbg() and other minor nits.
 - Removed references to non-lkml links from commit message.
 - Moved to use separate iomem resources for each lanes.
   Tx, Rx and PCS offsets per lane can now come from dt bindings.

 drivers/phy/Kconfig|8 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-qcom-qmp.c | 1206 
 3 files changed, 1215 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qmp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 0ed53d018b23..54296397452c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -430,6 +430,14 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+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 dad1682b80e3..dbe7731bbca9 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,6 +50,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_QCOM_QUSB2)   += phy-qcom-qusb2.o
+obj-$(CONFIG_PHY_QCOM_QMP) += phy-qcom-qmp.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c
new file mode 100644
index ..cff01c815c20
--- /dev/null
+++ b/drivers/phy/phy-qcom-qmp.c
@@ -0,0 +1,1206 @@
+/*
+ * 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 im

[PATCH v4 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

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.

Signed-off-by: Vivek Gautam 
Tested-by: Srinivas Kandagatla 
---

Changes since v3:
 - Renamed 'struct qcom_qmp_phy' to 'struct qcom_qmp' and
   'struct qmp_phy_desc' to 'struct qmp_phy' to avoid any confusion
   in distinguishing between QMP phy block and per-lane phy which is
   the actual phy in Linux eyes (suggested by Bjorn Andersson).
 - Made error labels more idiomatic.
 - Modified status checking for phy pcs.
 - Fixed power_down_delay check.
 - Refactored phy_pipe_clk_register() to register the pipe clock source
   using devm_clk_hw_register() (suggested by Stephen).
 - qcom_qmp_phy_xlate() function:
   - Removed unnecessary 'for loop'.
   - Added additional check for '0' or -ve args_count.
 - Fixed the mixed tabs and spaces in pipe_clk_src diagram.
 - Removed instances of memset() since we use snprintf() for the
   buffers.
 - Refactored qphy_setbits() and qphy_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Using readl_poll_timeout() to simplify pcs ready status polling.
   Also fixed the polling condition for pcs block ready status:
   'Common block ready status bit is set on phy init completion, while
   PCS block ready status bit (PHYSTATUS) is reset on phy init
   completion.'
 - Moved out the per-lane phy creation from probe() to separate
   function.
 - Registering pipe clock source as a fixed rate clock that comes
   out of the PLL block of QMP phy. These source clocks serve as
   parent to 'pipe_clks' that are requested by pcie or usb3 phys.
 - Using of_device_get_match_data() to get match data.
 - Fixed sparse warnings for 'static' and 'const'.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - Fixed missing mutex_unlock() calls in error cases, reported by
   Julia Lawall.
 - Selecting CONFIG_RESET_CONTROLLER when this driver is enabled.
 - Added a boolean property to check if the phy has individual lane
   reset available.
 - Took care or EPROBE_DEFER, dev_vdbg() and other minor nits.
 - Removed references to non-lkml links from commit message.
 - Moved to use separate iomem resources for each lanes.
   Tx, Rx and PCS offsets per lane can now come from dt bindings.

 drivers/phy/Kconfig|8 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-qcom-qmp.c | 1206 
 3 files changed, 1215 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qmp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 0ed53d018b23..54296397452c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -430,6 +430,14 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+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 dad1682b80e3..dbe7731bbca9 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,6 +50,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_QCOM_QUSB2)   += phy-qcom-qusb2.o
+obj-$(CONFIG_PHY_QCOM_QMP) += phy-qcom-qmp.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c
new file mode 100644
index ..cff01c815c20
--- /dev/null
+++ b/drivers/phy/phy-qcom-qmp.c
@@ -0,0 +1,1206 @@
+/*
+ * 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.  Se

[PATCH v4 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

Qualcomm chipsets have QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Rob Herring <r...@kernel.org>
---

Changes since v3:
 - Added 'Acked-by' from Rob.
 - Removed 'reset-names' and 'nvmem-cell-names' from the bindings
   since we use only one cell.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/vdda-phy-dpdm/vdda-phy-dpdm-supply.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Addressed s/tune2_hstx_trim_efuse/tune2_hstx_trim. Don't need to add
   'efuse' suffix to nvmem cell.
 - Addressed s/qusb2phy/phy for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
 - Updated dt bindings to remove 'hstx-trim-bit-offset' and
   'hstx-trim-bit-len' bindings.

 .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
new file mode 100644
index ..218595fe8824
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -0,0 +1,45 @@
+Qualcomm QUSB2 phy controller
+=
+
+QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+Required properties:
+ - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - 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,
+   "ref" for 19.2 MHz ref clk,
+   "iface" for phy interface clock (Optional).
+
+ - vdd-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.
+ - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
signals.
+
+ - resets: Phandle to reset to phy block.
+
+Optional properties:
+ - nvmem-cells: Phandle to nvmem cell that contains 'HS Tx trim'
+   tuning parameter value for qusb2 phy.
+
+ - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+
+Example:
+   hsusb_phy: phy@7411000 {
+   compatible = "qcom,msm8996-qusb2-phy";
+   reg = <0x07411000 0x180>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+   < GCC_RX1_USB2_CLKREF_CLK>,
+   clock-names = "cfg_ahb", "ref";
+
+   vdd-phy-supply = <_s2>;
+   vdda-pll-supply = <_l12>;
+   vdda-phy-dpdm-supply = <_l24>;
+
+   resets = < GCC_QUSB2PHY_PRIM_BCR>;
+   nvmem-cells = <_hstx_trim>;
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
   USB3, PCIe, UFS and few other controllers.

The patches are based on next branch of linux-phy tree.

These have been tested on Dragon board db820c hardware with
required set of dt patches on integration tree maintained by
Linaro landing team for Qualcomm [1].

Couple of other patches [2,3,4] for nvmem are also pulled in for testing.
Patch series fixing DMA config for XHCI [5] is also pulled in for testing.

Changes since v3:
 - Addressed review comments given by Rob and Stephen for qusb2 phy
   and qmp phy bindings respectively.
 - Addressed review comments given by Stephen and Bjorn for qmp phy driver.

Changes since v2:
 - Addressed review comments given by Rob and Stephen for bindings.
 - Addressed the review comments given by Stephen for the qusb2 and qmp
   phy drivers.

Changes since v1:
 - Moved device tree binding documentation to separate patches, as suggested
   by Rob.
 - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
   given by Rob.
 - Addressed review comments from Kishon.
 - Addressed review comments from Srinivas for QMP phy driver.
 - Addressed kbuild warning.

Please see individual patches for detailed changelogs.

[1] 
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=integration-linux-qcomlt
[2] https://lkml.org/lkml/2016/11/17/21
[3] https://lkml.org/lkml/2016/12/19/18
[4] http://www.spinics.net/lists/linux-arm-msm/msg25483.html
[5] https://lkml.org/lkml/2016/11/17/339

Vivek Gautam (4):
  dt-bindings: phy: Add support for QUSB2 phy
  phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
  dt-bindings: phy: Add support for QMP phy
  phy: qcom-qmp: new qmp phy driver for qcom-chipsets

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   |   76 ++
 .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   45 +
 drivers/phy/Kconfig|   18 +
 drivers/phy/Makefile   |2 +
 drivers/phy/phy-qcom-qmp.c | 1206 
 drivers/phy/phy-qcom-qusb2.c   |  539 +
 6 files changed, 1886 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
 create mode 100644 drivers/phy/phy-qcom-qmp.c
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

Qualcomm chipsets have QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam 
Acked-by: Rob Herring 
---

Changes since v3:
 - Added 'Acked-by' from Rob.
 - Removed 'reset-names' and 'nvmem-cell-names' from the bindings
   since we use only one cell.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/vdda-phy-dpdm/vdda-phy-dpdm-supply.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Addressed s/tune2_hstx_trim_efuse/tune2_hstx_trim. Don't need to add
   'efuse' suffix to nvmem cell.
 - Addressed s/qusb2phy/phy for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
 - Updated dt bindings to remove 'hstx-trim-bit-offset' and
   'hstx-trim-bit-len' bindings.

 .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
new file mode 100644
index ..218595fe8824
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -0,0 +1,45 @@
+Qualcomm QUSB2 phy controller
+=
+
+QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+Required properties:
+ - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - 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,
+   "ref" for 19.2 MHz ref clk,
+   "iface" for phy interface clock (Optional).
+
+ - vdd-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.
+ - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
signals.
+
+ - resets: Phandle to reset to phy block.
+
+Optional properties:
+ - nvmem-cells: Phandle to nvmem cell that contains 'HS Tx trim'
+   tuning parameter value for qusb2 phy.
+
+ - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+
+Example:
+   hsusb_phy: phy@7411000 {
+   compatible = "qcom,msm8996-qusb2-phy";
+   reg = <0x07411000 0x180>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+   < GCC_RX1_USB2_CLKREF_CLK>,
+   clock-names = "cfg_ahb", "ref";
+
+   vdd-phy-supply = <_s2>;
+   vdda-pll-supply = <_l12>;
+   vdda-phy-dpdm-supply = <_l24>;
+
+   resets = < GCC_QUSB2PHY_PRIM_BCR>;
+   nvmem-cells = <_hstx_trim>;
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
   USB3, PCIe, UFS and few other controllers.

The patches are based on next branch of linux-phy tree.

These have been tested on Dragon board db820c hardware with
required set of dt patches on integration tree maintained by
Linaro landing team for Qualcomm [1].

Couple of other patches [2,3,4] for nvmem are also pulled in for testing.
Patch series fixing DMA config for XHCI [5] is also pulled in for testing.

Changes since v3:
 - Addressed review comments given by Rob and Stephen for qusb2 phy
   and qmp phy bindings respectively.
 - Addressed review comments given by Stephen and Bjorn for qmp phy driver.

Changes since v2:
 - Addressed review comments given by Rob and Stephen for bindings.
 - Addressed the review comments given by Stephen for the qusb2 and qmp
   phy drivers.

Changes since v1:
 - Moved device tree binding documentation to separate patches, as suggested
   by Rob.
 - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
   given by Rob.
 - Addressed review comments from Kishon.
 - Addressed review comments from Srinivas for QMP phy driver.
 - Addressed kbuild warning.

Please see individual patches for detailed changelogs.

[1] 
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=integration-linux-qcomlt
[2] https://lkml.org/lkml/2016/11/17/21
[3] https://lkml.org/lkml/2016/12/19/18
[4] http://www.spinics.net/lists/linux-arm-msm/msg25483.html
[5] https://lkml.org/lkml/2016/11/17/339

Vivek Gautam (4):
  dt-bindings: phy: Add support for QUSB2 phy
  phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
  dt-bindings: phy: Add support for QMP phy
  phy: qcom-qmp: new qmp phy driver for qcom-chipsets

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   |   76 ++
 .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   45 +
 drivers/phy/Kconfig|   18 +
 drivers/phy/Makefile   |2 +
 drivers/phy/phy-qcom-qmp.c | 1206 
 drivers/phy/phy-qcom-qusb2.c   |  539 +
 6 files changed, 1886 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
 create mode 100644 drivers/phy/phy-qcom-qmp.c
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Rob Herring <r...@kernel.org>
---

Changes since v3:
 - Added #clock-cells = <1>, indicating that phy is a clock provider.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Using 'phy' for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
 - Added 'Acked-by' from Rob.
 - Updated bindings to include mem resource as a list of
   offset - length pair for serdes block and for each lane.
 - Added a new binding for 'lane-offsets' that contains offsets
   to tx, rx and pcs blocks from each lane base address.

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 76 ++
 1 file changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

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 ..6f510fe48f46
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,76 @@
+Qualcomm QMP PHY controller
+===
+
+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: list of offset and length pair of the PHY register sets.
+   at index 0: offset and length of register set for PHY common
+   serdes block.
+   from index 1 - N: offset and length of register set for each lane,
+ for N number of phy lanes (ports).
+ - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
+ - #phy-cells: must be 1
+- Cell after phy phandle should be the port (lane) number.
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+  interface (for pipe based PHYs). These clock are then gate-controlled
+  by gcc.
+ - 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" for 19.2 MHz ref clk,
+   "pipe" 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" 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: phy@34000 {
+   compatible = "qcom,msm8996-qmp-pcie-phy";
+   reg = <0x034000 0x48f>,
+   <0x035000 0x5bf>,
+   <0x036000 0x5bf>,
+   <0x037000 0x5bf>;
+   /* tx, rx, pcs */
+   lane-offsets = <0x0 0x200 0x400>;
+   #phy-cells = <1>;
+   #clock-cells = <1>;
+
+   clocks = < GCC_PCIE_PHY_AUX_CLK>,
+   < GCC_PCIE_PHY_CFG_AHB_CLK>,
+   < GCC_PCIE_CLKREF_CLK>,
+   < GCC_PCIE_0_PIPE_CLK>,
+   < GCC_PCIE_1_PIPE_CLK>,
+   < GCC_PCIE_2_PIPE_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref",
+   "pipe0", "pipe1", "pipe2";
+
+   vdda-phy-supply = <_l28>;
+   vdda-pll-supply = <_l12>;
+
+   resets = < GCC_PCIE_PHY_BCR>,
+   < GCC_PCIE_PHY_COM_BCR>,
+   < GCC_PCIE_PHY_COM_NOCSR_BCR>,
+   < GCC_PC

[PATCH v4 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

PHY transceiver driver for QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller present on
Qualcomm chipsets.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
---

Changes since v3:
 - Added 'Reviewed-by' from Stephen.
 - Fixed debug message for qusb2_phy_set_tune2_param().
 - Replaced devm_reset_control_get() with devm_reset_control_get_by_index()
   since we are requesting only one reset.
 - Updated devm_nvmem_cell_get() with a NULL cell id.
 - Made error labels more idiomatic.
 - Refactored qusb2_setbits() and qusb2_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to
   do that since 'xo' is modeled as parent to this clock.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Moved nvmem_cell_get() to probe function.
 - Simplified phy pll status handling.
 - Using of_device_get_match_data() to get match data.
 - Uniformly using lowercase for hex numbers.
 - Fixed sparse warnings.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - removed reference to clk_enabled/pwr_enabled.
 - moved clock and regulator enable code to phy_power_on/off() callbacks.
 - fixed return on EPROBE_DEFER in qusb2_phy_probe().
 - fixed phy create and phy register ordering.
 - removed references to non-lkml links from commit message.
 - took care of other minor nits.
 - Fixed coccinelle warnings -
   'PTR_ERR applied after initialization to constant'
 - Addressed review comment, regarding qfprom access for tune2 param value.
   This driver is now based on qfprom patch[1] that allows byte access now.

 drivers/phy/Kconfig  |  10 +
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-qcom-qusb2.c | 539 +++
 3 files changed, 550 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e8eb7f225a88..0ed53d018b23 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -430,6 +430,16 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_QCOM_QUSB2
+   tristate "Qualcomm QUSB2 PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
+ controllers on Qualcomm chips. This driver supports the high-speed
+ PHY which is usually paired with either the ChipIdea or Synopsys DWC3
+ USB IPs on MSM SOCs.
+
 config PHY_QCOM_UFS
tristate "Qualcomm UFS PHY driver"
depends on OF && ARCH_QCOM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 65eb2f436a41..dad1682b80e3 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
 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_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
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
new file mode 100644
index ..c69118610164
--- /dev/null
+++ b/drivers/phy/phy-qcom-qusb2.c
@@ -0,0 +1,539 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define QUSB2PHY_PLL_TEST  0x04
+#define CLK_REF_SELBIT(7)
+
+#define QUSB2PHY_PLL_TUNE  0x08
+#define QUSB2PHY_PLL_USER_CTL1 0x0c
+#define QUSB2PHY_PLL_USER_CTL2 0x10
+#define QUSB2PHY_PLL_AUTOPGM_CTL1  0x1c
+#define QUSB2PHY_PLL_PWR_CTRL  0x18
+
+#define QUSB2PH

[PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam 
Acked-by: Rob Herring 
---

Changes since v3:
 - Added #clock-cells = <1>, indicating that phy is a clock provider.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Using 'phy' for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
 - Added 'Acked-by' from Rob.
 - Updated bindings to include mem resource as a list of
   offset - length pair for serdes block and for each lane.
 - Added a new binding for 'lane-offsets' that contains offsets
   to tx, rx and pcs blocks from each lane base address.

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 76 ++
 1 file changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

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 ..6f510fe48f46
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,76 @@
+Qualcomm QMP PHY controller
+===
+
+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: list of offset and length pair of the PHY register sets.
+   at index 0: offset and length of register set for PHY common
+   serdes block.
+   from index 1 - N: offset and length of register set for each lane,
+ for N number of phy lanes (ports).
+ - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
+ - #phy-cells: must be 1
+- Cell after phy phandle should be the port (lane) number.
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+  interface (for pipe based PHYs). These clock are then gate-controlled
+  by gcc.
+ - 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" for 19.2 MHz ref clk,
+   "pipe" 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" 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: phy@34000 {
+   compatible = "qcom,msm8996-qmp-pcie-phy";
+   reg = <0x034000 0x48f>,
+   <0x035000 0x5bf>,
+   <0x036000 0x5bf>,
+   <0x037000 0x5bf>;
+   /* tx, rx, pcs */
+   lane-offsets = <0x0 0x200 0x400>;
+   #phy-cells = <1>;
+   #clock-cells = <1>;
+
+   clocks = < GCC_PCIE_PHY_AUX_CLK>,
+   < GCC_PCIE_PHY_CFG_AHB_CLK>,
+   < GCC_PCIE_CLKREF_CLK>,
+   < GCC_PCIE_0_PIPE_CLK>,
+   < GCC_PCIE_1_PIPE_CLK>,
+   < GCC_PCIE_2_PIPE_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref",
+   "pipe0", "pipe1", "pipe2";
+
+   vdda-phy-supply = <_l28>;
+   vdda-pll-supply = <_l12>;
+
+   resets = < GCC_PCIE_PHY_BCR>,
+   < GCC_PCIE_PHY_COM_BCR>,
+   < GCC_PCIE_PHY_COM_NOCSR_BCR>,
+   < GCC_PCIE_0_PHY_BCR>,
+   < GCC_PCIE_1_PHY_BCR>,
+   < GCC_PCIE_2_PHY_BCR>;
+   reset-names = "phy", "common", "cfg",
+   "lane0", "lane1", "lane2";
+   };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

PHY transceiver driver for QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller present on
Qualcomm chipsets.

Signed-off-by: Vivek Gautam 
Reviewed-by: Stephen Boyd 
---

Changes since v3:
 - Added 'Reviewed-by' from Stephen.
 - Fixed debug message for qusb2_phy_set_tune2_param().
 - Replaced devm_reset_control_get() with devm_reset_control_get_by_index()
   since we are requesting only one reset.
 - Updated devm_nvmem_cell_get() with a NULL cell id.
 - Made error labels more idiomatic.
 - Refactored qusb2_setbits() and qusb2_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to
   do that since 'xo' is modeled as parent to this clock.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Moved nvmem_cell_get() to probe function.
 - Simplified phy pll status handling.
 - Using of_device_get_match_data() to get match data.
 - Uniformly using lowercase for hex numbers.
 - Fixed sparse warnings.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - removed reference to clk_enabled/pwr_enabled.
 - moved clock and regulator enable code to phy_power_on/off() callbacks.
 - fixed return on EPROBE_DEFER in qusb2_phy_probe().
 - fixed phy create and phy register ordering.
 - removed references to non-lkml links from commit message.
 - took care of other minor nits.
 - Fixed coccinelle warnings -
   'PTR_ERR applied after initialization to constant'
 - Addressed review comment, regarding qfprom access for tune2 param value.
   This driver is now based on qfprom patch[1] that allows byte access now.

 drivers/phy/Kconfig  |  10 +
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-qcom-qusb2.c | 539 +++
 3 files changed, 550 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e8eb7f225a88..0ed53d018b23 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -430,6 +430,16 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_QCOM_QUSB2
+   tristate "Qualcomm QUSB2 PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
+ controllers on Qualcomm chips. This driver supports the high-speed
+ PHY which is usually paired with either the ChipIdea or Synopsys DWC3
+ USB IPs on MSM SOCs.
+
 config PHY_QCOM_UFS
tristate "Qualcomm UFS PHY driver"
depends on OF && ARCH_QCOM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 65eb2f436a41..dad1682b80e3 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
 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_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
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
new file mode 100644
index ..c69118610164
--- /dev/null
+++ b/drivers/phy/phy-qcom-qusb2.c
@@ -0,0 +1,539 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define QUSB2PHY_PLL_TEST  0x04
+#define CLK_REF_SELBIT(7)
+
+#define QUSB2PHY_PLL_TUNE  0x08
+#define QUSB2PHY_PLL_USER_CTL1 0x0c
+#define QUSB2PHY_PLL_USER_CTL2 0x10
+#define QUSB2PHY_PLL_AUTOPGM_CTL1  0x1c
+#define QUSB2PHY_PLL_PWR_CTRL  0x18
+
+#define QUSB2PHY_PLL_STATUS0x38
+#define PLL_LOCKED  

[PATCH v2 2/2] nvmem: core: Allow getting nvmem cell with a NULL cell id

[Vivek Gautam]

The nvmem cell with a NULL cell name/id should be the one
with no accompanying 'nvmem-cell-names' property, and thus
will be the cell at index 0 in the device tree.
So, we default to index 0 and update the cell index only when
nvmem cell name id exists.

Suggested-by: Stephen Boyd <sb...@codeaurora.org>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
---

Based on torvald's master branch.

This patch supersedes the earlier posted series [1] that added
support to get nvmem cell by index. We don't need that patch-series.

Changes since v1:
 - Fixed the typo s/acoompanying/accompanying.
 - Added 'Reviewed-by' from Stephen.

[1] https://lkml.org/lkml/2016/12/23/80

 drivers/nvmem/core.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 5eb796acc79a..12e271f31cea 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -747,7 +747,9 @@ static struct nvmem_cell *nvmem_cell_get_from_list(const 
char *cell_id)
  * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell id
  *
  * @np: Device tree node that uses the nvmem cell.
- * @name: nvmem cell name from nvmem-cell-names property.
+ * @name: nvmem cell name from nvmem-cell-names property, or NULL
+ *   for the cell at index 0 (the lone cell with no accompanying
+ *   nvmem-cell-names property).
  *
  * Return: Will be an ERR_PTR() on error or a valid pointer
  * to a struct nvmem_cell.  The nvmem_cell will be freed by the
@@ -760,9 +762,12 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node 
*np,
struct nvmem_cell *cell;
struct nvmem_device *nvmem;
const __be32 *addr;
-   int rval, len, index;
+   int rval, len;
+   int index = 0;
 
-   index = of_property_match_string(np, "nvmem-cell-names", name);
+   /* if cell name exists, find index to the name */
+   if (name)
+   index = of_property_match_string(np, "nvmem-cell-names", name);
 
cell_np = of_parse_phandle(np, "nvmem-cells", index);
if (!cell_np)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 1/2] nvmem: core: Correct a bunch of function documentations

[Vivek Gautam]

Correct the documentation for arguments to a number
of functions.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Based on torvald's master branch.

Changes since v1:
 - Removed unnecessary whitespaces.

 drivers/nvmem/core.c | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 398ea7f54826..5eb796acc79a 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -608,7 +608,7 @@ static struct nvmem_device *nvmem_find(const char *name)
 /**
  * of_nvmem_device_get() - Get nvmem device from a given id
  *
- * @dev node: Device tree node that uses the nvmem device
+ * @np: Device tree node that uses the nvmem device.
  * @id: nvmem name from nvmem-names property.
  *
  * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_device
@@ -634,8 +634,8 @@ struct nvmem_device *of_nvmem_device_get(struct device_node 
*np, const char *id)
 /**
  * nvmem_device_get() - Get nvmem device from a given id
  *
- * @dev : Device that uses the nvmem device
- * @id: nvmem name from nvmem-names property.
+ * @dev: Device that uses the nvmem device.
+ * @dev_name: name of the requested nvmem device.
  *
  * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_device
  * on success.
@@ -674,6 +674,7 @@ static void devm_nvmem_device_release(struct device *dev, 
void *res)
 /**
  * devm_nvmem_device_put() - put alredy got nvmem device
  *
+ * @dev: Device that uses the nvmem device.
  * @nvmem: pointer to nvmem device allocated by devm_nvmem_cell_get(),
  * that needs to be released.
  */
@@ -702,8 +703,8 @@ void nvmem_device_put(struct nvmem_device *nvmem)
 /**
  * devm_nvmem_device_get() - Get nvmem cell of device form a given id
  *
- * @dev node: Device tree node that uses the nvmem cell
- * @id: nvmem name in nvmems property.
+ * @dev: Device that requests the nvmem device.
+ * @id: name id for the requested nvmem device.
  *
  * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_cell
  * on success.  The nvmem_cell will be freed by the automatically once the
@@ -745,8 +746,8 @@ static struct nvmem_cell *nvmem_cell_get_from_list(const 
char *cell_id)
 /**
  * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell id
  *
- * @dev node: Device tree node that uses the nvmem cell
- * @id: nvmem cell name from nvmem-cell-names property.
+ * @np: Device tree node that uses the nvmem cell.
+ * @name: nvmem cell name from nvmem-cell-names property.
  *
  * Return: Will be an ERR_PTR() on error or a valid pointer
  * to a struct nvmem_cell.  The nvmem_cell will be freed by the
@@ -830,8 +831,8 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
 /**
  * nvmem_cell_get() - Get nvmem cell of device form a given cell name
  *
- * @dev node: Device tree node that uses the nvmem cell
- * @id: nvmem cell name to get.
+ * @dev: Device that requests the nvmem cell.
+ * @cell_id: nvmem cell name to get.
  *
  * Return: Will be an ERR_PTR() on error or a valid pointer
  * to a struct nvmem_cell.  The nvmem_cell will be freed by the
@@ -859,8 +860,8 @@ static void devm_nvmem_cell_release(struct device *dev, 
void *res)
 /**
  * devm_nvmem_cell_get() - Get nvmem cell of device form a given id
  *
- * @dev node: Device tree node that uses the nvmem cell
- * @id: nvmem id in nvmem-names property.
+ * @dev: Device that requests the nvmem cell.
+ * @id: nvmem cell name id to get.
  *
  * Return: Will be an ERR_PTR() on error or a valid pointer
  * to a struct nvmem_cell.  The nvmem_cell will be freed by the
@@ -900,7 +901,8 @@ static int devm_nvmem_cell_match(struct device *dev, void 
*res, void *data)
  * devm_nvmem_cell_put() - Release previously allocated nvmem cell
  * from devm_nvmem_cell_get.
  *
- * @cell: Previously allocated nvmem cell by devm_nvmem_cell_get()
+ * @dev: Device that requests the nvmem cell.
+ * @cell: Previously allocated nvmem cell by devm_nvmem_cell_get().
  */
 void devm_nvmem_cell_put(struct device *dev, struct nvmem_cell *cell)
 {
@@ -916,7 +918,7 @@ void devm_nvmem_cell_put(struct device *dev, struct 
nvmem_cell *cell)
 /**
  * nvmem_cell_put() - Release previously allocated nvmem cell.
  *
- * @cell: Previously allocated nvmem cell by nvmem_cell_get()
+ * @cell: Previously allocated nvmem cell by nvmem_cell_get().
  */
 void nvmem_cell_put(struct nvmem_cell *cell)
 {
@@ -1126,7 +1128,7 @@ ssize_t nvmem_device_cell_read(struct nvmem_device *nvmem,
  * nvmem_device_cell_write() - Write cell to a given nvmem device
  *
  * @nvmem: nvmem device to be written to.
- * @info: nvmem cell info to be written
+ * @info: nvmem cell info to be written.
  * @buf: buffer to be written to cell.
  *
  * Return: length of bytes written or negative error code on failure.
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 2/2] nvmem: core: Allow getting nvmem cell with a NULL cell id

[Vivek Gautam]

The nvmem cell with a NULL cell name/id should be the one
with no accompanying 'nvmem-cell-names' property, and thus
will be the cell at index 0 in the device tree.
So, we default to index 0 and update the cell index only when
nvmem cell name id exists.

Suggested-by: Stephen Boyd 
Signed-off-by: Vivek Gautam 
Reviewed-by: Stephen Boyd 
---

Based on torvald's master branch.

This patch supersedes the earlier posted series [1] that added
support to get nvmem cell by index. We don't need that patch-series.

Changes since v1:
 - Fixed the typo s/acoompanying/accompanying.
 - Added 'Reviewed-by' from Stephen.

[1] https://lkml.org/lkml/2016/12/23/80

 drivers/nvmem/core.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 5eb796acc79a..12e271f31cea 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -747,7 +747,9 @@ static struct nvmem_cell *nvmem_cell_get_from_list(const 
char *cell_id)
  * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell id
  *
  * @np: Device tree node that uses the nvmem cell.
- * @name: nvmem cell name from nvmem-cell-names property.
+ * @name: nvmem cell name from nvmem-cell-names property, or NULL
+ *   for the cell at index 0 (the lone cell with no accompanying
+ *   nvmem-cell-names property).
  *
  * Return: Will be an ERR_PTR() on error or a valid pointer
  * to a struct nvmem_cell.  The nvmem_cell will be freed by the
@@ -760,9 +762,12 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node 
*np,
struct nvmem_cell *cell;
struct nvmem_device *nvmem;
const __be32 *addr;
-   int rval, len, index;
+   int rval, len;
+   int index = 0;
 
-   index = of_property_match_string(np, "nvmem-cell-names", name);
+   /* if cell name exists, find index to the name */
+   if (name)
+   index = of_property_match_string(np, "nvmem-cell-names", name);
 
cell_np = of_parse_phandle(np, "nvmem-cells", index);
if (!cell_np)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 1/2] nvmem: core: Correct a bunch of function documentations

[Vivek Gautam]

Correct the documentation for arguments to a number
of functions.

Signed-off-by: Vivek Gautam 
---

Based on torvald's master branch.

Changes since v1:
 - Removed unnecessary whitespaces.

 drivers/nvmem/core.c | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 398ea7f54826..5eb796acc79a 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -608,7 +608,7 @@ static struct nvmem_device *nvmem_find(const char *name)
 /**
  * of_nvmem_device_get() - Get nvmem device from a given id
  *
- * @dev node: Device tree node that uses the nvmem device
+ * @np: Device tree node that uses the nvmem device.
  * @id: nvmem name from nvmem-names property.
  *
  * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_device
@@ -634,8 +634,8 @@ struct nvmem_device *of_nvmem_device_get(struct device_node 
*np, const char *id)
 /**
  * nvmem_device_get() - Get nvmem device from a given id
  *
- * @dev : Device that uses the nvmem device
- * @id: nvmem name from nvmem-names property.
+ * @dev: Device that uses the nvmem device.
+ * @dev_name: name of the requested nvmem device.
  *
  * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_device
  * on success.
@@ -674,6 +674,7 @@ static void devm_nvmem_device_release(struct device *dev, 
void *res)
 /**
  * devm_nvmem_device_put() - put alredy got nvmem device
  *
+ * @dev: Device that uses the nvmem device.
  * @nvmem: pointer to nvmem device allocated by devm_nvmem_cell_get(),
  * that needs to be released.
  */
@@ -702,8 +703,8 @@ void nvmem_device_put(struct nvmem_device *nvmem)
 /**
  * devm_nvmem_device_get() - Get nvmem cell of device form a given id
  *
- * @dev node: Device tree node that uses the nvmem cell
- * @id: nvmem name in nvmems property.
+ * @dev: Device that requests the nvmem device.
+ * @id: name id for the requested nvmem device.
  *
  * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_cell
  * on success.  The nvmem_cell will be freed by the automatically once the
@@ -745,8 +746,8 @@ static struct nvmem_cell *nvmem_cell_get_from_list(const 
char *cell_id)
 /**
  * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell id
  *
- * @dev node: Device tree node that uses the nvmem cell
- * @id: nvmem cell name from nvmem-cell-names property.
+ * @np: Device tree node that uses the nvmem cell.
+ * @name: nvmem cell name from nvmem-cell-names property.
  *
  * Return: Will be an ERR_PTR() on error or a valid pointer
  * to a struct nvmem_cell.  The nvmem_cell will be freed by the
@@ -830,8 +831,8 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
 /**
  * nvmem_cell_get() - Get nvmem cell of device form a given cell name
  *
- * @dev node: Device tree node that uses the nvmem cell
- * @id: nvmem cell name to get.
+ * @dev: Device that requests the nvmem cell.
+ * @cell_id: nvmem cell name to get.
  *
  * Return: Will be an ERR_PTR() on error or a valid pointer
  * to a struct nvmem_cell.  The nvmem_cell will be freed by the
@@ -859,8 +860,8 @@ static void devm_nvmem_cell_release(struct device *dev, 
void *res)
 /**
  * devm_nvmem_cell_get() - Get nvmem cell of device form a given id
  *
- * @dev node: Device tree node that uses the nvmem cell
- * @id: nvmem id in nvmem-names property.
+ * @dev: Device that requests the nvmem cell.
+ * @id: nvmem cell name id to get.
  *
  * Return: Will be an ERR_PTR() on error or a valid pointer
  * to a struct nvmem_cell.  The nvmem_cell will be freed by the
@@ -900,7 +901,8 @@ static int devm_nvmem_cell_match(struct device *dev, void 
*res, void *data)
  * devm_nvmem_cell_put() - Release previously allocated nvmem cell
  * from devm_nvmem_cell_get.
  *
- * @cell: Previously allocated nvmem cell by devm_nvmem_cell_get()
+ * @dev: Device that requests the nvmem cell.
+ * @cell: Previously allocated nvmem cell by devm_nvmem_cell_get().
  */
 void devm_nvmem_cell_put(struct device *dev, struct nvmem_cell *cell)
 {
@@ -916,7 +918,7 @@ void devm_nvmem_cell_put(struct device *dev, struct 
nvmem_cell *cell)
 /**
  * nvmem_cell_put() - Release previously allocated nvmem cell.
  *
- * @cell: Previously allocated nvmem cell by nvmem_cell_get()
+ * @cell: Previously allocated nvmem cell by nvmem_cell_get().
  */
 void nvmem_cell_put(struct nvmem_cell *cell)
 {
@@ -1126,7 +1128,7 @@ ssize_t nvmem_device_cell_read(struct nvmem_device *nvmem,
  * nvmem_device_cell_write() - Write cell to a given nvmem device
  *
  * @nvmem: nvmem device to be written to.
- * @info: nvmem cell info to be written
+ * @info: nvmem cell info to be written.
  * @buf: buffer to be written to cell.
  *
  * Return: length of bytes written or negative error code on failure.
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy

[Vivek Gautam]

Hi Jaehoon,


On 01/04/2017 06:04 PM, Jaehoon Chung wrote:

This patch supports to use Generic Phy framework for Exynos PCIe phy.
When Exynos that supported the pcie want to use the PCIe,
it needs to control the phy resgister.
But it should be more complex to control in their own PCIe device drivers.

Currently, there is an exynos5440 case to support the pcie.
So this driver is based on Exynos5440 PCIe.
In future, will support the Other exynos SoCs likes exynos5433, exynos7.

Signed-off-by: Jaehoon Chung 
---
Changelog on V2:
- Not include the codes relevant to pci-exynos.
- Remove the getting child node.

  drivers/phy/Kconfig   |   9 ++
  drivers/phy/Makefile  |   1 +
  drivers/phy/phy-exynos-pcie.c | 280 ++
  3 files changed, 290 insertions(+)
  create mode 100644 drivers/phy/phy-exynos-pcie.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e8eb7f2..2dddef4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -331,6 +331,15 @@ config PHY_EXYNOS5_USBDRD
  This driver provides PHY interface for USB 3.0 DRD controller
  present on Exynos5 SoC series.
  
+config PHY_EXYNOS_PCIE

+   bool "Exynos PCIe PHY driver"
+   depends on ARCH_EXYNOS && OF
+   depends on PCI_EXYNOS
+   select GENERIC_PHY
+   help
+ Enable PCIe PHY support for Exynos SoC series.
+ This driver provides PHY interface for Exynos PCIe controller.
+
  config PHY_PISTACHIO_USB
tristate "IMG Pistachio USB2.0 PHY driver"
depends on MACH_PISTACHIO
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 65eb2f4..081aeb4 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -37,6 +37,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4X12_USB2) += 
phy-exynos4x12-usb2.o
  phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
  phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= phy-s5pv210-usb2.o
  obj-$(CONFIG_PHY_EXYNOS5_USBDRD)  += phy-exynos5-usbdrd.o
+obj-$(CONFIG_PHY_EXYNOS_PCIE)  += phy-exynos-pcie.o
  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)   += phy-qcom-apq8064-sata.o
  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
  obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)  += phy-rockchip-inno-usb2.o
diff --git a/drivers/phy/phy-exynos-pcie.c b/drivers/phy/phy-exynos-pcie.c
new file mode 100644
index 000..b57f49b
--- /dev/null
+++ b/drivers/phy/phy-exynos-pcie.c
@@ -0,0 +1,280 @@
+/*
+ * Samsung EXYNOS SoC series PCIe PHY driver
+ *
+ * Phy provider for PCIe controller on Exynos SoC series
+ *
+ * Copyright (C) 2016 Samsung Electronics Co., Ltd.
+ * Jaehoon Chung 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PCIe Purple registers */
+#define PCIE_PHY_GLOBAL_RESET  0x000
+#define PCIE_PHY_COMMON_RESET  0x004
+#define PCIE_PHY_CMN_REG   0x008
+#define PCIE_PHY_MAC_RESET 0x00c
+#define PCIE_PHY_PLL_LOCKED0x010
+#define PCIE_PHY_TRSVREG_RESET 0x020
+#define PCIE_PHY_TRSV_RESET0x024
+
+/* PCIe PHY registers */
+#define PCIE_PHY_IMPEDANCE 0x004
+#define PCIE_PHY_PLL_DIV_0 0x008
+#define PCIE_PHY_PLL_BIAS  0x00c
+#define PCIE_PHY_DCC_FEEDBACK  0x014
+#define PCIE_PHY_PLL_DIV_1 0x05c
+#define PCIE_PHY_COMMON_POWER  0x064
+#define PCIE_PHY_COMMON_PD_CMN BIT(3)
+#define PCIE_PHY_TRSV0_EMP_LVL 0x084
+#define PCIE_PHY_TRSV0_DRV_LVL 0x088
+#define PCIE_PHY_TRSV0_RXCDR   0x0ac
+#define PCIE_PHY_TRSV0_POWER   0x0c4
+#define PCIE_PHY_TRSV0_PD_TSV  BIT(7)
+#define PCIE_PHY_TRSV0_LVCC0x0dc
+#define PCIE_PHY_TRSV1_EMP_LVL 0x144
+#define PCIE_PHY_TRSV1_RXCDR   0x16c
+#define PCIE_PHY_TRSV1_POWER   0x184
+#define PCIE_PHY_TRSV1_PD_TSV  BIT(7)
+#define PCIE_PHY_TRSV1_LVCC0x19c
+#define PCIE_PHY_TRSV2_EMP_LVL 0x204
+#define PCIE_PHY_TRSV2_RXCDR   0x22c
+#define PCIE_PHY_TRSV2_POWER   0x244
+#define PCIE_PHY_TRSV2_PD_TSV  BIT(7)
+#define PCIE_PHY_TRSV2_LVCC0x25c
+#define PCIE_PHY_TRSV3_EMP_LVL 0x2c4
+#define PCIE_PHY_TRSV3_RXCDR   0x2ec
+#define PCIE_PHY_TRSV3_POWER   0x304
+#define PCIE_PHY_TRSV3_PD_TSV  BIT(7)
+#define PCIE_PHY_TRSV3_LVCC0x31c
+
+struct exynos_pcie_phy_data {
+   struct phy_ops  *ops;
+};
+
+/* For Exynos pcie phy */
+struct exynos_pcie_phy {
+   const struct exynos_pcie_phy_data *drv_data;
+   void __iomem *phy_base;
+   void __iomem *blk_base; /* For exynos5440 */
+};
+
+static void exynos_pcie_phy_writel(void __iomem *base, u32 

Re: [PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy

[Vivek Gautam]

Hi Jaehoon,


On 01/04/2017 06:04 PM, Jaehoon Chung wrote:

This patch supports to use Generic Phy framework for Exynos PCIe phy.
When Exynos that supported the pcie want to use the PCIe,
it needs to control the phy resgister.
But it should be more complex to control in their own PCIe device drivers.

Currently, there is an exynos5440 case to support the pcie.
So this driver is based on Exynos5440 PCIe.
In future, will support the Other exynos SoCs likes exynos5433, exynos7.

Signed-off-by: Jaehoon Chung 
---
Changelog on V2:
- Not include the codes relevant to pci-exynos.
- Remove the getting child node.

  drivers/phy/Kconfig   |   9 ++
  drivers/phy/Makefile  |   1 +
  drivers/phy/phy-exynos-pcie.c | 280 ++
  3 files changed, 290 insertions(+)
  create mode 100644 drivers/phy/phy-exynos-pcie.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e8eb7f2..2dddef4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -331,6 +331,15 @@ config PHY_EXYNOS5_USBDRD
  This driver provides PHY interface for USB 3.0 DRD controller
  present on Exynos5 SoC series.
  
+config PHY_EXYNOS_PCIE

+   bool "Exynos PCIe PHY driver"
+   depends on ARCH_EXYNOS && OF
+   depends on PCI_EXYNOS
+   select GENERIC_PHY
+   help
+ Enable PCIe PHY support for Exynos SoC series.
+ This driver provides PHY interface for Exynos PCIe controller.
+
  config PHY_PISTACHIO_USB
tristate "IMG Pistachio USB2.0 PHY driver"
depends on MACH_PISTACHIO
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 65eb2f4..081aeb4 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -37,6 +37,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4X12_USB2) += 
phy-exynos4x12-usb2.o
  phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
  phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= phy-s5pv210-usb2.o
  obj-$(CONFIG_PHY_EXYNOS5_USBDRD)  += phy-exynos5-usbdrd.o
+obj-$(CONFIG_PHY_EXYNOS_PCIE)  += phy-exynos-pcie.o
  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)   += phy-qcom-apq8064-sata.o
  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
  obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)  += phy-rockchip-inno-usb2.o
diff --git a/drivers/phy/phy-exynos-pcie.c b/drivers/phy/phy-exynos-pcie.c
new file mode 100644
index 000..b57f49b
--- /dev/null
+++ b/drivers/phy/phy-exynos-pcie.c
@@ -0,0 +1,280 @@
+/*
+ * Samsung EXYNOS SoC series PCIe PHY driver
+ *
+ * Phy provider for PCIe controller on Exynos SoC series
+ *
+ * Copyright (C) 2016 Samsung Electronics Co., Ltd.
+ * Jaehoon Chung 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PCIe Purple registers */
+#define PCIE_PHY_GLOBAL_RESET  0x000
+#define PCIE_PHY_COMMON_RESET  0x004
+#define PCIE_PHY_CMN_REG   0x008
+#define PCIE_PHY_MAC_RESET 0x00c
+#define PCIE_PHY_PLL_LOCKED0x010
+#define PCIE_PHY_TRSVREG_RESET 0x020
+#define PCIE_PHY_TRSV_RESET0x024
+
+/* PCIe PHY registers */
+#define PCIE_PHY_IMPEDANCE 0x004
+#define PCIE_PHY_PLL_DIV_0 0x008
+#define PCIE_PHY_PLL_BIAS  0x00c
+#define PCIE_PHY_DCC_FEEDBACK  0x014
+#define PCIE_PHY_PLL_DIV_1 0x05c
+#define PCIE_PHY_COMMON_POWER  0x064
+#define PCIE_PHY_COMMON_PD_CMN BIT(3)
+#define PCIE_PHY_TRSV0_EMP_LVL 0x084
+#define PCIE_PHY_TRSV0_DRV_LVL 0x088
+#define PCIE_PHY_TRSV0_RXCDR   0x0ac
+#define PCIE_PHY_TRSV0_POWER   0x0c4
+#define PCIE_PHY_TRSV0_PD_TSV  BIT(7)
+#define PCIE_PHY_TRSV0_LVCC0x0dc
+#define PCIE_PHY_TRSV1_EMP_LVL 0x144
+#define PCIE_PHY_TRSV1_RXCDR   0x16c
+#define PCIE_PHY_TRSV1_POWER   0x184
+#define PCIE_PHY_TRSV1_PD_TSV  BIT(7)
+#define PCIE_PHY_TRSV1_LVCC0x19c
+#define PCIE_PHY_TRSV2_EMP_LVL 0x204
+#define PCIE_PHY_TRSV2_RXCDR   0x22c
+#define PCIE_PHY_TRSV2_POWER   0x244
+#define PCIE_PHY_TRSV2_PD_TSV  BIT(7)
+#define PCIE_PHY_TRSV2_LVCC0x25c
+#define PCIE_PHY_TRSV3_EMP_LVL 0x2c4
+#define PCIE_PHY_TRSV3_RXCDR   0x2ec
+#define PCIE_PHY_TRSV3_POWER   0x304
+#define PCIE_PHY_TRSV3_PD_TSV  BIT(7)
+#define PCIE_PHY_TRSV3_LVCC0x31c
+
+struct exynos_pcie_phy_data {
+   struct phy_ops  *ops;
+};
+
+/* For Exynos pcie phy */
+struct exynos_pcie_phy {
+   const struct exynos_pcie_phy_data *drv_data;
+   void __iomem *phy_base;
+   void __iomem *blk_base; /* For exynos5440 */
+};
+
+static void exynos_pcie_phy_writel(void __iomem *base, u32 val, u32 offset)
+{
+   writel(val, base + 

Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[vivek . gautam]

On 2017-01-07 02:47, Bjorn Andersson wrote:

On Fri 06 Jan 01:47 PST 2017, Vivek Gautam wrote:


> > +static int qcom_qmp_phy_com_init(struct qcom_qmp_phy *qphy)
> > +{
> > + const struct qmp_phy_cfg *cfg = qphy->cfg;
> > + void __iomem *serdes = qphy->serdes;
> > + int ret;
> > +
> > + mutex_lock(>phy_mutex);
> > + if (qphy->init_count++) {
> > + mutex_unlock(>phy_mutex);
> > + return 0;
> > + }
> As far as I can see phy_init() and phy_exit() already keep reference
> count on the initialization and you only call this function from
> phy_ops->init, so you should be able to drop this.
This is an intermediary function that does the common block 
initialization.

PHYs like PCIe have a separate common block (apart from SerDes)
for all phy channels. We shouldn't program this common block
multiple times for each channel. That's why this init_count.



You're right!

Unfortunately it took me several minutes to wrap my head around the phy
vs multi-lane and I have a really hard time keeping "qcom_qmp_phy" and
"qmp_phy_desc" apart throughout the driver.

If I understand correctly the qcom_qmp_phy is the context representing 
a

"QMP block", while this is a PHY block it's not actually the phy in
Linux eyes. The qcom_phy_desc represents a "QMP lane", which in Linux
eyes is the phys, but as we think of QMP as the PHY this confused me.


That's correct. The qcom_qmp_phy structure represents the QMP phy block
as a whole and not the individual phy lane instances. These phy lanes
are represented by qcom_phy_desc, and are the actual PHYs in Linux eyes.



How about naming them "struct qmp" and "struct qmp_lane" (or possibly
qmp_phy) instead? That way we remove the confusion of QMP PHY vs Linux
PHY and we make the lane part explicit.


Sure, this sounds good to me - "struct qmp" and "struct qmp_phy" (will
call the respective variables as qblk for qmp block (struct qmp) and
qphy for struct qmp_phy).
Thanks for pointing out. Will change them.

Regards
Vivek



Regards,
Bjorn

--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[vivek . gautam]

On 2017-01-07 02:47, Bjorn Andersson wrote:

On Fri 06 Jan 01:47 PST 2017, Vivek Gautam wrote:


> > +static int qcom_qmp_phy_com_init(struct qcom_qmp_phy *qphy)
> > +{
> > + const struct qmp_phy_cfg *cfg = qphy->cfg;
> > + void __iomem *serdes = qphy->serdes;
> > + int ret;
> > +
> > + mutex_lock(>phy_mutex);
> > + if (qphy->init_count++) {
> > + mutex_unlock(>phy_mutex);
> > + return 0;
> > + }
> As far as I can see phy_init() and phy_exit() already keep reference
> count on the initialization and you only call this function from
> phy_ops->init, so you should be able to drop this.
This is an intermediary function that does the common block 
initialization.

PHYs like PCIe have a separate common block (apart from SerDes)
for all phy channels. We shouldn't program this common block
multiple times for each channel. That's why this init_count.



You're right!

Unfortunately it took me several minutes to wrap my head around the phy
vs multi-lane and I have a really hard time keeping "qcom_qmp_phy" and
"qmp_phy_desc" apart throughout the driver.

If I understand correctly the qcom_qmp_phy is the context representing 
a

"QMP block", while this is a PHY block it's not actually the phy in
Linux eyes. The qcom_phy_desc represents a "QMP lane", which in Linux
eyes is the phys, but as we think of QMP as the PHY this confused me.


That's correct. The qcom_qmp_phy structure represents the QMP phy block
as a whole and not the individual phy lane instances. These phy lanes
are represented by qcom_phy_desc, and are the actual PHYs in Linux eyes.



How about naming them "struct qmp" and "struct qmp_lane" (or possibly
qmp_phy) instead? That way we remove the confusion of QMP PHY vs Linux
PHY and we make the lane part explicit.


Sure, this sounds good to me - "struct qmp" and "struct qmp_phy" (will
call the respective variables as qblk for qmp block (struct qmp) and
qphy for struct qmp_phy).
Thanks for pointing out. Will change them.

Regards
Vivek



Regards,
Bjorn

--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Hi,


On 01/06/2017 12:48 PM, Bjorn Andersson wrote:

On Tue 20 Dec 09:03 PST 2016, Vivek Gautam wrote:


diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c

[..]

+static int qcom_qmp_phy_poweron(struct phy *phy)

[..]

+
+err3:

Rather than naming your labels errX, it's idiomatic to give them
descriptive names, e.g. "disable_ref_clk" here.

Sure will change these labels and any such occurrence further in the code.




+   clk_disable_unprepare(qphy->ref_clk);
+err2:
+   regulator_disable(qphy->vddp_ref_clk);
+err1:
+   regulator_disable(qphy->vdda_pll);
+err:
+   regulator_disable(qphy->vdda_phy);
+   return ret;
+}

[..]

+static int qcom_qmp_phy_com_init(struct qcom_qmp_phy *qphy)
+{
+   const struct qmp_phy_cfg *cfg = qphy->cfg;
+   void __iomem *serdes = qphy->serdes;
+   int ret;
+
+   mutex_lock(>phy_mutex);
+   if (qphy->init_count++) {
+   mutex_unlock(>phy_mutex);
+   return 0;
+   }

As far as I can see phy_init() and phy_exit() already keep reference
count on the initialization and you only call this function from
phy_ops->init, so you should be able to drop this.

This is an intermediary function that does the common block initialization.
PHYs like PCIe have a separate common block (apart from SerDes)
for all phy channels. We shouldn't program this common block
multiple times for each channel. That's why this init_count.



[..]

+
+/* PHY Initialization */
+static int qcom_qmp_phy_init(struct phy *phy)
+{

[..]

+   /* phy power down delay; given in PCIE phy programming guide only */
+   if (qphy->cfg->type == PHY_TYPE_PCIE)

Rather than basing this off "is this pcie" it's preferred if you have a
bool power_down_delay; (or optionally carrying the timeout value) to
control this.

Sure, will modify this.




+   usleep_range(POWER_DOWN_DELAY_US_MIN, POWER_DOWN_DELAY_US_MAX);
+
+   /* start SerDes and Phy-Coding-Sublayer */
+   qphy_setbits(pcs + QPHY_START_CTRL, cfg->start_ctrl);
+
+   /* Pull PHY out of reset state */
+   qphy_clrbits(pcs + QPHY_SW_RESET, SW_RESET);
+
+   status = pcs + cfg->regs[QPHY_PCS_READY_STATUS];
+   mask = cfg->mask_pcs_ready;
+
+   ret = !mask ? 0 : readl_poll_timeout(status, val, !(val & mask), 1,
+   PHY_INIT_COMPLETE_TIMEOUT);

I presume it's not okay to read the status register even once for pcie?
If it is you can skip the conditional as !(val & 0) will break the poll
after the first read.

Yea, it is okay to read the status register for pcie.

Will leave just readl_poll_timeout() that exits on !(val & mask).
We anyways don't set mask_pcs_ready for pcie.


[..]

+static int qcom_qmp_phy_exit(struct phy *phy)
+{

[..]

+}
+
+

Extra blank line

Will remove it.



+static int qcom_qmp_phy_regulator_init(struct device *dev)

[..]

+static
+struct qmp_phy_desc *qcom_qmp_phy_create(struct platform_device *pdev, int 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) {

Is this check adding any value?

The USB3 and PCIe phys are PIPE based phys, and hence the pipe
clock is mandatory for them. Other phys don't care about pipe clock.




+   ret = PTR_ERR(phy_desc->pipe_clk);
+   if (ret != -EPROBE_DEFER)
+   dev_err(dev,
+   "failed to get lane%d pipe_clk, %d\n",
+   id, ret);
+   return ERR_PTR(ret);
+   }
+   phy_desc->pipe_clk = NULL;

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


Regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Hi,


On 01/06/2017 12:48 PM, Bjorn Andersson wrote:

On Tue 20 Dec 09:03 PST 2016, Vivek Gautam wrote:


diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c

[..]

+static int qcom_qmp_phy_poweron(struct phy *phy)

[..]

+
+err3:

Rather than naming your labels errX, it's idiomatic to give them
descriptive names, e.g. "disable_ref_clk" here.

Sure will change these labels and any such occurrence further in the code.




+   clk_disable_unprepare(qphy->ref_clk);
+err2:
+   regulator_disable(qphy->vddp_ref_clk);
+err1:
+   regulator_disable(qphy->vdda_pll);
+err:
+   regulator_disable(qphy->vdda_phy);
+   return ret;
+}

[..]

+static int qcom_qmp_phy_com_init(struct qcom_qmp_phy *qphy)
+{
+   const struct qmp_phy_cfg *cfg = qphy->cfg;
+   void __iomem *serdes = qphy->serdes;
+   int ret;
+
+   mutex_lock(>phy_mutex);
+   if (qphy->init_count++) {
+   mutex_unlock(>phy_mutex);
+   return 0;
+   }

As far as I can see phy_init() and phy_exit() already keep reference
count on the initialization and you only call this function from
phy_ops->init, so you should be able to drop this.

This is an intermediary function that does the common block initialization.
PHYs like PCIe have a separate common block (apart from SerDes)
for all phy channels. We shouldn't program this common block
multiple times for each channel. That's why this init_count.



[..]

+
+/* PHY Initialization */
+static int qcom_qmp_phy_init(struct phy *phy)
+{

[..]

+   /* phy power down delay; given in PCIE phy programming guide only */
+   if (qphy->cfg->type == PHY_TYPE_PCIE)

Rather than basing this off "is this pcie" it's preferred if you have a
bool power_down_delay; (or optionally carrying the timeout value) to
control this.

Sure, will modify this.




+   usleep_range(POWER_DOWN_DELAY_US_MIN, POWER_DOWN_DELAY_US_MAX);
+
+   /* start SerDes and Phy-Coding-Sublayer */
+   qphy_setbits(pcs + QPHY_START_CTRL, cfg->start_ctrl);
+
+   /* Pull PHY out of reset state */
+   qphy_clrbits(pcs + QPHY_SW_RESET, SW_RESET);
+
+   status = pcs + cfg->regs[QPHY_PCS_READY_STATUS];
+   mask = cfg->mask_pcs_ready;
+
+   ret = !mask ? 0 : readl_poll_timeout(status, val, !(val & mask), 1,
+   PHY_INIT_COMPLETE_TIMEOUT);

I presume it's not okay to read the status register even once for pcie?
If it is you can skip the conditional as !(val & 0) will break the poll
after the first read.

Yea, it is okay to read the status register for pcie.

Will leave just readl_poll_timeout() that exits on !(val & mask).
We anyways don't set mask_pcs_ready for pcie.


[..]

+static int qcom_qmp_phy_exit(struct phy *phy)
+{

[..]

+}
+
+

Extra blank line

Will remove it.



+static int qcom_qmp_phy_regulator_init(struct device *dev)

[..]

+static
+struct qmp_phy_desc *qcom_qmp_phy_create(struct platform_device *pdev, int 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) {

Is this check adding any value?

The USB3 and PCIe phys are PIPE based phys, and hence the pipe
clock is mandatory for them. Other phys don't care about pipe clock.




+   ret = PTR_ERR(phy_desc->pipe_clk);
+   if (ret != -EPROBE_DEFER)
+   dev_err(dev,
+   "failed to get lane%d pipe_clk, %d\n",
+   id, ret);
+   return ERR_PTR(ret);
+   }
+   phy_desc->pipe_clk = NULL;

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


Regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: qcom: Fix a possible NULL pointer dereferencing

[Vivek Gautam]

Hi,

On 01/06/2017 04:09 AM, Stephen Boyd wrote:

On 01/05, Vivek Gautam wrote:

On 01/05/2017 07:50 PM, Andy Gross wrote:

On Thu, Jan 05, 2017 at 02:25:25PM +0530, Vivek Gautam wrote:

Assign num_parents as 0 while registering fixed rate clocks
in _qcom_cc_register_board_clk(), to make sure the clk framework
doesn't dereference parent.

Fixes: ee15faffef11 ("clk: qcom: common: Add API to register board clocks backwards 
compatibly")

Cc: Georgi Djakov<georgi.dja...@linaro.org>
Signed-off-by: Vivek Gautam<vivek.gau...@codeaurora.org>
---

Based on 'clk-next'. Build tested.

  drivers/clk/qcom/common.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index cfab7b400381..df004ead1bef 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -157,6 +157,7 @@ static int _qcom_cc_register_board_clk(struct device *dev, 
const char *path,
init_data.name = path;
init_data.ops = _fixed_rate_ops;
+   init_data.num_parents = 0;

It seems like there was a initializer in the declaration but it was { } instead
of { 0 }.

Was the original intent to make this structure initialized to 0?  If so, perhaps
it should be fixed above in the initializer.

yes, i think we intend to initialize the clock init data to 0, and thus
we should do that during declaration.
Will modify and re-spin the patch.


What's the error exactly? Do you have some call stack/crash that
could be put in the commit text?


I got a crash dump from clk_register, when i was working on qmp phy
driver patches. This came when clk_init_data was not initilized.
So i had to explicitly assign num_parents to 0.


It was my understanding that GCC allows braces without anything
inside to initialize structures to 0, so I'm confused what's
wrong here.


You are right. My understanding, that we need to initialize a structure
with {0}, was incomplete.
We don't need this patch.


If this is actually a problem then we have other
places to fix this.

  $ git grep "clk_init_data.*{ *}"
  drivers/clk/bcm/clk-bcm53573-ilp.c: struct clk_init_data init = { };
  drivers/clk/clk-gpio.c: struct clk_init_data init = {};
  drivers/clk/clk-qoriq.c:struct clk_init_data init = {};
  drivers/clk/clk-rk808.c:struct clk_init_data init = {};
  drivers/clk/mediatek/clk-apmixed.c: struct clk_init_data init = {};
  drivers/clk/mediatek/clk-gate.c:struct clk_init_data init = {};
  drivers/clk/mediatek/clk-pll.c: struct clk_init_data init = {};
  drivers/clk/qcom/common.c:  struct clk_init_data init_data = { };
  drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c:struct clk_init_data 
bytediv_init = { };



Regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: qcom: Fix a possible NULL pointer dereferencing

[Vivek Gautam]

Hi,

On 01/06/2017 04:09 AM, Stephen Boyd wrote:

On 01/05, Vivek Gautam wrote:

On 01/05/2017 07:50 PM, Andy Gross wrote:

On Thu, Jan 05, 2017 at 02:25:25PM +0530, Vivek Gautam wrote:

Assign num_parents as 0 while registering fixed rate clocks
in _qcom_cc_register_board_clk(), to make sure the clk framework
doesn't dereference parent.

Fixes: ee15faffef11 ("clk: qcom: common: Add API to register board clocks backwards 
compatibly")

Cc: Georgi Djakov
Signed-off-by: Vivek Gautam
---

Based on 'clk-next'. Build tested.

  drivers/clk/qcom/common.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index cfab7b400381..df004ead1bef 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -157,6 +157,7 @@ static int _qcom_cc_register_board_clk(struct device *dev, 
const char *path,
init_data.name = path;
init_data.ops = _fixed_rate_ops;
+   init_data.num_parents = 0;

It seems like there was a initializer in the declaration but it was { } instead
of { 0 }.

Was the original intent to make this structure initialized to 0?  If so, perhaps
it should be fixed above in the initializer.

yes, i think we intend to initialize the clock init data to 0, and thus
we should do that during declaration.
Will modify and re-spin the patch.


What's the error exactly? Do you have some call stack/crash that
could be put in the commit text?


I got a crash dump from clk_register, when i was working on qmp phy
driver patches. This came when clk_init_data was not initilized.
So i had to explicitly assign num_parents to 0.


It was my understanding that GCC allows braces without anything
inside to initialize structures to 0, so I'm confused what's
wrong here.


You are right. My understanding, that we need to initialize a structure
with {0}, was incomplete.
We don't need this patch.


If this is actually a problem then we have other
places to fix this.

  $ git grep "clk_init_data.*{ *}"
  drivers/clk/bcm/clk-bcm53573-ilp.c: struct clk_init_data init = { };
  drivers/clk/clk-gpio.c: struct clk_init_data init = {};
  drivers/clk/clk-qoriq.c:struct clk_init_data init = {};
  drivers/clk/clk-rk808.c:struct clk_init_data init = {};
  drivers/clk/mediatek/clk-apmixed.c: struct clk_init_data init = {};
  drivers/clk/mediatek/clk-gate.c:struct clk_init_data init = {};
  drivers/clk/mediatek/clk-pll.c: struct clk_init_data init = {};
  drivers/clk/qcom/common.c:  struct clk_init_data init_data = { };
  drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c:struct clk_init_data 
bytediv_init = { };



Regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: qcom: Fix a possible NULL pointer dereferencing

[Vivek Gautam]

On 01/05/2017 07:50 PM, Andy Gross wrote:

On Thu, Jan 05, 2017 at 02:25:25PM +0530, Vivek Gautam wrote:

Assign num_parents as 0 while registering fixed rate clocks
in _qcom_cc_register_board_clk(), to make sure the clk framework
doesn't dereference parent.

Fixes: ee15faffef11 ("clk: qcom: common: Add API to register board clocks backwards 
compatibly")

Cc: Georgi Djakov<georgi.dja...@linaro.org>
Signed-off-by: Vivek Gautam<vivek.gau...@codeaurora.org>
---

Based on 'clk-next'. Build tested.

  drivers/clk/qcom/common.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index cfab7b400381..df004ead1bef 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -157,6 +157,7 @@ static int _qcom_cc_register_board_clk(struct device *dev, 
const char *path,
  
  		init_data.name = path;

init_data.ops = _fixed_rate_ops;
+   init_data.num_parents = 0;

It seems like there was a initializer in the declaration but it was { } instead
of { 0 }.

Was the original intent to make this structure initialized to 0?  If so, perhaps
it should be fixed above in the initializer.


yes, i think we intend to initialize the clock init data to 0, and thus
we should do that during declaration.
Will modify and re-spin the patch.


Regards
Vivek

  
  		ret = devm_clk_hw_register(dev, >hw);

if (ret)

Regards,

Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message tomajord...@vger.kernel.org
More majordomo info athttp://vger.kernel.org/majordomo-info.html


--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: qcom: Fix a possible NULL pointer dereferencing

[Vivek Gautam]

On 01/05/2017 07:50 PM, Andy Gross wrote:

On Thu, Jan 05, 2017 at 02:25:25PM +0530, Vivek Gautam wrote:

Assign num_parents as 0 while registering fixed rate clocks
in _qcom_cc_register_board_clk(), to make sure the clk framework
doesn't dereference parent.

Fixes: ee15faffef11 ("clk: qcom: common: Add API to register board clocks backwards 
compatibly")

Cc: Georgi Djakov
Signed-off-by: Vivek Gautam
---

Based on 'clk-next'. Build tested.

  drivers/clk/qcom/common.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index cfab7b400381..df004ead1bef 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -157,6 +157,7 @@ static int _qcom_cc_register_board_clk(struct device *dev, 
const char *path,
  
  		init_data.name = path;

init_data.ops = _fixed_rate_ops;
+   init_data.num_parents = 0;

It seems like there was a initializer in the declaration but it was { } instead
of { 0 }.

Was the original intent to make this structure initialized to 0?  If so, perhaps
it should be fixed above in the initializer.


yes, i think we intend to initialize the clock init data to 0, and thus
we should do that during declaration.
Will modify and re-spin the patch.


Regards
Vivek

  
  		ret = devm_clk_hw_register(dev, >hw);

if (ret)

Regards,

Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message tomajord...@vger.kernel.org
More majordomo info athttp://vger.kernel.org/majordomo-info.html


--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] nvmem: core: Allow ignoring length when reading a cell

[Vivek Gautam]

On 01/05/2017 03:10 PM, Srinivas Kandagatla wrote:



On 05/01/17 05:34, Vivek Gautam wrote:

Hi Srinivas,

On Tue, Dec 20, 2016 at 3:17 AM, Stephen Boyd <sb...@codeaurora.org> 
wrote:

On 12/19, Vivek Gautam wrote:

nvmem_cell_read() API fills in the argument 'len' with
the number of bytes read from the cell. Many users don't
care about this length value. So allow users to pass a
NULL pointer to this len field.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---


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


Can you please pick this patch as well, adding Stephen's 
'Reviewed-by' tag.


This is already in my queue for 4.11 release, as this is an 
enhancement. I will send them to Greg once we hit rc4 or rc5.


Okay. Thanks for picking.


Regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] nvmem: core: Allow ignoring length when reading a cell

[Vivek Gautam]

On 01/05/2017 03:10 PM, Srinivas Kandagatla wrote:



On 05/01/17 05:34, Vivek Gautam wrote:

Hi Srinivas,

On Tue, Dec 20, 2016 at 3:17 AM, Stephen Boyd  
wrote:

On 12/19, Vivek Gautam wrote:

nvmem_cell_read() API fills in the argument 'len' with
the number of bytes read from the cell. Many users don't
care about this length value. So allow users to pass a
NULL pointer to this len field.

Signed-off-by: Vivek Gautam 
---


Reviewed-by: Stephen Boyd 


Can you please pick this patch as well, adding Stephen's 
'Reviewed-by' tag.


This is already in my queue for 4.11 release, as this is an 
enhancement. I will send them to Greg once we hit rc4 or rc5.


Okay. Thanks for picking.


Regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Hi,

On Wed, Jan 4, 2017 at 12:54 AM, Bjorn Andersson
<bjorn.anders...@linaro.org> wrote:
> On Wed 28 Dec 23:39 PST 2016, Vivek Gautam wrote:
>
>> >> + *
>> >> + */
>> >> +static int phy_pipe_clk_register(struct qcom_qmp_phy *qphy, int id)
>> >> +{
>> >> + char clk_name[MAX_PROP_NAME];
>> >
>> > I'm not sure MAX_PROP_NAME is the same as some max clk name but
>> > ok. We should be able to calculate that the maximum is length of
>> > usb3_phy_pipe_clk_src for now though?
>>
>> Yea, i thought of using the same macro, considering that it provides
>> 32 characters :-)
>> Will rather use the length of usb3_phy_pipe_clk_src for now. May be
>> #define MAX_CLK_NAME   24
>>
>
> Using a macro indicates that the size have some global meaning, but as
> far as I can see it doesn't. Just write 24 and you will have enough
> space for 100k pcie pipe clocks. And then use sizeof(clk_name) below.

Sure, will do as suggested.

>
>> >
>> >> + struct clk *clk;
>> >> +
>> >> + memset(_name, 0, sizeof(clk_name));
>
> There's no point in clearing clk_name, as it will be overwritten
> and null-terminated below.

Right. Will remove this.

>
>> >> + switch (qphy->cfg->type) {
>> >> + case PHY_TYPE_USB3:
>> >> + snprintf(clk_name, MAX_PROP_NAME, "usb3_phy_pipe_clk_src");
>> >> + break;
>> >> + case PHY_TYPE_PCIE:
>> >> + snprintf(clk_name, MAX_PROP_NAME, "pcie_%d_pipe_clk_src", 
>> >> id);
>> >> + break;
>> >> + default:
>> >> + return -EINVAL;
>> >> + }
>> >> +
>> >> + /* controllers using QMP phys use 125MHz pipe clock interface */
>> >> + clk = clk_register_fixed_rate(qphy->dev, clk_name, NULL, 0, 
>> >> 12500);
>
> Regards,
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Regards
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Hi,

On Wed, Jan 4, 2017 at 12:54 AM, Bjorn Andersson
 wrote:
> On Wed 28 Dec 23:39 PST 2016, Vivek Gautam wrote:
>
>> >> + *
>> >> + */
>> >> +static int phy_pipe_clk_register(struct qcom_qmp_phy *qphy, int id)
>> >> +{
>> >> + char clk_name[MAX_PROP_NAME];
>> >
>> > I'm not sure MAX_PROP_NAME is the same as some max clk name but
>> > ok. We should be able to calculate that the maximum is length of
>> > usb3_phy_pipe_clk_src for now though?
>>
>> Yea, i thought of using the same macro, considering that it provides
>> 32 characters :-)
>> Will rather use the length of usb3_phy_pipe_clk_src for now. May be
>> #define MAX_CLK_NAME   24
>>
>
> Using a macro indicates that the size have some global meaning, but as
> far as I can see it doesn't. Just write 24 and you will have enough
> space for 100k pcie pipe clocks. And then use sizeof(clk_name) below.

Sure, will do as suggested.

>
>> >
>> >> + struct clk *clk;
>> >> +
>> >> + memset(_name, 0, sizeof(clk_name));
>
> There's no point in clearing clk_name, as it will be overwritten
> and null-terminated below.

Right. Will remove this.

>
>> >> + switch (qphy->cfg->type) {
>> >> + case PHY_TYPE_USB3:
>> >> + snprintf(clk_name, MAX_PROP_NAME, "usb3_phy_pipe_clk_src");
>> >> + break;
>> >> + case PHY_TYPE_PCIE:
>> >> + snprintf(clk_name, MAX_PROP_NAME, "pcie_%d_pipe_clk_src", 
>> >> id);
>> >> + break;
>> >> + default:
>> >> + return -EINVAL;
>> >> + }
>> >> +
>> >> + /* controllers using QMP phys use 125MHz pipe clock interface */
>> >> + clk = clk_register_fixed_rate(qphy->dev, clk_name, NULL, 0, 
>> >> 12500);
>
> Regards,
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Regards
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] clk: qcom: Fix a possible NULL pointer dereferencing

[Vivek Gautam]

Assign num_parents as 0 while registering fixed rate clocks
in _qcom_cc_register_board_clk(), to make sure the clk framework
doesn't dereference parent.

Fixes: ee15faffef11 ("clk: qcom: common: Add API to register board clocks 
backwards compatibly")

Cc: Georgi Djakov <georgi.dja...@linaro.org>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Based on 'clk-next'. Build tested.

 drivers/clk/qcom/common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index cfab7b400381..df004ead1bef 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -157,6 +157,7 @@ static int _qcom_cc_register_board_clk(struct device *dev, 
const char *path,
 
init_data.name = path;
init_data.ops = _fixed_rate_ops;
+   init_data.num_parents = 0;
 
ret = devm_clk_hw_register(dev, >hw);
if (ret)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] clk: qcom: Fix a possible NULL pointer dereferencing

[Vivek Gautam]

Assign num_parents as 0 while registering fixed rate clocks
in _qcom_cc_register_board_clk(), to make sure the clk framework
doesn't dereference parent.

Fixes: ee15faffef11 ("clk: qcom: common: Add API to register board clocks 
backwards compatibly")

Cc: Georgi Djakov 
Signed-off-by: Vivek Gautam 
---

Based on 'clk-next'. Build tested.

 drivers/clk/qcom/common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index cfab7b400381..df004ead1bef 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -157,6 +157,7 @@ static int _qcom_cc_register_board_clk(struct device *dev, 
const char *path,
 
init_data.name = path;
init_data.ops = _fixed_rate_ops;
+   init_data.num_parents = 0;
 
ret = devm_clk_hw_register(dev, >hw);
if (ret)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] nvmem: core: Allow ignoring length when reading a cell

[Vivek Gautam]

Hi Srinivas,

On Tue, Dec 20, 2016 at 3:17 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> On 12/19, Vivek Gautam wrote:
>> nvmem_cell_read() API fills in the argument 'len' with
>> the number of bytes read from the cell. Many users don't
>> care about this length value. So allow users to pass a
>> NULL pointer to this len field.
>>
>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>> ---
>
> Reviewed-by: Stephen Boyd <sb...@codeaurora.org>

Can you please pick this patch as well, adding Stephen's 'Reviewed-by' tag.


Regards
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] nvmem: core: Allow ignoring length when reading a cell

[Vivek Gautam]

Hi Srinivas,

On Tue, Dec 20, 2016 at 3:17 AM, Stephen Boyd  wrote:
> On 12/19, Vivek Gautam wrote:
>> nvmem_cell_read() API fills in the argument 'len' with
>> the number of bytes read from the cell. Many users don't
>> care about this length value. So allow users to pass a
>> NULL pointer to this len field.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>
> Reviewed-by: Stephen Boyd 

Can you please pick this patch as well, adding Stephen's 'Reviewed-by' tag.


Regards
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] nvmem: qfprom: Allow single byte accesses for read/write

[Vivek Gautam]

On Wed, Jan 4, 2017 at 7:37 PM, Srinivas Kandagatla
 wrote:
> Thanks for the Patch,
>
> I will queue this up!!

Thanks Srinivas.
[snip]



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] nvmem: qfprom: Allow single byte accesses for read/write

[Vivek Gautam]

On Wed, Jan 4, 2017 at 7:37 PM, Srinivas Kandagatla
 wrote:
> Thanks for the Patch,
>
> I will queue this up!!

Thanks Srinivas.
[snip]



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Hi Stephen,


On Thu, Dec 29, 2016 at 4:46 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> On 12/20, 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.
>>
>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>> Tested-by: Srinivas Kandagatla <srinivas.kandaga...@linaro.org>
>> ---
>>
>> +
>> +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++)
>> + /* phys[i]->index */
>> + if (i == args->args[0])
>> + return qphy->phys[i]->phy;
>
> What's the loop for? If args->arg[0] < qphy->cfg->nlanes then we
> should be able to directly index the qphy->phys array with that
> number and return it.

Right, will do that.

>
>> +
>> + return ERR_PTR(-ENODEV);
>> +}
>> +
> [...]
>> +
>> +/*
>> + * The _pipe_clksrc generated by PHY goes to the GCC that gate
>> + * controls it. The _pipe_clk coming out of the GCC is requested
>> + * by the PHY driver for its operations.
>> + * We register the _pipe_clksrc here. The gcc driver takes care
>> + * of assigning this _pipe_clksrc as parent to _pipe_clk.
>> + * Below picture shows this relationship.
>> + *
>> + *  +--+
>> + *  |  PHY block   |<<---+
>> + *  |  | |
>> + *  |   +---+  |   +-+   |
>> + *   I/P---^-->|  PLL  |--^--->pipe_clksrc--->| GCC |--->pipe_clk---+
>> + *   clk   |   +---+  |+-+
>> + *  +--+
>
> There are mixed tabs and spaces in this diagram causing
> confusion in my editor. Please make it only spaces so the picture
> comes out correctly.

Sure, will do that.

>
>> + *
>> + */
>> +static int phy_pipe_clk_register(struct qcom_qmp_phy *qphy, int id)
>> +{
>> + char clk_name[MAX_PROP_NAME];
>
> I'm not sure MAX_PROP_NAME is the same as some max clk name but
> ok. We should be able to calculate that the maximum is length of
> usb3_phy_pipe_clk_src for now though?

Yea, i thought of using the same macro, considering that it provides
32 characters :-)
Will rather use the length of usb3_phy_pipe_clk_src for now. May be
#define MAX_CLK_NAME   24

>
>> + struct clk *clk;
>> +
>> + memset(_name, 0, sizeof(clk_name));
>> + switch (qphy->cfg->type) {
>> + case PHY_TYPE_USB3:
>> + snprintf(clk_name, MAX_PROP_NAME, "usb3_phy_pipe_clk_src");
>> + break;
>> + case PHY_TYPE_PCIE:
>> + snprintf(clk_name, MAX_PROP_NAME, "pcie_%d_pipe_clk_src", id);
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + /* controllers using QMP phys use 125MHz pipe clock interface */
>> + clk = clk_register_fixed_rate(qphy->dev, clk_name, NULL, 0, 12500);
>
> I was hoping you would be able to calculate the actual output
> rate by reading hardware. This is ok too though.

Yea, I too was looking to understand the phy registers needed to
calculate and re-calibrate the pipe clock rate, but couldn't find much
from the IP programming guide. So, I had to fall back to registering
a fixed-rate clock, since we are sure that the pipe clock rate is fixed at
125 MHz for the controllers using pipe interface.
Once we find out the required information, we can as well register clk_ops
for this clock.

> Just please use
> clk_hw_register_fixed_rate() instead. And you'll probably need
> some sort of devm() usage here to handle probe failure, so I
> would probably roll my own and allocate a fixed_rate clk
> structure and set the rate/name directly and then call
> devm_clk_hw_register().

Sure, will do that.

>
>> +
>> + return PTR_ERR_OR_ZERO(clk);
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project


Thanks
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Hi Stephen,


On Thu, Dec 29, 2016 at 4:46 AM, Stephen Boyd  wrote:
> On 12/20, 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.
>>
>> Signed-off-by: Vivek Gautam 
>> Tested-by: Srinivas Kandagatla 
>> ---
>>
>> +
>> +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++)
>> + /* phys[i]->index */
>> + if (i == args->args[0])
>> + return qphy->phys[i]->phy;
>
> What's the loop for? If args->arg[0] < qphy->cfg->nlanes then we
> should be able to directly index the qphy->phys array with that
> number and return it.

Right, will do that.

>
>> +
>> + return ERR_PTR(-ENODEV);
>> +}
>> +
> [...]
>> +
>> +/*
>> + * The _pipe_clksrc generated by PHY goes to the GCC that gate
>> + * controls it. The _pipe_clk coming out of the GCC is requested
>> + * by the PHY driver for its operations.
>> + * We register the _pipe_clksrc here. The gcc driver takes care
>> + * of assigning this _pipe_clksrc as parent to _pipe_clk.
>> + * Below picture shows this relationship.
>> + *
>> + *  +--+
>> + *  |  PHY block   |<<---+
>> + *  |  | |
>> + *  |   +---+  |   +-+   |
>> + *   I/P---^-->|  PLL  |--^--->pipe_clksrc--->| GCC |--->pipe_clk---+
>> + *   clk   |   +---+  |+-+
>> + *  +--+
>
> There are mixed tabs and spaces in this diagram causing
> confusion in my editor. Please make it only spaces so the picture
> comes out correctly.

Sure, will do that.

>
>> + *
>> + */
>> +static int phy_pipe_clk_register(struct qcom_qmp_phy *qphy, int id)
>> +{
>> + char clk_name[MAX_PROP_NAME];
>
> I'm not sure MAX_PROP_NAME is the same as some max clk name but
> ok. We should be able to calculate that the maximum is length of
> usb3_phy_pipe_clk_src for now though?

Yea, i thought of using the same macro, considering that it provides
32 characters :-)
Will rather use the length of usb3_phy_pipe_clk_src for now. May be
#define MAX_CLK_NAME   24

>
>> + struct clk *clk;
>> +
>> + memset(_name, 0, sizeof(clk_name));
>> + switch (qphy->cfg->type) {
>> + case PHY_TYPE_USB3:
>> + snprintf(clk_name, MAX_PROP_NAME, "usb3_phy_pipe_clk_src");
>> + break;
>> + case PHY_TYPE_PCIE:
>> + snprintf(clk_name, MAX_PROP_NAME, "pcie_%d_pipe_clk_src", id);
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + /* controllers using QMP phys use 125MHz pipe clock interface */
>> + clk = clk_register_fixed_rate(qphy->dev, clk_name, NULL, 0, 12500);
>
> I was hoping you would be able to calculate the actual output
> rate by reading hardware. This is ok too though.

Yea, I too was looking to understand the phy registers needed to
calculate and re-calibrate the pipe clock rate, but couldn't find much
from the IP programming guide. So, I had to fall back to registering
a fixed-rate clock, since we are sure that the pipe clock rate is fixed at
125 MHz for the controllers using pipe interface.
Once we find out the required information, we can as well register clk_ops
for this clock.

> Just please use
> clk_hw_register_fixed_rate() instead. And you'll probably need
> some sort of devm() usage here to handle probe failure, so I
> would probably roll my own and allocate a fixed_rate clk
> structure and set the rate/name directly and then call
> devm_clk_hw_register().

Sure, will do that.

>
>> +
>> + return PTR_ERR_OR_ZERO(clk);
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project


Thanks
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

Hi Stephen,

On Thu, Dec 29, 2016 at 12:27 PM, Vivek Gautam
<vivek.gau...@codeaurora.org> wrote:
> On Thu, Dec 29, 2016 at 4:31 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
>> On 12/20, Vivek Gautam wrote:
>>> PHY transceiver driver for QUSB2 phy controller that provides
>>> HighSpeed functionality for DWC3 controller present on
>>> Qualcomm chipsets.
>>>
>>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>>
>> One comment below, but otherwise
>>
>> Reviewed-by: Stephen Boyd <sb...@codeaurora.org>

Thanks for the review.


Best Regards
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

Hi Stephen,

On Thu, Dec 29, 2016 at 12:27 PM, Vivek Gautam
 wrote:
> On Thu, Dec 29, 2016 at 4:31 AM, Stephen Boyd  wrote:
>> On 12/20, Vivek Gautam wrote:
>>> PHY transceiver driver for QUSB2 phy controller that provides
>>> HighSpeed functionality for DWC3 controller present on
>>> Qualcomm chipsets.
>>>
>>> Signed-off-by: Vivek Gautam 
>>
>> One comment below, but otherwise
>>
>> Reviewed-by: Stephen Boyd 

Thanks for the review.


Best Regards
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

On Thu, Dec 29, 2016 at 4:31 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> On 12/20, Vivek Gautam wrote:
>> PHY transceiver driver for QUSB2 phy controller that provides
>> HighSpeed functionality for DWC3 controller present on
>> Qualcomm chipsets.
>>
>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>
> One comment below, but otherwise
>
> Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
>
>> +static void qusb2_phy_set_tune2_param(struct qusb2_phy *qphy)
>> +{
>> + struct device *dev = >phy->dev;
>> + u8 *val;
>> +
>> + /*
>> +  * Read efuse register having TUNE2 parameter's high nibble.
>> +  * If efuse register shows value as 0x0, or if we fail to find
>> +  * a valid efuse register settings, then use default value
>> +  * as 0xB for high nibble that we have already set while
>> +  * configuring phy.
>> +  */
>> + val = nvmem_cell_read(qphy->cell, NULL);
>> + if (IS_ERR(val) || !val[0]) {
>> + dev_dbg(dev, "failed to read a valid hs-tx trim value, %ld\n",
>> + PTR_ERR(val));
>
> If val is 0 PTR_ERR(0) will be junk? I guess that's ok for debug
> print.

May be -EINVAL is better for debug print. Even when val[0]
is 0, val will still be a valid pointer, and so PTR_ERR(val) will
essentially be the pointer casted to long.



Thanks
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

On Thu, Dec 29, 2016 at 4:31 AM, Stephen Boyd  wrote:
> On 12/20, Vivek Gautam wrote:
>> PHY transceiver driver for QUSB2 phy controller that provides
>> HighSpeed functionality for DWC3 controller present on
>> Qualcomm chipsets.
>>
>> Signed-off-by: Vivek Gautam 
>
> One comment below, but otherwise
>
> Reviewed-by: Stephen Boyd 
>
>> +static void qusb2_phy_set_tune2_param(struct qusb2_phy *qphy)
>> +{
>> + struct device *dev = >phy->dev;
>> + u8 *val;
>> +
>> + /*
>> +  * Read efuse register having TUNE2 parameter's high nibble.
>> +  * If efuse register shows value as 0x0, or if we fail to find
>> +  * a valid efuse register settings, then use default value
>> +  * as 0xB for high nibble that we have already set while
>> +  * configuring phy.
>> +  */
>> + val = nvmem_cell_read(qphy->cell, NULL);
>> + if (IS_ERR(val) || !val[0]) {
>> + dev_dbg(dev, "failed to read a valid hs-tx trim value, %ld\n",
>> + PTR_ERR(val));
>
> If val is 0 PTR_ERR(0) will be junk? I guess that's ok for debug
> print.

May be -EINVAL is better for debug print. Even when val[0]
is 0, val will still be a valid pointer, and so PTR_ERR(val) will
essentially be the pointer casted to long.



Thanks
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

On Thu, Dec 29, 2016 at 4:34 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> On 12/20, Vivek Gautam wrote:
>> +
>> +Example:
>> + pcie_phy: phy@34000 {
>> + compatible = "qcom,msm8996-qmp-pcie-phy";
>> + reg = <0x034000 0x48f>,
>> + <0x035000 0x5bf>,
>> + <0x036000 0x5bf>,
>> + <0x037000 0x5bf>;
>> + /* tx, rx, pcs */
>> + lane-offsets = <0x0 0x200 0x400>;
>> + #phy-cells = <1>;
>> +
>> + clocks = < GCC_PCIE_PHY_AUX_CLK>,
>> + < GCC_PCIE_PHY_CFG_AHB_CLK>,
>> + < GCC_PCIE_CLKREF_CLK>,
>> + < GCC_PCIE_0_PIPE_CLK>,
>> + < GCC_PCIE_1_PIPE_CLK>,
>> + < GCC_PCIE_2_PIPE_CLK>;
>> + clock-names = "aux", "cfg_ahb", "ref",
>> + "pipe0", "pipe1", "pipe2";
>
> Can we add a #clock-cells = <0> or <1> here given that this is a
> clk provider? We may want to express the clk circular dependency
> between this phy node and GCC via the clocks property at some
> point instead of doing it implicitly via strings in C code.

Sure, will add #clock-cells = <1>.
Although phys like USB and PIPE currently have just the pipe_clk
being controlled by gcc, the UFS phy has tx/rx symbol clocks that
are controlled by gcc but are generated by phy the same way as
pipe_clk.
So, i guess #clock-cells = <1 > makes sense.


Thanks
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

On Thu, Dec 29, 2016 at 4:34 AM, Stephen Boyd  wrote:
> On 12/20, Vivek Gautam wrote:
>> +
>> +Example:
>> + pcie_phy: phy@34000 {
>> + compatible = "qcom,msm8996-qmp-pcie-phy";
>> + reg = <0x034000 0x48f>,
>> + <0x035000 0x5bf>,
>> + <0x036000 0x5bf>,
>> + <0x037000 0x5bf>;
>> + /* tx, rx, pcs */
>> + lane-offsets = <0x0 0x200 0x400>;
>> + #phy-cells = <1>;
>> +
>> + clocks = < GCC_PCIE_PHY_AUX_CLK>,
>> + < GCC_PCIE_PHY_CFG_AHB_CLK>,
>> + < GCC_PCIE_CLKREF_CLK>,
>> + < GCC_PCIE_0_PIPE_CLK>,
>> + < GCC_PCIE_1_PIPE_CLK>,
>> + < GCC_PCIE_2_PIPE_CLK>;
>> + clock-names = "aux", "cfg_ahb", "ref",
>> + "pipe0", "pipe1", "pipe2";
>
> Can we add a #clock-cells = <0> or <1> here given that this is a
> clk provider? We may want to express the clk circular dependency
> between this phy node and GCC via the clocks property at some
> point instead of doing it implicitly via strings in C code.

Sure, will add #clock-cells = <1>.
Although phys like USB and PIPE currently have just the pipe_clk
being controlled by gcc, the UFS phy has tx/rx symbol clocks that
are controlled by gcc but are generated by phy the same way as
pipe_clk.
So, i guess #clock-cells = <1 > makes sense.


Thanks
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC PATCH 1/6] phy: exynos-pcie: Add support for Exynos PCIe phy

[Vivek Gautam]

On Wed, Dec 28, 2016 at 3:05 PM, Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> Hi Vivek,
>
> On 12/28/2016 05:58 PM, Vivek Gautam wrote:
>> Hi Jaehoon,
>>
>> On Wed, Dec 28, 2016 at 8:19 AM, Jaehoon Chung <jh80.ch...@samsung.com> 
>> wrote:
>>> Hi Vivek,
>>>
>>> On 12/27/2016 02:53 PM, Vivek Gautam wrote:
>>>> Hi Jaehoon,
>>>>
>>>>
>>>> On Mon, Dec 26, 2016 at 10:50 AM, Jaehoon Chung <jh80.ch...@samsung.com> 
>>>> wrote:
>>>>> This patch supports to use Generic Phy framework for Exynos PCIe phy.
>>>>> When Exynos that supported the pcie want to use the PCIe,
>>>>> it needs to control the phy resgister.
>>>>> But it should be more complex to control in their own PCIe device drivers.
>>>>>
>>>>> Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com>
>>>>> ---
>>>>>  drivers/phy/Kconfig   |   9 ++
>>>>>  drivers/phy/Makefile  |   1 +
>>>>>  drivers/phy/phy-exynos-pcie.c | 227 
>>>>> ++
>>>>>  3 files changed, 237 insertions(+)
>>>>>  create mode 100644 drivers/phy/phy-exynos-pcie.c
>>>>>
>>>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>>>> index fe00f91..94b0433 100644
>>>>> --- a/drivers/phy/Kconfig
>>>>> +++ b/drivers/phy/Kconfig
>>>>> @@ -341,6 +341,15 @@ config PHY_EXYNOS5_USBDRD
>>>>>   This driver provides PHY interface for USB 3.0 DRD controller
>>>>>   present on Exynos5 SoC series.
>>>>>
>>>>> +config PHY_EXYNOS_PCIE
>>>>> +   bool "Exynos PCIe PHY driver"
>>>>
>>>> Is there a reason for this not being 'tristate' ?
>>>
>>> Will change.
>>
>> I notice that PCI_EXYNOS5433 is bool as well.
>> If the host has to be 'bool' then it makes sense to have phy
>> also bool as well. But if PCI_EXYNOS5433 can be made
>> tristate, then this also changes to tristate.
>
> Right. I understood what you said.
>
>>
>>>
>>>>
>>>>> +   depends on ARCH_EXYNOS && OF
>>>>> +   depends on PCI_EXYNOS5433
>>>>> +   select GENERIC_PHY
>>>>> +   help
>>>>> + Enable PCIe PHY support for Exynos SoC series.
>>>>
>>>> If this driver is for Exynos5433, then same should come in this help
>>>> text as well.
>>>
>>> will support the other exynos series.
>>> I'm working on refactoring exynos5440 with PHY generic Framework.
>>> Then this drive is not for only Exnyos5433. how about?
>>
>> Ok, it's good then. My only concern is 'depends on PCI_EXYNOS5433'
>> makes it look like it is for EXYNOS5433. I am fine if that changes as well.
>
> I will not put PCI_EXYNOS5433, just will use the PCI_EXYNOS.
> Because it will be supported only one file as pci-exynos.c

cool then.

[...]

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC PATCH 1/6] phy: exynos-pcie: Add support for Exynos PCIe phy

[Vivek Gautam]

On Wed, Dec 28, 2016 at 3:05 PM, Jaehoon Chung  wrote:
> Hi Vivek,
>
> On 12/28/2016 05:58 PM, Vivek Gautam wrote:
>> Hi Jaehoon,
>>
>> On Wed, Dec 28, 2016 at 8:19 AM, Jaehoon Chung  
>> wrote:
>>> Hi Vivek,
>>>
>>> On 12/27/2016 02:53 PM, Vivek Gautam wrote:
>>>> Hi Jaehoon,
>>>>
>>>>
>>>> On Mon, Dec 26, 2016 at 10:50 AM, Jaehoon Chung  
>>>> wrote:
>>>>> This patch supports to use Generic Phy framework for Exynos PCIe phy.
>>>>> When Exynos that supported the pcie want to use the PCIe,
>>>>> it needs to control the phy resgister.
>>>>> But it should be more complex to control in their own PCIe device drivers.
>>>>>
>>>>> Signed-off-by: Jaehoon Chung 
>>>>> ---
>>>>>  drivers/phy/Kconfig   |   9 ++
>>>>>  drivers/phy/Makefile  |   1 +
>>>>>  drivers/phy/phy-exynos-pcie.c | 227 
>>>>> ++
>>>>>  3 files changed, 237 insertions(+)
>>>>>  create mode 100644 drivers/phy/phy-exynos-pcie.c
>>>>>
>>>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>>>> index fe00f91..94b0433 100644
>>>>> --- a/drivers/phy/Kconfig
>>>>> +++ b/drivers/phy/Kconfig
>>>>> @@ -341,6 +341,15 @@ config PHY_EXYNOS5_USBDRD
>>>>>   This driver provides PHY interface for USB 3.0 DRD controller
>>>>>   present on Exynos5 SoC series.
>>>>>
>>>>> +config PHY_EXYNOS_PCIE
>>>>> +   bool "Exynos PCIe PHY driver"
>>>>
>>>> Is there a reason for this not being 'tristate' ?
>>>
>>> Will change.
>>
>> I notice that PCI_EXYNOS5433 is bool as well.
>> If the host has to be 'bool' then it makes sense to have phy
>> also bool as well. But if PCI_EXYNOS5433 can be made
>> tristate, then this also changes to tristate.
>
> Right. I understood what you said.
>
>>
>>>
>>>>
>>>>> +   depends on ARCH_EXYNOS && OF
>>>>> +   depends on PCI_EXYNOS5433
>>>>> +   select GENERIC_PHY
>>>>> +   help
>>>>> + Enable PCIe PHY support for Exynos SoC series.
>>>>
>>>> If this driver is for Exynos5433, then same should come in this help
>>>> text as well.
>>>
>>> will support the other exynos series.
>>> I'm working on refactoring exynos5440 with PHY generic Framework.
>>> Then this drive is not for only Exnyos5433. how about?
>>
>> Ok, it's good then. My only concern is 'depends on PCI_EXYNOS5433'
>> makes it look like it is for EXYNOS5433. I am fine if that changes as well.
>
> I will not put PCI_EXYNOS5433, just will use the PCI_EXYNOS.
> Because it will be supported only one file as pci-exynos.c

cool then.

[...]

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC PATCH 1/6] phy: exynos-pcie: Add support for Exynos PCIe phy

[Vivek Gautam]

Hi Jaehoon,

On Wed, Dec 28, 2016 at 8:19 AM, Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> Hi Vivek,
>
> On 12/27/2016 02:53 PM, Vivek Gautam wrote:
>> Hi Jaehoon,
>>
>>
>> On Mon, Dec 26, 2016 at 10:50 AM, Jaehoon Chung <jh80.ch...@samsung.com> 
>> wrote:
>>> This patch supports to use Generic Phy framework for Exynos PCIe phy.
>>> When Exynos that supported the pcie want to use the PCIe,
>>> it needs to control the phy resgister.
>>> But it should be more complex to control in their own PCIe device drivers.
>>>
>>> Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com>
>>> ---
>>>  drivers/phy/Kconfig   |   9 ++
>>>  drivers/phy/Makefile  |   1 +
>>>  drivers/phy/phy-exynos-pcie.c | 227 
>>> ++
>>>  3 files changed, 237 insertions(+)
>>>  create mode 100644 drivers/phy/phy-exynos-pcie.c
>>>
>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>> index fe00f91..94b0433 100644
>>> --- a/drivers/phy/Kconfig
>>> +++ b/drivers/phy/Kconfig
>>> @@ -341,6 +341,15 @@ config PHY_EXYNOS5_USBDRD
>>>   This driver provides PHY interface for USB 3.0 DRD controller
>>>   present on Exynos5 SoC series.
>>>
>>> +config PHY_EXYNOS_PCIE
>>> +   bool "Exynos PCIe PHY driver"
>>
>> Is there a reason for this not being 'tristate' ?
>
> Will change.

I notice that PCI_EXYNOS5433 is bool as well.
If the host has to be 'bool' then it makes sense to have phy
also bool as well. But if PCI_EXYNOS5433 can be made
tristate, then this also changes to tristate.

>
>>
>>> +   depends on ARCH_EXYNOS && OF
>>> +   depends on PCI_EXYNOS5433
>>> +   select GENERIC_PHY
>>> +   help
>>> + Enable PCIe PHY support for Exynos SoC series.
>>
>> If this driver is for Exynos5433, then same should come in this help
>> text as well.
>
> will support the other exynos series.
> I'm working on refactoring exynos5440 with PHY generic Framework.
> Then this drive is not for only Exnyos5433. how about?

Ok, it's good then. My only concern is 'depends on PCI_EXYNOS5433'
makes it look like it is for EXYNOS5433. I am fine if that changes as well.

[...]

>>> +
>>> +#define PCIE_EXYNOS5433_PMU_PHY_OFFSET 0x730
>>> +#define PCIE_PHY_OFFSET(x) ((x) * 0x4)
>>> +
>>> +/* Sysreg Fsys register offset and bit for Exynos5433 */
>>> +#define PCIE_PHY_MAC_RESET 0x208
>>> +#define PCIE_MAC_RESET_MASK0xFF
>>> +#define PCIE_MAC_RESET BIT(4)
>>> +#define PCIE_L1SUB_CM_CON  0x1010
>>> +#define PCIE_REFCLK_GATING_EN  BIT(0)
>>> +#define PCIE_PHY_COMMON_RESET  0x1020
>>> +#define PCIE_PHY_RESET BIT(0)
>>> +#define PCIE_PHY_GLOBAL_RESET  0x1040
>>> +#define PCIE_GLOBAL_RESET  BIT(0)
>>> +#define PCIE_REFCLKBIT(1)
>>> +#define PCIE_REFCLK_MASK   0x16
>>> +#define PCIE_APP_REQ_EXIT_L1_MODE  BIT(5)
>>> +
>>> +enum exynos_pcie_phy_data_type {
>>> +   PCIE_PHY_TYPE_EXYNOS5433,
>>> +};
>>> +
>>> +struct exynos_pcie_phy_data {
>>> +   enum exynos_pcie_phy_data_type  ctrl_type;
>>
>> Why do we need this controller type ?
>> If there are changes in the IP between different version,
>> then you can as well use different compatibles.
>
> Do you mean is the using "of_device_is_compatible()"?

I meant that multiple compatible strings can be added based on the
IP versions. And any IP specific data can be put in the .data field
of  'of_device_id' structure.
If there's more to differentiate between the IP versions at runtime,
you can use of_device_is_compatible().

[...]



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC PATCH 1/6] phy: exynos-pcie: Add support for Exynos PCIe phy

[Vivek Gautam]

Hi Jaehoon,

On Wed, Dec 28, 2016 at 8:19 AM, Jaehoon Chung  wrote:
> Hi Vivek,
>
> On 12/27/2016 02:53 PM, Vivek Gautam wrote:
>> Hi Jaehoon,
>>
>>
>> On Mon, Dec 26, 2016 at 10:50 AM, Jaehoon Chung  
>> wrote:
>>> This patch supports to use Generic Phy framework for Exynos PCIe phy.
>>> When Exynos that supported the pcie want to use the PCIe,
>>> it needs to control the phy resgister.
>>> But it should be more complex to control in their own PCIe device drivers.
>>>
>>> Signed-off-by: Jaehoon Chung 
>>> ---
>>>  drivers/phy/Kconfig   |   9 ++
>>>  drivers/phy/Makefile  |   1 +
>>>  drivers/phy/phy-exynos-pcie.c | 227 
>>> ++
>>>  3 files changed, 237 insertions(+)
>>>  create mode 100644 drivers/phy/phy-exynos-pcie.c
>>>
>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>> index fe00f91..94b0433 100644
>>> --- a/drivers/phy/Kconfig
>>> +++ b/drivers/phy/Kconfig
>>> @@ -341,6 +341,15 @@ config PHY_EXYNOS5_USBDRD
>>>   This driver provides PHY interface for USB 3.0 DRD controller
>>>   present on Exynos5 SoC series.
>>>
>>> +config PHY_EXYNOS_PCIE
>>> +   bool "Exynos PCIe PHY driver"
>>
>> Is there a reason for this not being 'tristate' ?
>
> Will change.

I notice that PCI_EXYNOS5433 is bool as well.
If the host has to be 'bool' then it makes sense to have phy
also bool as well. But if PCI_EXYNOS5433 can be made
tristate, then this also changes to tristate.

>
>>
>>> +   depends on ARCH_EXYNOS && OF
>>> +   depends on PCI_EXYNOS5433
>>> +   select GENERIC_PHY
>>> +   help
>>> + Enable PCIe PHY support for Exynos SoC series.
>>
>> If this driver is for Exynos5433, then same should come in this help
>> text as well.
>
> will support the other exynos series.
> I'm working on refactoring exynos5440 with PHY generic Framework.
> Then this drive is not for only Exnyos5433. how about?

Ok, it's good then. My only concern is 'depends on PCI_EXYNOS5433'
makes it look like it is for EXYNOS5433. I am fine if that changes as well.

[...]

>>> +
>>> +#define PCIE_EXYNOS5433_PMU_PHY_OFFSET 0x730
>>> +#define PCIE_PHY_OFFSET(x) ((x) * 0x4)
>>> +
>>> +/* Sysreg Fsys register offset and bit for Exynos5433 */
>>> +#define PCIE_PHY_MAC_RESET 0x208
>>> +#define PCIE_MAC_RESET_MASK0xFF
>>> +#define PCIE_MAC_RESET BIT(4)
>>> +#define PCIE_L1SUB_CM_CON  0x1010
>>> +#define PCIE_REFCLK_GATING_EN  BIT(0)
>>> +#define PCIE_PHY_COMMON_RESET  0x1020
>>> +#define PCIE_PHY_RESET BIT(0)
>>> +#define PCIE_PHY_GLOBAL_RESET  0x1040
>>> +#define PCIE_GLOBAL_RESET  BIT(0)
>>> +#define PCIE_REFCLKBIT(1)
>>> +#define PCIE_REFCLK_MASK   0x16
>>> +#define PCIE_APP_REQ_EXIT_L1_MODE  BIT(5)
>>> +
>>> +enum exynos_pcie_phy_data_type {
>>> +   PCIE_PHY_TYPE_EXYNOS5433,
>>> +};
>>> +
>>> +struct exynos_pcie_phy_data {
>>> +   enum exynos_pcie_phy_data_type  ctrl_type;
>>
>> Why do we need this controller type ?
>> If there are changes in the IP between different version,
>> then you can as well use different compatibles.
>
> Do you mean is the using "of_device_is_compatible()"?

I meant that multiple compatible strings can be added based on the
IP versions. And any IP specific data can be put in the .data field
of  'of_device_id' structure.
If there's more to differentiate between the IP versions at runtime,
you can use of_device_is_compatible().

[...]



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] thermal: mtk_thermal: Staticise a number of data variables

[Vivek Gautam]

Sparse throws following warnings:
drivers/thermal/mtk_thermal.c:186:11: warning: symbol 'mt8173_bank_data' was 
not declared. Should it be static?
drivers/thermal/mtk_thermal.c:193:11: warning: symbol 'mt8173_msr' was not 
declared. Should it be static?
drivers/thermal/mtk_thermal.c:197:11: warning: symbol 'mt8173_adcpnp' was not 
declared. Should it be static?
drivers/thermal/mtk_thermal.c:201:11: warning: symbol 'mt8173_mux_values' was 
not declared. Should it be static?
drivers/thermal/mtk_thermal.c:204:11: warning: symbol 'mt2701_bank_data' was 
not declared. Should it be static?
drivers/thermal/mtk_thermal.c:208:11: warning: symbol 'mt2701_msr' was not 
declared. Should it be static?
drivers/thermal/mtk_thermal.c:212:11: warning: symbol 'mt2701_adcpnp' was not 
declared. Should it be static?
drivers/thermal/mtk_thermal.c:216:11: warning: symbol 'mt2701_mux_values' was 
not declared. Should it be static?

Make these variables as static to fix these warnings.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Based on Torvald's master branch. Build tested.

 drivers/thermal/mtk_thermal.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 34169c32d495..1aff7fde54b1 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -183,37 +183,37 @@ struct mtk_thermal {
 };
 
 /* MT8173 thermal sensor data */
-const int mt8173_bank_data[MT8173_NUM_ZONES][3] = {
+static const int mt8173_bank_data[MT8173_NUM_ZONES][3] = {
{ MT8173_TS2, MT8173_TS3 },
{ MT8173_TS2, MT8173_TS4 },
{ MT8173_TS1, MT8173_TS2, MT8173_TSABB },
{ MT8173_TS2 },
 };
 
-const int mt8173_msr[MT8173_NUM_SENSORS_PER_ZONE] = {
+static const int mt8173_msr[MT8173_NUM_SENSORS_PER_ZONE] = {
TEMP_MSR0, TEMP_MSR1, TEMP_MSR2, TEMP_MSR2
 };
 
-const int mt8173_adcpnp[MT8173_NUM_SENSORS_PER_ZONE] = {
+static const int mt8173_adcpnp[MT8173_NUM_SENSORS_PER_ZONE] = {
TEMP_ADCPNP0, TEMP_ADCPNP1, TEMP_ADCPNP2, TEMP_ADCPNP3
 };
 
-const int mt8173_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
+static const int mt8173_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
 
 /* MT2701 thermal sensor data */
-const int mt2701_bank_data[MT2701_NUM_SENSORS] = {
+static const int mt2701_bank_data[MT2701_NUM_SENSORS] = {
MT2701_TS1, MT2701_TS2, MT2701_TSABB
 };
 
-const int mt2701_msr[MT2701_NUM_SENSORS_PER_ZONE] = {
+static const int mt2701_msr[MT2701_NUM_SENSORS_PER_ZONE] = {
TEMP_MSR0, TEMP_MSR1, TEMP_MSR2
 };
 
-const int mt2701_adcpnp[MT2701_NUM_SENSORS_PER_ZONE] = {
+static const int mt2701_adcpnp[MT2701_NUM_SENSORS_PER_ZONE] = {
TEMP_ADCPNP0, TEMP_ADCPNP1, TEMP_ADCPNP2
 };
 
-const int mt2701_mux_values[MT2701_NUM_SENSORS] = { 0, 1, 16 };
+static const int mt2701_mux_values[MT2701_NUM_SENSORS] = { 0, 1, 16 };
 
 /**
  * The MT8173 thermal controller has four banks. Each bank can read up to
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] thermal: mtk_thermal: Staticise a number of data variables

[Vivek Gautam]

Sparse throws following warnings:
drivers/thermal/mtk_thermal.c:186:11: warning: symbol 'mt8173_bank_data' was 
not declared. Should it be static?
drivers/thermal/mtk_thermal.c:193:11: warning: symbol 'mt8173_msr' was not 
declared. Should it be static?
drivers/thermal/mtk_thermal.c:197:11: warning: symbol 'mt8173_adcpnp' was not 
declared. Should it be static?
drivers/thermal/mtk_thermal.c:201:11: warning: symbol 'mt8173_mux_values' was 
not declared. Should it be static?
drivers/thermal/mtk_thermal.c:204:11: warning: symbol 'mt2701_bank_data' was 
not declared. Should it be static?
drivers/thermal/mtk_thermal.c:208:11: warning: symbol 'mt2701_msr' was not 
declared. Should it be static?
drivers/thermal/mtk_thermal.c:212:11: warning: symbol 'mt2701_adcpnp' was not 
declared. Should it be static?
drivers/thermal/mtk_thermal.c:216:11: warning: symbol 'mt2701_mux_values' was 
not declared. Should it be static?

Make these variables as static to fix these warnings.

Signed-off-by: Vivek Gautam 
---

Based on Torvald's master branch. Build tested.

 drivers/thermal/mtk_thermal.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 34169c32d495..1aff7fde54b1 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -183,37 +183,37 @@ struct mtk_thermal {
 };
 
 /* MT8173 thermal sensor data */
-const int mt8173_bank_data[MT8173_NUM_ZONES][3] = {
+static const int mt8173_bank_data[MT8173_NUM_ZONES][3] = {
{ MT8173_TS2, MT8173_TS3 },
{ MT8173_TS2, MT8173_TS4 },
{ MT8173_TS1, MT8173_TS2, MT8173_TSABB },
{ MT8173_TS2 },
 };
 
-const int mt8173_msr[MT8173_NUM_SENSORS_PER_ZONE] = {
+static const int mt8173_msr[MT8173_NUM_SENSORS_PER_ZONE] = {
TEMP_MSR0, TEMP_MSR1, TEMP_MSR2, TEMP_MSR2
 };
 
-const int mt8173_adcpnp[MT8173_NUM_SENSORS_PER_ZONE] = {
+static const int mt8173_adcpnp[MT8173_NUM_SENSORS_PER_ZONE] = {
TEMP_ADCPNP0, TEMP_ADCPNP1, TEMP_ADCPNP2, TEMP_ADCPNP3
 };
 
-const int mt8173_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
+static const int mt8173_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
 
 /* MT2701 thermal sensor data */
-const int mt2701_bank_data[MT2701_NUM_SENSORS] = {
+static const int mt2701_bank_data[MT2701_NUM_SENSORS] = {
MT2701_TS1, MT2701_TS2, MT2701_TSABB
 };
 
-const int mt2701_msr[MT2701_NUM_SENSORS_PER_ZONE] = {
+static const int mt2701_msr[MT2701_NUM_SENSORS_PER_ZONE] = {
TEMP_MSR0, TEMP_MSR1, TEMP_MSR2
 };
 
-const int mt2701_adcpnp[MT2701_NUM_SENSORS_PER_ZONE] = {
+static const int mt2701_adcpnp[MT2701_NUM_SENSORS_PER_ZONE] = {
TEMP_ADCPNP0, TEMP_ADCPNP1, TEMP_ADCPNP2
 };
 
-const int mt2701_mux_values[MT2701_NUM_SENSORS] = { 0, 1, 16 };
+static const int mt2701_mux_values[MT2701_NUM_SENSORS] = { 0, 1, 16 };
 
 /**
  * The MT8173 thermal controller has four banks. Each bank can read up to
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

On Wed, Dec 28, 2016 at 6:43 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> On 12/22/2016 08:52 PM, Vivek Gautam wrote:
>>
>>>> +
>>>> +Optional properties:
>>>> + - nvmem-cells: a list of phandles to nvmem cells that contain fused
>>>> + tuning parameters for qusb2 phy, one for each entry
>>>> + in nvmem-cell-names.
>>>> + - nvmem-cell-names: must be "tune2_hstx_trim" for cell containing
>>>> +  HS Tx trim value.
>>> ditto.
>> nvmem doesn't allow, at this point, to get the cells by index.
>> Its APIs take 'const char' cell id and get the cell.
>>
>> We should add this support to get the cell by index.
>> Will create a patch for that, and drop the '-names' property from bindings.
>>
>
> If we introduce a cells based API just for this case of one phandle it
> may make sense to allow the cell id to be NULL and default to whatever
> cell is there without a names property. We do something similar with
> clks where a NULL connection id defaults to the first phandle in the
> list. Then we can avoid having a new set of DT specific APIs here. Of
> course, documentation should be updated to indicate that a NULL cell_id
> means use index 0 with DT.

Right. This makes sense. I didn't notice that we do something
similar in clocks.
I will post a new change for this (which should be pretty small
in comparison to earlier patchset that introduced new dt based APIs).

>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

On Wed, Dec 28, 2016 at 6:43 AM, Stephen Boyd  wrote:
> On 12/22/2016 08:52 PM, Vivek Gautam wrote:
>>
>>>> +
>>>> +Optional properties:
>>>> + - nvmem-cells: a list of phandles to nvmem cells that contain fused
>>>> + tuning parameters for qusb2 phy, one for each entry
>>>> + in nvmem-cell-names.
>>>> + - nvmem-cell-names: must be "tune2_hstx_trim" for cell containing
>>>> +  HS Tx trim value.
>>> ditto.
>> nvmem doesn't allow, at this point, to get the cells by index.
>> Its APIs take 'const char' cell id and get the cell.
>>
>> We should add this support to get the cell by index.
>> Will create a patch for that, and drop the '-names' property from bindings.
>>
>
> If we introduce a cells based API just for this case of one phandle it
> may make sense to allow the cell id to be NULL and default to whatever
> cell is there without a names property. We do something similar with
> clks where a NULL connection id defaults to the first phandle in the
> list. Then we can avoid having a new set of DT specific APIs here. Of
> course, documentation should be updated to indicate that a NULL cell_id
> means use index 0 with DT.

Right. This makes sense. I didn't notice that we do something
similar in clocks.
I will post a new change for this (which should be pretty small
in comparison to earlier patchset that introduced new dt based APIs).

>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC PATCH 1/6] phy: exynos-pcie: Add support for Exynos PCIe phy

[Vivek Gautam]

Hi Jaehoon,


On Mon, Dec 26, 2016 at 10:50 AM, Jaehoon Chung  wrote:
> This patch supports to use Generic Phy framework for Exynos PCIe phy.
> When Exynos that supported the pcie want to use the PCIe,
> it needs to control the phy resgister.
> But it should be more complex to control in their own PCIe device drivers.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  drivers/phy/Kconfig   |   9 ++
>  drivers/phy/Makefile  |   1 +
>  drivers/phy/phy-exynos-pcie.c | 227 
> ++
>  3 files changed, 237 insertions(+)
>  create mode 100644 drivers/phy/phy-exynos-pcie.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index fe00f91..94b0433 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -341,6 +341,15 @@ config PHY_EXYNOS5_USBDRD
>   This driver provides PHY interface for USB 3.0 DRD controller
>   present on Exynos5 SoC series.
>
> +config PHY_EXYNOS_PCIE
> +   bool "Exynos PCIe PHY driver"

Is there a reason for this not being 'tristate' ?

> +   depends on ARCH_EXYNOS && OF
> +   depends on PCI_EXYNOS5433
> +   select GENERIC_PHY
> +   help
> + Enable PCIe PHY support for Exynos SoC series.

If this driver is for Exynos5433, then same should come in this help
text as well.

> + This driver provides PHY interface for Exynos PCIe controller.
> +
>  config PHY_PISTACHIO_USB
> tristate "IMG Pistachio USB2.0 PHY driver"
> depends on MACH_PISTACHIO
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a534cf5..586344d 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -38,6 +38,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4X12_USB2) += 
> phy-exynos4x12-usb2.o
>  phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2)  += phy-exynos5250-usb2.o
>  phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
> +obj-$(CONFIG_PHY_EXYNOS_PCIE)  += phy-exynos-pcie.o
>  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
>  obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)   += phy-rockchip-inno-usb2.o
> diff --git a/drivers/phy/phy-exynos-pcie.c b/drivers/phy/phy-exynos-pcie.c
> new file mode 100644
> index 000..0f5eefd
> --- /dev/null
> +++ b/drivers/phy/phy-exynos-pcie.c
> @@ -0,0 +1,227 @@
> +/*
> + * Samsung EXYNOS SoC series PCIe PHY driver
> + *
> + * Phy provider for PCIe controller on Exynos SoC series
> + *
> + * Copyright (C) 2016 Samsung Electronics Co., Ltd.
> + * Jaehoon Chung 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

nit: It's good to have these includes in alphabetical order.

> +
> +#define PCIE_EXYNOS5433_PMU_PHY_OFFSET 0x730
> +#define PCIE_PHY_OFFSET(x) ((x) * 0x4)
> +
> +/* Sysreg Fsys register offset and bit for Exynos5433 */
> +#define PCIE_PHY_MAC_RESET 0x208
> +#define PCIE_MAC_RESET_MASK0xFF
> +#define PCIE_MAC_RESET BIT(4)
> +#define PCIE_L1SUB_CM_CON  0x1010
> +#define PCIE_REFCLK_GATING_EN  BIT(0)
> +#define PCIE_PHY_COMMON_RESET  0x1020
> +#define PCIE_PHY_RESET BIT(0)
> +#define PCIE_PHY_GLOBAL_RESET  0x1040
> +#define PCIE_GLOBAL_RESET  BIT(0)
> +#define PCIE_REFCLKBIT(1)
> +#define PCIE_REFCLK_MASK   0x16
> +#define PCIE_APP_REQ_EXIT_L1_MODE  BIT(5)
> +
> +enum exynos_pcie_phy_data_type {
> +   PCIE_PHY_TYPE_EXYNOS5433,
> +};
> +
> +struct exynos_pcie_phy_data {
> +   enum exynos_pcie_phy_data_type  ctrl_type;

Why do we need this controller type ?
If there are changes in the IP between different version,
then you can as well use different compatibles.

> +   u32 pmureg_offset; /* PMU_REG offset */

Please use top comments.

> +   struct phy_ops  *ops;
> +};
> +
> +/* for Exynos pcie phy */
> +struct exynos_pcie_phy {
> +   const struct exynos_pcie_phy_data *drv_data;
> +   struct regmap *pmureg;
> +   struct regmap *fsysreg;
> +   void __iomem *phy_base;

just 'base' ?

> +};
> +
> +static void exynos_pcie_phy_writel(void __iomem *base, u32 val, u32 offset)
> +{
> +   writel(val, base + offset);
> +}
> +
> +static int exynos_pcie_phy_init(struct phy *phy)
> +{
> +   struct exynos_pcie_phy *ep = phy_get_drvdata(phy);
> +
> +   if (ep->fsysreg) {
> +   regmap_update_bits(ep->fsysreg, PCIE_PHY_COMMON_RESET,
> +   PCIE_PHY_RESET, 1);
> +   regmap_update_bits(ep->fsysreg, 

Re: [RFC PATCH 1/6] phy: exynos-pcie: Add support for Exynos PCIe phy

[Vivek Gautam]

Hi Jaehoon,


On Mon, Dec 26, 2016 at 10:50 AM, Jaehoon Chung  wrote:
> This patch supports to use Generic Phy framework for Exynos PCIe phy.
> When Exynos that supported the pcie want to use the PCIe,
> it needs to control the phy resgister.
> But it should be more complex to control in their own PCIe device drivers.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  drivers/phy/Kconfig   |   9 ++
>  drivers/phy/Makefile  |   1 +
>  drivers/phy/phy-exynos-pcie.c | 227 
> ++
>  3 files changed, 237 insertions(+)
>  create mode 100644 drivers/phy/phy-exynos-pcie.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index fe00f91..94b0433 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -341,6 +341,15 @@ config PHY_EXYNOS5_USBDRD
>   This driver provides PHY interface for USB 3.0 DRD controller
>   present on Exynos5 SoC series.
>
> +config PHY_EXYNOS_PCIE
> +   bool "Exynos PCIe PHY driver"

Is there a reason for this not being 'tristate' ?

> +   depends on ARCH_EXYNOS && OF
> +   depends on PCI_EXYNOS5433
> +   select GENERIC_PHY
> +   help
> + Enable PCIe PHY support for Exynos SoC series.

If this driver is for Exynos5433, then same should come in this help
text as well.

> + This driver provides PHY interface for Exynos PCIe controller.
> +
>  config PHY_PISTACHIO_USB
> tristate "IMG Pistachio USB2.0 PHY driver"
> depends on MACH_PISTACHIO
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a534cf5..586344d 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -38,6 +38,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4X12_USB2) += 
> phy-exynos4x12-usb2.o
>  phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2)  += phy-exynos5250-usb2.o
>  phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
> +obj-$(CONFIG_PHY_EXYNOS_PCIE)  += phy-exynos-pcie.o
>  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
>  obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)   += phy-rockchip-inno-usb2.o
> diff --git a/drivers/phy/phy-exynos-pcie.c b/drivers/phy/phy-exynos-pcie.c
> new file mode 100644
> index 000..0f5eefd
> --- /dev/null
> +++ b/drivers/phy/phy-exynos-pcie.c
> @@ -0,0 +1,227 @@
> +/*
> + * Samsung EXYNOS SoC series PCIe PHY driver
> + *
> + * Phy provider for PCIe controller on Exynos SoC series
> + *
> + * Copyright (C) 2016 Samsung Electronics Co., Ltd.
> + * Jaehoon Chung 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

nit: It's good to have these includes in alphabetical order.

> +
> +#define PCIE_EXYNOS5433_PMU_PHY_OFFSET 0x730
> +#define PCIE_PHY_OFFSET(x) ((x) * 0x4)
> +
> +/* Sysreg Fsys register offset and bit for Exynos5433 */
> +#define PCIE_PHY_MAC_RESET 0x208
> +#define PCIE_MAC_RESET_MASK0xFF
> +#define PCIE_MAC_RESET BIT(4)
> +#define PCIE_L1SUB_CM_CON  0x1010
> +#define PCIE_REFCLK_GATING_EN  BIT(0)
> +#define PCIE_PHY_COMMON_RESET  0x1020
> +#define PCIE_PHY_RESET BIT(0)
> +#define PCIE_PHY_GLOBAL_RESET  0x1040
> +#define PCIE_GLOBAL_RESET  BIT(0)
> +#define PCIE_REFCLKBIT(1)
> +#define PCIE_REFCLK_MASK   0x16
> +#define PCIE_APP_REQ_EXIT_L1_MODE  BIT(5)
> +
> +enum exynos_pcie_phy_data_type {
> +   PCIE_PHY_TYPE_EXYNOS5433,
> +};
> +
> +struct exynos_pcie_phy_data {
> +   enum exynos_pcie_phy_data_type  ctrl_type;

Why do we need this controller type ?
If there are changes in the IP between different version,
then you can as well use different compatibles.

> +   u32 pmureg_offset; /* PMU_REG offset */

Please use top comments.

> +   struct phy_ops  *ops;
> +};
> +
> +/* for Exynos pcie phy */
> +struct exynos_pcie_phy {
> +   const struct exynos_pcie_phy_data *drv_data;
> +   struct regmap *pmureg;
> +   struct regmap *fsysreg;
> +   void __iomem *phy_base;

just 'base' ?

> +};
> +
> +static void exynos_pcie_phy_writel(void __iomem *base, u32 val, u32 offset)
> +{
> +   writel(val, base + offset);
> +}
> +
> +static int exynos_pcie_phy_init(struct phy *phy)
> +{
> +   struct exynos_pcie_phy *ep = phy_get_drvdata(phy);
> +
> +   if (ep->fsysreg) {
> +   regmap_update_bits(ep->fsysreg, PCIE_PHY_COMMON_RESET,
> +   PCIE_PHY_RESET, 1);
> +   regmap_update_bits(ep->fsysreg, PCIE_PHY_MAC_RESET,
> +   PCIE_MAC_RESET, 0);
> 

[PATCH RESEND 0/2] nvmem: core: Support to get nvmem cell using index

[Vivek Gautam]

Couple of patches to support getting nvmem cell using cell index.
Usually when we have only one nvmem cell for a device, we may not
want to add a nvmem-cell-names property to the device node.
With these patches, we can now get a cell using phandle and the cell
index.

Updated the links to patch and thread in [1] and [2]. Missed them
earlier. The patches 1/2 and 2/2 remain unchanged.

 - Based on torvald's master branch.
 - Tested with next-20161223 tag and a revert to patch [1], to fix
   build issue on arm64 (as indicated in the thread [2]), on
   db410c target. Able to read temperatures from thermal sensors.

[1] 1a339a14b1f2 arm64: setup: introduce kaslr_offset()
[2] https://lkml.org/lkml/2016/12/22/217

Vivek Gautam (2):
  nvmem: core: Allow getting cell by index in phandle
  nvmem: core: Add a resource managed API to get cell by index

 drivers/nvmem/core.c   | 68 +-
 include/linux/nvmem-consumer.h | 19 +++-
 2 files changed, 79 insertions(+), 8 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH RESEND 0/2] nvmem: core: Support to get nvmem cell using index

[Vivek Gautam]

Couple of patches to support getting nvmem cell using cell index.
Usually when we have only one nvmem cell for a device, we may not
want to add a nvmem-cell-names property to the device node.
With these patches, we can now get a cell using phandle and the cell
index.

Updated the links to patch and thread in [1] and [2]. Missed them
earlier. The patches 1/2 and 2/2 remain unchanged.

 - Based on torvald's master branch.
 - Tested with next-20161223 tag and a revert to patch [1], to fix
   build issue on arm64 (as indicated in the thread [2]), on
   db410c target. Able to read temperatures from thermal sensors.

[1] 1a339a14b1f2 arm64: setup: introduce kaslr_offset()
[2] https://lkml.org/lkml/2016/12/22/217

Vivek Gautam (2):
  nvmem: core: Allow getting cell by index in phandle
  nvmem: core: Add a resource managed API to get cell by index

 drivers/nvmem/core.c   | 68 +-
 include/linux/nvmem-consumer.h | 19 +++-
 2 files changed, 79 insertions(+), 8 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/2] nvmem: core: Support to get nvmem cell using index

[Vivek Gautam]

Couple of patches to support getting nvmem cell using cell index.
Usually when we have only one nvmem cell for a device, we may not
want to add a nvmem-cell-names property to the device node.
With these patches, we can now get a cell using phandle and the cell
index.

 - Based on torvald's master branch.
 - Tested with next-20161223 tag and a revert to patch [1], to fix
   build issue on arm64, on db410c target. Able to read temperatures
   from thermal sensors.

Vivek Gautam (2):
  nvmem: core: Allow getting cell by index in phandle
  nvmem: core: Add a resource managed API to get cell by index

 drivers/nvmem/core.c   | 68 +-
 include/linux/nvmem-consumer.h | 19 +++-
 2 files changed, 79 insertions(+), 8 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/2] nvmem: core: Support to get nvmem cell using index

[Vivek Gautam]

Couple of patches to support getting nvmem cell using cell index.
Usually when we have only one nvmem cell for a device, we may not
want to add a nvmem-cell-names property to the device node.
With these patches, we can now get a cell using phandle and the cell
index.

 - Based on torvald's master branch.
 - Tested with next-20161223 tag and a revert to patch [1], to fix
   build issue on arm64, on db410c target. Able to read temperatures
   from thermal sensors.

Vivek Gautam (2):
  nvmem: core: Allow getting cell by index in phandle
  nvmem: core: Add a resource managed API to get cell by index

 drivers/nvmem/core.c   | 68 +-
 include/linux/nvmem-consumer.h | 19 +++-
 2 files changed, 79 insertions(+), 8 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/2] nvmem: core: Allow getting cell by index in phandle

[Vivek Gautam]

Fork out a method to get nvmem cell using cell index
in the phandle for the cell.
This helps in getting the lone cell given in the phandle,
without mentioning the cell name in device tree.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
 drivers/nvmem/core.c   | 35 ---
 include/linux/nvmem-consumer.h | 11 ++-
 2 files changed, 38 insertions(+), 8 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 4c3884266afe..f46b8f667571 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -743,25 +743,24 @@ static struct nvmem_cell *nvmem_cell_get_from_list(const 
char *cell_id)
 
 #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
 /**
- * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell id
+ * of_nvmem_cell_get_by_index() - Get a nvmem cell from given device node and
+ cell index
  *
  * @dev node: Device tree node that uses the nvmem cell
- * @id: nvmem cell name from nvmem-cell-names property.
+ * @index: index of nvmem cell
  *
  * Return: Will be an ERR_PTR() on error or a valid pointer
  * to a struct nvmem_cell.  The nvmem_cell will be freed by the
  * nvmem_cell_put().
  */
-struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
-   const char *name)
+struct nvmem_cell *of_nvmem_cell_get_by_index(struct device_node *np,
+   int index)
 {
struct device_node *cell_np, *nvmem_np;
struct nvmem_cell *cell;
struct nvmem_device *nvmem;
const __be32 *addr;
-   int rval, len, index;
-
-   index = of_property_match_string(np, "nvmem-cell-names", name);
+   int rval, len;
 
cell_np = of_parse_phandle(np, "nvmem-cells", index);
if (!cell_np)
@@ -824,6 +823,28 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node 
*np,
 
return ERR_PTR(rval);
 }
+EXPORT_SYMBOL_GPL(of_nvmem_cell_get_by_index);
+
+/**
+ * of_nvmem_cell_get() - Get a nvmem cell from given device node and
+ * cell id.
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @id: nvmem cell name from nvmem-cell-names property
+ *
+ * Return: Will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_cell.  The nvmem_cell will be freed by the
+ * nvmem_cell_put().
+ */
+struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
+   const char *id)
+{
+   int index;
+
+   index = of_property_match_string(np, "nvmem-cell-names", id);
+
+   return of_nvmem_cell_get_by_index(np, index);
+}
 EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
 #endif
 
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index c2256d746543..0dd9ef837a32 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -138,11 +138,20 @@ static inline int nvmem_device_write(struct nvmem_device 
*nvmem,
 #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
 struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
 const char *name);
+struct nvmem_cell *of_nvmem_cell_get_by_index(struct device_node *np,
+ int index);
 struct nvmem_device *of_nvmem_device_get(struct device_node *np,
 const char *name);
 #else
+static inline
+struct nvmem_cell *of_nvmem_cell_get_by_index(struct device_node *np,
+ int index)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 static inline struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
-const char *name)
+  const char *name)
 {
return ERR_PTR(-ENOSYS);
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/2] nvmem: core: Allow getting cell by index in phandle

[Vivek Gautam]

Fork out a method to get nvmem cell using cell index
in the phandle for the cell.
This helps in getting the lone cell given in the phandle,
without mentioning the cell name in device tree.

Signed-off-by: Vivek Gautam 
---
 drivers/nvmem/core.c   | 35 ---
 include/linux/nvmem-consumer.h | 11 ++-
 2 files changed, 38 insertions(+), 8 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 4c3884266afe..f46b8f667571 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -743,25 +743,24 @@ static struct nvmem_cell *nvmem_cell_get_from_list(const 
char *cell_id)
 
 #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
 /**
- * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell id
+ * of_nvmem_cell_get_by_index() - Get a nvmem cell from given device node and
+ cell index
  *
  * @dev node: Device tree node that uses the nvmem cell
- * @id: nvmem cell name from nvmem-cell-names property.
+ * @index: index of nvmem cell
  *
  * Return: Will be an ERR_PTR() on error or a valid pointer
  * to a struct nvmem_cell.  The nvmem_cell will be freed by the
  * nvmem_cell_put().
  */
-struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
-   const char *name)
+struct nvmem_cell *of_nvmem_cell_get_by_index(struct device_node *np,
+   int index)
 {
struct device_node *cell_np, *nvmem_np;
struct nvmem_cell *cell;
struct nvmem_device *nvmem;
const __be32 *addr;
-   int rval, len, index;
-
-   index = of_property_match_string(np, "nvmem-cell-names", name);
+   int rval, len;
 
cell_np = of_parse_phandle(np, "nvmem-cells", index);
if (!cell_np)
@@ -824,6 +823,28 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node 
*np,
 
return ERR_PTR(rval);
 }
+EXPORT_SYMBOL_GPL(of_nvmem_cell_get_by_index);
+
+/**
+ * of_nvmem_cell_get() - Get a nvmem cell from given device node and
+ * cell id.
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @id: nvmem cell name from nvmem-cell-names property
+ *
+ * Return: Will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_cell.  The nvmem_cell will be freed by the
+ * nvmem_cell_put().
+ */
+struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
+   const char *id)
+{
+   int index;
+
+   index = of_property_match_string(np, "nvmem-cell-names", id);
+
+   return of_nvmem_cell_get_by_index(np, index);
+}
 EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
 #endif
 
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index c2256d746543..0dd9ef837a32 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -138,11 +138,20 @@ static inline int nvmem_device_write(struct nvmem_device 
*nvmem,
 #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
 struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
 const char *name);
+struct nvmem_cell *of_nvmem_cell_get_by_index(struct device_node *np,
+ int index);
 struct nvmem_device *of_nvmem_device_get(struct device_node *np,
 const char *name);
 #else
+static inline
+struct nvmem_cell *of_nvmem_cell_get_by_index(struct device_node *np,
+ int index)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 static inline struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
-const char *name)
+  const char *name)
 {
return ERR_PTR(-ENOSYS);
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/2] nvmem: core: Add a resource managed API to get cell by index

[Vivek Gautam]

Adding a resource managed method to obtain nvmem cell
using cell index.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
 drivers/nvmem/core.c   | 33 +
 include/linux/nvmem-consumer.h |  8 
 2 files changed, 41 insertions(+)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index f46b8f667571..3d0eca689931 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -907,6 +907,39 @@ struct nvmem_cell *devm_nvmem_cell_get(struct device *dev, 
const char *id)
 }
 EXPORT_SYMBOL_GPL(devm_nvmem_cell_get);
 
+#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
+/**
+ * devm_nvmem_cell_get_by_index() - Get nvmem cell of device from cell index;
+ * resource managed.
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @index: index of nvmem cell
+ *
+ * Return: Will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_cell.  The nvmem_cell will be freed by the
+ * automatically once the device is freed.
+ */
+struct nvmem_cell *devm_nvmem_cell_get_by_index(struct device *dev, int index)
+{
+   struct nvmem_cell **ptr, *cell;
+
+   ptr = devres_alloc(devm_nvmem_cell_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return ERR_PTR(-ENOMEM);
+
+   cell = of_nvmem_cell_get_by_index(dev->of_node, index);
+   if (!IS_ERR(cell)) {
+   *ptr = cell;
+   devres_add(dev, ptr);
+   } else {
+   devres_free(ptr);
+   }
+
+   return cell;
+}
+EXPORT_SYMBOL_GPL(devm_nvmem_cell_get_by_index);
+#endif
+
 static int devm_nvmem_cell_match(struct device *dev, void *res, void *data)
 {
struct nvmem_cell **c = res;
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 0dd9ef837a32..065647b5143e 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -142,6 +142,8 @@ struct nvmem_cell *of_nvmem_cell_get_by_index(struct 
device_node *np,
  int index);
 struct nvmem_device *of_nvmem_device_get(struct device_node *np,
 const char *name);
+struct nvmem_cell *devm_nvmem_cell_get_by_index(struct device *dev,
+  int index);
 #else
 static inline
 struct nvmem_cell *of_nvmem_cell_get_by_index(struct device_node *np,
@@ -161,6 +163,12 @@ static inline struct nvmem_device 
*of_nvmem_device_get(struct device_node *np,
 {
return ERR_PTR(-ENOSYS);
 }
+
+static inline
+struct nvmem_cell *devm_nvmem_cell_get_by_index(struct device *dev, int index)
+{
+   return ERR_PTR(-ENOSYS);
+}
 #endif /* CONFIG_NVMEM && CONFIG_OF */
 
 #endif  /* ifndef _LINUX_NVMEM_CONSUMER_H */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/2] nvmem: core: Add a resource managed API to get cell by index

[Vivek Gautam]

Adding a resource managed method to obtain nvmem cell
using cell index.

Signed-off-by: Vivek Gautam 
---
 drivers/nvmem/core.c   | 33 +
 include/linux/nvmem-consumer.h |  8 
 2 files changed, 41 insertions(+)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index f46b8f667571..3d0eca689931 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -907,6 +907,39 @@ struct nvmem_cell *devm_nvmem_cell_get(struct device *dev, 
const char *id)
 }
 EXPORT_SYMBOL_GPL(devm_nvmem_cell_get);
 
+#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
+/**
+ * devm_nvmem_cell_get_by_index() - Get nvmem cell of device from cell index;
+ * resource managed.
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @index: index of nvmem cell
+ *
+ * Return: Will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_cell.  The nvmem_cell will be freed by the
+ * automatically once the device is freed.
+ */
+struct nvmem_cell *devm_nvmem_cell_get_by_index(struct device *dev, int index)
+{
+   struct nvmem_cell **ptr, *cell;
+
+   ptr = devres_alloc(devm_nvmem_cell_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return ERR_PTR(-ENOMEM);
+
+   cell = of_nvmem_cell_get_by_index(dev->of_node, index);
+   if (!IS_ERR(cell)) {
+   *ptr = cell;
+   devres_add(dev, ptr);
+   } else {
+   devres_free(ptr);
+   }
+
+   return cell;
+}
+EXPORT_SYMBOL_GPL(devm_nvmem_cell_get_by_index);
+#endif
+
 static int devm_nvmem_cell_match(struct device *dev, void *res, void *data)
 {
struct nvmem_cell **c = res;
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 0dd9ef837a32..065647b5143e 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -142,6 +142,8 @@ struct nvmem_cell *of_nvmem_cell_get_by_index(struct 
device_node *np,
  int index);
 struct nvmem_device *of_nvmem_device_get(struct device_node *np,
 const char *name);
+struct nvmem_cell *devm_nvmem_cell_get_by_index(struct device *dev,
+  int index);
 #else
 static inline
 struct nvmem_cell *of_nvmem_cell_get_by_index(struct device_node *np,
@@ -161,6 +163,12 @@ static inline struct nvmem_device 
*of_nvmem_device_get(struct device_node *np,
 {
return ERR_PTR(-ENOSYS);
 }
+
+static inline
+struct nvmem_cell *devm_nvmem_cell_get_by_index(struct device *dev, int index)
+{
+   return ERR_PTR(-ENOSYS);
+}
 #endif /* CONFIG_NVMEM && CONFIG_OF */
 
 #endif  /* ifndef _LINUX_NVMEM_CONSUMER_H */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

Hi Rob,


On Fri, Dec 23, 2016 at 2:46 AM, Rob Herring <r...@kernel.org> wrote:
> On Tue, Dec 20, 2016 at 10:33:48PM +0530, Vivek Gautam wrote:
>> Qualcomm chipsets have QUSB2 phy controller that provides
>> HighSpeed functionality for DWC3 controller.
>> Adding dt binding information for the same.
>>
>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>> ---
>>
>> Changes since v2:
>>  - Removed binding for "ref_clk_src" since we don't request this
>>clock in the driver.
>>  - Addressed s/vdda-phy-dpdm/vdda-phy-dpdm-supply.
>>  - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
>>  - Addressed s/tune2_hstx_trim_efuse/tune2_hstx_trim. Don't need to add
>>'efuse' suffix to nvmem cell.
>>  - Addressed s/qusb2phy/phy for the node name.
>>
>> Changes since v1:
>>  - New patch, forked out of the original driver patch:
>>"phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
>>  - Updated dt bindings to remove 'hstx-trim-bit-offset' and
>>'hstx-trim-bit-len' bindings.
>>
>>  .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 53 
>> ++
>>  1 file changed, 53 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
>> b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>> new file mode 100644
>> index ..594f2dcd12dd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>> @@ -0,0 +1,53 @@
>> +Qualcomm QUSB2 phy controller
>> +=
>> +
>> +QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
>> +
>> +Required properties:
>> + - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
>> + - reg: offset and length of the PHY register set.
>> + - #phy-cells: must be 0.
>> +
>> + - 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,
>> + "ref" for 19.2 MHz ref clk,
>> + "iface" for phy interface clock (Optional).
>> +
>> + - vdd-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.
>> + - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
>> signals.
>> +
>> + - 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.
>
> -names is pointless when only one.

Sure, will drop the -names property, and get the reset control by index.

>
>> +
>> +Optional properties:
>> + - nvmem-cells: a list of phandles to nvmem cells that contain fused
>> + tuning parameters for qusb2 phy, one for each entry
>> + in nvmem-cell-names.
>> + - nvmem-cell-names: must be "tune2_hstx_trim" for cell containing
>> +  HS Tx trim value.
>
> ditto.

nvmem doesn't allow, at this point, to get the cells by index.
Its APIs take 'const char' cell id and get the cell.

We should add this support to get the cell by index.
Will create a patch for that, and drop the '-names' property from bindings.

>
> With those dropped,
>
> Acked-by: Rob Herring <r...@kernel.org>

Thanks for the Ack.

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



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

Hi Rob,


On Fri, Dec 23, 2016 at 2:46 AM, Rob Herring  wrote:
> On Tue, Dec 20, 2016 at 10:33:48PM +0530, Vivek Gautam wrote:
>> Qualcomm chipsets have QUSB2 phy controller that provides
>> HighSpeed functionality for DWC3 controller.
>> Adding dt binding information for the same.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>>
>> Changes since v2:
>>  - Removed binding for "ref_clk_src" since we don't request this
>>clock in the driver.
>>  - Addressed s/vdda-phy-dpdm/vdda-phy-dpdm-supply.
>>  - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
>>  - Addressed s/tune2_hstx_trim_efuse/tune2_hstx_trim. Don't need to add
>>'efuse' suffix to nvmem cell.
>>  - Addressed s/qusb2phy/phy for the node name.
>>
>> Changes since v1:
>>  - New patch, forked out of the original driver patch:
>>"phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
>>  - Updated dt bindings to remove 'hstx-trim-bit-offset' and
>>'hstx-trim-bit-len' bindings.
>>
>>  .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 53 
>> ++
>>  1 file changed, 53 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
>> b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>> new file mode 100644
>> index ..594f2dcd12dd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>> @@ -0,0 +1,53 @@
>> +Qualcomm QUSB2 phy controller
>> +=
>> +
>> +QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
>> +
>> +Required properties:
>> + - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
>> + - reg: offset and length of the PHY register set.
>> + - #phy-cells: must be 0.
>> +
>> + - 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,
>> + "ref" for 19.2 MHz ref clk,
>> + "iface" for phy interface clock (Optional).
>> +
>> + - vdd-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.
>> + - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
>> signals.
>> +
>> + - 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.
>
> -names is pointless when only one.

Sure, will drop the -names property, and get the reset control by index.

>
>> +
>> +Optional properties:
>> + - nvmem-cells: a list of phandles to nvmem cells that contain fused
>> + tuning parameters for qusb2 phy, one for each entry
>> + in nvmem-cell-names.
>> + - nvmem-cell-names: must be "tune2_hstx_trim" for cell containing
>> +  HS Tx trim value.
>
> ditto.

nvmem doesn't allow, at this point, to get the cells by index.
Its APIs take 'const char' cell id and get the cell.

We should add this support to get the cell by index.
Will create a patch for that, and drop the '-names' property from bindings.

>
> With those dropped,
>
> Acked-by: Rob Herring 

Thanks for the Ack.

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



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v5 0/6] inherit dma configuration from parent dev

[Vivek Gautam]

On Thu, Nov 17, 2016 at 5:13 PM, Sriram Dash <sriram.d...@nxp.com> wrote:
> For xhci-hcd platform device, all the DMA parameters are not
> configured properly, notably dma ops for dwc3 devices.
>
> The idea here is that you pass in the parent of_node along
> with the child device pointer, so it would behave exactly
> like the parent already does. The difference is that it also
> handles all the other attributes besides the mask.
>
> Arnd Bergmann (6):
>   usb: separate out sysdev pointer from usb_bus
>   usb: chipidea: use bus->sysdev for DMA configuration
>   usb: ehci: fsl: use bus->sysdev for DMA configuration
>   usb: xhci: use bus->sysdev for DMA configuration
>   usb: dwc3: use bus->sysdev for DMA configuration
>   usb: dwc3: Do not set dma coherent mask

Tested patches 1, 4 & 5 on db820c platform with required set of patches [1] for
phy.

Tested-by: Vivek Gautam <vivek.gau...@codeaurora.org>
for the above mentioned patches.

[1] https://lkml.org/lkml/2016/12/20/392


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v5 0/6] inherit dma configuration from parent dev

[Vivek Gautam]

On Thu, Nov 17, 2016 at 5:13 PM, Sriram Dash  wrote:
> For xhci-hcd platform device, all the DMA parameters are not
> configured properly, notably dma ops for dwc3 devices.
>
> The idea here is that you pass in the parent of_node along
> with the child device pointer, so it would behave exactly
> like the parent already does. The difference is that it also
> handles all the other attributes besides the mask.
>
> Arnd Bergmann (6):
>   usb: separate out sysdev pointer from usb_bus
>   usb: chipidea: use bus->sysdev for DMA configuration
>   usb: ehci: fsl: use bus->sysdev for DMA configuration
>   usb: xhci: use bus->sysdev for DMA configuration
>   usb: dwc3: use bus->sysdev for DMA configuration
>   usb: dwc3: Do not set dma coherent mask

Tested patches 1, 4 & 5 on db820c platform with required set of patches [1] for
phy.

Tested-by: Vivek Gautam 
for the above mentioned patches.

[1] https://lkml.org/lkml/2016/12/20/392


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

Qualcomm chipsets have QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/vdda-phy-dpdm/vdda-phy-dpdm-supply.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Addressed s/tune2_hstx_trim_efuse/tune2_hstx_trim. Don't need to add
   'efuse' suffix to nvmem cell.
 - Addressed s/qusb2phy/phy for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
 - Updated dt bindings to remove 'hstx-trim-bit-offset' and
   'hstx-trim-bit-len' bindings.

 .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
new file mode 100644
index ..594f2dcd12dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -0,0 +1,53 @@
+Qualcomm QUSB2 phy controller
+=
+
+QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+Required properties:
+ - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - 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,
+   "ref" for 19.2 MHz ref clk,
+   "iface" for phy interface clock (Optional).
+
+ - vdd-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.
+ - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
signals.
+
+ - 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.
+
+Optional properties:
+ - nvmem-cells: a list of phandles to nvmem cells that contain fused
+   tuning parameters for qusb2 phy, one for each entry
+   in nvmem-cell-names.
+ - nvmem-cell-names: must be "tune2_hstx_trim" for cell containing
+HS Tx trim value.
+
+ - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+
+Example:
+   hsusb_phy: phy@7411000 {
+   compatible = "qcom,msm8996-qusb2-phy";
+   reg = <0x07411000 0x180>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+   < GCC_RX1_USB2_CLKREF_CLK>,
+   clock-names = "cfg_ahb", "ref";
+
+   vdd-phy-supply = <_s2>;
+   vdda-pll-supply = <_l12>;
+   vdda-phy-dpdm-supply = <_l24>;
+
+   resets = < GCC_QUSB2PHY_PRIM_BCR>;
+   reset-names = "phy";
+
+   nvmem-cells = <_hstx_trim>;
+   nvmem-cell-names = "tune2_hstx_trim";
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

Qualcomm chipsets have QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam 
---

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/vdda-phy-dpdm/vdda-phy-dpdm-supply.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Addressed s/tune2_hstx_trim_efuse/tune2_hstx_trim. Don't need to add
   'efuse' suffix to nvmem cell.
 - Addressed s/qusb2phy/phy for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
 - Updated dt bindings to remove 'hstx-trim-bit-offset' and
   'hstx-trim-bit-len' bindings.

 .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
new file mode 100644
index ..594f2dcd12dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -0,0 +1,53 @@
+Qualcomm QUSB2 phy controller
+=
+
+QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+Required properties:
+ - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - 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,
+   "ref" for 19.2 MHz ref clk,
+   "iface" for phy interface clock (Optional).
+
+ - vdd-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.
+ - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
signals.
+
+ - 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.
+
+Optional properties:
+ - nvmem-cells: a list of phandles to nvmem cells that contain fused
+   tuning parameters for qusb2 phy, one for each entry
+   in nvmem-cell-names.
+ - nvmem-cell-names: must be "tune2_hstx_trim" for cell containing
+HS Tx trim value.
+
+ - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+
+Example:
+   hsusb_phy: phy@7411000 {
+   compatible = "qcom,msm8996-qusb2-phy";
+   reg = <0x07411000 0x180>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+   < GCC_RX1_USB2_CLKREF_CLK>,
+   clock-names = "cfg_ahb", "ref";
+
+   vdd-phy-supply = <_s2>;
+   vdda-pll-supply = <_l12>;
+   vdda-phy-dpdm-supply = <_l24>;
+
+   resets = < GCC_QUSB2PHY_PRIM_BCR>;
+   reset-names = "phy";
+
+   nvmem-cells = <_hstx_trim>;
+   nvmem-cell-names = "tune2_hstx_trim";
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
   USB3, PCIe, UFS and few other controllers.

The patches are based on next branch of linux-phy tree.

These have been tested on Dragon board db820c hardware with
required set of patches on integration tree maintained by
Linaro landing team for Qualcomm [1].

Couple of other patches [2,3] for nvmem are also pulled in for testing.

Changes since v2:
 - Addressed review comments given by Rob and Stephen for bindings.
 - Addressed the review comments given by Stephen for the qusb2 and qmp
   phy drivers.
   Please see individual patches for detailed changelogs.

Changes since v1:
 - Moved device tree binding documentation to separate patches, as suggested
   by Rob.
 - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
   given by Rob.
 - Addressed review comments from Kishon.
 - Addressed review comments from Srinivas for QMP phy driver.
 - Addressed kbuild warning.

[1] 
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=integration-linux-qcomlt
[2] https://lkml.org/lkml/2016/11/17/21
[3] https://lkml.org/lkml/2016/12/19/18

Vivek Gautam (4):
  dt-bindings: phy: Add support for QUSB2 phy
  phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
  dt-bindings: phy: Add support for QMP phy
  phy: qcom-qmp: new qmp phy driver for qcom-chipsets

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   |   71 ++
 .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   53 +
 drivers/phy/Kconfig|   18 +
 drivers/phy/Makefile   |2 +
 drivers/phy/phy-qcom-qmp.c | 1191 
 drivers/phy/phy-qcom-qusb2.c   |  540 +
 6 files changed, 1875 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
 create mode 100644 drivers/phy/phy-qcom-qmp.c
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

PHY transceiver driver for QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller present on
Qualcomm chipsets.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to
   do that since 'xo' is modeled as parent to this clock.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Moved nvmem_cell_get() to probe function.
 - Simplified phy pll status handling.
 - Using of_device_get_match_data() to get match data.
 - Uniformly using lowercase for hex numbers.
 - Fixed sparse warnings.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - removed reference to clk_enabled/pwr_enabled.
 - moved clock and regulator enable code to phy_power_on/off() callbacks.
 - fixed return on EPROBE_DEFER in qusb2_phy_probe().
 - fixed phy create and phy register ordering.
 - removed references to non-lkml links from commit message.
 - took care of other minor nits.
 - Fixed coccinelle warnings -
   'PTR_ERR applied after initialization to constant'
 - Addressed review comment, regarding qfprom access for tune2 param value.
   This driver is now based on qfprom patch[1] that allows byte access now.

 drivers/phy/Kconfig  |  10 +
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-qcom-qusb2.c | 540 +++
 3 files changed, 551 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e8eb7f225a88..0ed53d018b23 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -430,6 +430,16 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_QCOM_QUSB2
+   tristate "Qualcomm QUSB2 PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
+ controllers on Qualcomm chips. This driver supports the high-speed
+ PHY which is usually paired with either the ChipIdea or Synopsys DWC3
+ USB IPs on MSM SOCs.
+
 config PHY_QCOM_UFS
tristate "Qualcomm UFS PHY driver"
depends on OF && ARCH_QCOM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 65eb2f436a41..dad1682b80e3 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
 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_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
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
new file mode 100644
index ..ae7feae835fd
--- /dev/null
+++ b/drivers/phy/phy-qcom-qusb2.c
@@ -0,0 +1,540 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define QUSB2PHY_PLL_TEST  0x04
+#define CLK_REF_SELBIT(7)
+
+#define QUSB2PHY_PLL_TUNE  0x08
+#define QUSB2PHY_PLL_USER_CTL1 0x0c
+#define QUSB2PHY_PLL_USER_CTL2 0x10
+#define QUSB2PHY_PLL_AUTOPGM_CTL1  0x1c
+#define QUSB2PHY_PLL_PWR_CTRL  0x18
+
+#define QUSB2PHY_PLL_STATUS0x38
+#define PLL_LOCKED BIT(5)
+
+#define QUSB2PHY_PORT_TUNE1 0x80
+#define QUSB2PHY_PORT_TUNE2 0x84
+#define QUSB2PHY_PORT_TUNE3 0x88
+#define QUSB2PHY_PORT_TUNE4 0x8c
+#define QUSB2PHY_PORT_TUNE50x90
+#define QUSB2PHY_PORT_TEST20x9c
+
+#define QUSB2PHY_PORT_POWERDOWN0xb4
+#define CLAMP_N_EN BIT(5)
+#define FREEZIO_N  BIT(1)
+#d

[PATCH v3 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
   USB3, PCIe, UFS and few other controllers.

The patches are based on next branch of linux-phy tree.

These have been tested on Dragon board db820c hardware with
required set of patches on integration tree maintained by
Linaro landing team for Qualcomm [1].

Couple of other patches [2,3] for nvmem are also pulled in for testing.

Changes since v2:
 - Addressed review comments given by Rob and Stephen for bindings.
 - Addressed the review comments given by Stephen for the qusb2 and qmp
   phy drivers.
   Please see individual patches for detailed changelogs.

Changes since v1:
 - Moved device tree binding documentation to separate patches, as suggested
   by Rob.
 - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
   given by Rob.
 - Addressed review comments from Kishon.
 - Addressed review comments from Srinivas for QMP phy driver.
 - Addressed kbuild warning.

[1] 
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=integration-linux-qcomlt
[2] https://lkml.org/lkml/2016/11/17/21
[3] https://lkml.org/lkml/2016/12/19/18

Vivek Gautam (4):
  dt-bindings: phy: Add support for QUSB2 phy
  phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
  dt-bindings: phy: Add support for QMP phy
  phy: qcom-qmp: new qmp phy driver for qcom-chipsets

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   |   71 ++
 .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   53 +
 drivers/phy/Kconfig|   18 +
 drivers/phy/Makefile   |2 +
 drivers/phy/phy-qcom-qmp.c | 1191 
 drivers/phy/phy-qcom-qusb2.c   |  540 +
 6 files changed, 1875 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
 create mode 100644 drivers/phy/phy-qcom-qmp.c
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

PHY transceiver driver for QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller present on
Qualcomm chipsets.

Signed-off-by: Vivek Gautam 
---

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to
   do that since 'xo' is modeled as parent to this clock.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Moved nvmem_cell_get() to probe function.
 - Simplified phy pll status handling.
 - Using of_device_get_match_data() to get match data.
 - Uniformly using lowercase for hex numbers.
 - Fixed sparse warnings.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - removed reference to clk_enabled/pwr_enabled.
 - moved clock and regulator enable code to phy_power_on/off() callbacks.
 - fixed return on EPROBE_DEFER in qusb2_phy_probe().
 - fixed phy create and phy register ordering.
 - removed references to non-lkml links from commit message.
 - took care of other minor nits.
 - Fixed coccinelle warnings -
   'PTR_ERR applied after initialization to constant'
 - Addressed review comment, regarding qfprom access for tune2 param value.
   This driver is now based on qfprom patch[1] that allows byte access now.

 drivers/phy/Kconfig  |  10 +
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-qcom-qusb2.c | 540 +++
 3 files changed, 551 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e8eb7f225a88..0ed53d018b23 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -430,6 +430,16 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_QCOM_QUSB2
+   tristate "Qualcomm QUSB2 PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
+ controllers on Qualcomm chips. This driver supports the high-speed
+ PHY which is usually paired with either the ChipIdea or Synopsys DWC3
+ USB IPs on MSM SOCs.
+
 config PHY_QCOM_UFS
tristate "Qualcomm UFS PHY driver"
depends on OF && ARCH_QCOM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 65eb2f436a41..dad1682b80e3 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
 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_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
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
new file mode 100644
index ..ae7feae835fd
--- /dev/null
+++ b/drivers/phy/phy-qcom-qusb2.c
@@ -0,0 +1,540 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define QUSB2PHY_PLL_TEST  0x04
+#define CLK_REF_SELBIT(7)
+
+#define QUSB2PHY_PLL_TUNE  0x08
+#define QUSB2PHY_PLL_USER_CTL1 0x0c
+#define QUSB2PHY_PLL_USER_CTL2 0x10
+#define QUSB2PHY_PLL_AUTOPGM_CTL1  0x1c
+#define QUSB2PHY_PLL_PWR_CTRL  0x18
+
+#define QUSB2PHY_PLL_STATUS0x38
+#define PLL_LOCKED BIT(5)
+
+#define QUSB2PHY_PORT_TUNE1 0x80
+#define QUSB2PHY_PORT_TUNE2 0x84
+#define QUSB2PHY_PORT_TUNE3 0x88
+#define QUSB2PHY_PORT_TUNE4 0x8c
+#define QUSB2PHY_PORT_TUNE50x90
+#define QUSB2PHY_PORT_TEST20x9c
+
+#define QUSB2PHY_PORT_POWERDOWN0xb4
+#define CLAMP_N_EN BIT(5)
+#define FREEZIO_N  BIT(1)
+#define POWER_DOWN BIT(

[PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

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.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Tested-by: Srinivas Kandagatla <srinivas.kandaga...@linaro.org>
---

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Using readl_poll_timeout() to simplify pcs ready status polling.
   Also fixed the polling condition for pcs block ready status:
   'Common block ready status bit is set on phy init completion, while
   PCS block ready status bit (PHYSTATUS) is reset on phy init
   completion.'
 - Moved out the per-lane phy creation from probe() to separate
   function.
 - Registering pipe clock source as a fixed rate clock that comes
   out of the PLL block of QMP phy. These source clocks serve as
   parent to 'pipe_clks' that are requested by pcie or usb3 phys.
 - Using of_device_get_match_data() to get match data.
 - Fixed sparse warnings for 'static' and 'const'.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - Fixed missing mutex_unlock() calls in error cases, reported by
   Julia Lawall.
 - Selecting CONFIG_RESET_CONTROLLER when this driver is enabled.
 - Added a boolean property to check if the phy has individual lane
   reset available.
 - Took care or EPROBE_DEFER, dev_vdbg() and other minor nits.
 - Removed references to non-lkml links from commit message.
 - Moved to use separate iomem resources for each lanes.
   Tx, Rx and PCS offsets per lane can now come from dt bindings.

 drivers/phy/Kconfig|8 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-qcom-qmp.c | 1191 
 3 files changed, 1200 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qmp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 0ed53d018b23..54296397452c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -430,6 +430,14 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+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 dad1682b80e3..dbe7731bbca9 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,6 +50,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_QCOM_QUSB2)   += phy-qcom-qusb2.o
+obj-$(CONFIG_PHY_QCOM_QMP) += phy-qcom-qmp.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c
new file mode 100644
index ..09ab93575057
--- /dev/null
+++ b/drivers/phy/phy-qcom-qmp.c
@@ -0,0 +1,1191 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* QMP PHY QSERDES COM registers */
+#define QSERDES_COM_BG_TIMER   0x00c
+#define QSERDES_COM_SSC_EN_CENTER  0x010
+#define QSERDES_COM_SSC_ADJ_PER1   0x014
+#define QSERDES_COM_SSC_ADJ_PER2   0x018
+#define QSERDES_COM_SSC_PER1   0x01c
+#define QSERDES_COM_SSC_PER2   0x020
+#define QSERDES_COM_SSC_STEP_SIZE1 0x024
+#define QSERDES_COM_SSC_STEP_SIZE2 0x028
+#define QSERDES_COM_BIAS_EN_CLKBUFLR_EN  

[PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

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.

Signed-off-by: Vivek Gautam 
Tested-by: Srinivas Kandagatla 
---

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Using readl_poll_timeout() to simplify pcs ready status polling.
   Also fixed the polling condition for pcs block ready status:
   'Common block ready status bit is set on phy init completion, while
   PCS block ready status bit (PHYSTATUS) is reset on phy init
   completion.'
 - Moved out the per-lane phy creation from probe() to separate
   function.
 - Registering pipe clock source as a fixed rate clock that comes
   out of the PLL block of QMP phy. These source clocks serve as
   parent to 'pipe_clks' that are requested by pcie or usb3 phys.
 - Using of_device_get_match_data() to get match data.
 - Fixed sparse warnings for 'static' and 'const'.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - Fixed missing mutex_unlock() calls in error cases, reported by
   Julia Lawall.
 - Selecting CONFIG_RESET_CONTROLLER when this driver is enabled.
 - Added a boolean property to check if the phy has individual lane
   reset available.
 - Took care or EPROBE_DEFER, dev_vdbg() and other minor nits.
 - Removed references to non-lkml links from commit message.
 - Moved to use separate iomem resources for each lanes.
   Tx, Rx and PCS offsets per lane can now come from dt bindings.

 drivers/phy/Kconfig|8 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-qcom-qmp.c | 1191 
 3 files changed, 1200 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qmp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 0ed53d018b23..54296397452c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -430,6 +430,14 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+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 dad1682b80e3..dbe7731bbca9 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,6 +50,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_QCOM_QUSB2)   += phy-qcom-qusb2.o
+obj-$(CONFIG_PHY_QCOM_QMP) += phy-qcom-qmp.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c
new file mode 100644
index ..09ab93575057
--- /dev/null
+++ b/drivers/phy/phy-qcom-qmp.c
@@ -0,0 +1,1191 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* QMP PHY QSERDES COM registers */
+#define QSERDES_COM_BG_TIMER   0x00c
+#define QSERDES_COM_SSC_EN_CENTER  0x010
+#define QSERDES_COM_SSC_ADJ_PER1   0x014
+#define QSERDES_COM_SSC_ADJ_PER2   0x018
+#define QSERDES_COM_SSC_PER1   0x01c
+#define QSERDES_COM_SSC_PER2   0x020
+#define QSERDES_COM_SSC_STEP_SIZE1 0x024
+#define QSERDES_COM_SSC_STEP_SIZE2 0x028
+#define QSERDES_COM_BIAS_EN_CLKBUFLR_EN0x034
+#define QSERDES_COM_CLK_ENABLE10x0

[PATCH v3 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Rob Herring <r...@kernel.org>
---

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Using 'phy' for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
 - updated bindings to include mem resource as a list of
   offset - length pair for serdes block and for each lane.
 - added a new binding for 'lane-offsets' that contains offsets
   to tx, rx and pcs blocks from each lane base address.

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 71 ++
 1 file changed, 71 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

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 ..af9ada87a4e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,71 @@
+Qualcomm QMP PHY controller
+===
+
+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: list of offset and length pair of the PHY register sets.
+   at index 0: offset and length of register set for PHY common
+   serdes block.
+   from index 1 - N: offset and length of register set for each lane,
+ for N number of phy lanes (ports).
+ - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
+ - #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" for 19.2 MHz ref clk,
+   "pipe" 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" 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: phy@34000 {
+   compatible = "qcom,msm8996-qmp-pcie-phy";
+   reg = <0x034000 0x48f>,
+   <0x035000 0x5bf>,
+   <0x036000 0x5bf>,
+   <0x037000 0x5bf>;
+   /* tx, rx, pcs */
+   lane-offsets = <0x0 0x200 0x400>;
+   #phy-cells = <1>;
+
+   clocks = < GCC_PCIE_PHY_AUX_CLK>,
+   < GCC_PCIE_PHY_CFG_AHB_CLK>,
+   < GCC_PCIE_CLKREF_CLK>,
+   < GCC_PCIE_0_PIPE_CLK>,
+   < GCC_PCIE_1_PIPE_CLK>,
+   < GCC_PCIE_2_PIPE_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref",
+   "pipe0", "pipe1", "pipe2";
+
+   vdda-phy-supply = <_l28>;
+   vdda-pll-supply = <_l12>;
+
+   resets = < GCC_PCIE_PHY_BCR>,
+   < GCC_PCIE_PHY_COM_BCR>,
+   < GCC_PCIE_PHY_COM_NOCSR_BCR>,
+   < GCC_PCIE_0_PHY_BCR>,
+   < GCC_PCIE_1_PHY_BCR>,
+   < GCC_PCIE_2_PHY_BCR>;
+   reset-names = "phy", "common", "cfg",
+   "lane0", "lane1", "lane2";
+   };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam 
Acked-by: Rob Herring 
---

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Using 'phy' for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
 - updated bindings to include mem resource as a list of
   offset - length pair for serdes block and for each lane.
 - added a new binding for 'lane-offsets' that contains offsets
   to tx, rx and pcs blocks from each lane base address.

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 71 ++
 1 file changed, 71 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

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 ..af9ada87a4e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,71 @@
+Qualcomm QMP PHY controller
+===
+
+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: list of offset and length pair of the PHY register sets.
+   at index 0: offset and length of register set for PHY common
+   serdes block.
+   from index 1 - N: offset and length of register set for each lane,
+ for N number of phy lanes (ports).
+ - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
+ - #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" for 19.2 MHz ref clk,
+   "pipe" 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" 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: phy@34000 {
+   compatible = "qcom,msm8996-qmp-pcie-phy";
+   reg = <0x034000 0x48f>,
+   <0x035000 0x5bf>,
+   <0x036000 0x5bf>,
+   <0x037000 0x5bf>;
+   /* tx, rx, pcs */
+   lane-offsets = <0x0 0x200 0x400>;
+   #phy-cells = <1>;
+
+   clocks = < GCC_PCIE_PHY_AUX_CLK>,
+   < GCC_PCIE_PHY_CFG_AHB_CLK>,
+   < GCC_PCIE_CLKREF_CLK>,
+   < GCC_PCIE_0_PIPE_CLK>,
+   < GCC_PCIE_1_PIPE_CLK>,
+   < GCC_PCIE_2_PIPE_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref",
+   "pipe0", "pipe1", "pipe2";
+
+   vdda-phy-supply = <_l28>;
+   vdda-pll-supply = <_l12>;
+
+   resets = < GCC_PCIE_PHY_BCR>,
+   < GCC_PCIE_PHY_COM_BCR>,
+   < GCC_PCIE_PHY_COM_NOCSR_BCR>,
+   < GCC_PCIE_0_PHY_BCR>,
+   < GCC_PCIE_1_PHY_BCR>,
+   < GCC_PCIE_2_PHY_BCR>;
+   reset-names = "phy", "common", "cfg",
+   "lane0", "lane1", "lane2";
+   };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH -next] phy: rockchip-typec: fix non static symbol warnings

[Vivek Gautam]

On Wed, Sep 21, 2016 at 8:35 PM, Wei Yongjun  wrote:
> From: Wei Yongjun 
>
> Fixes the following sparse warnings:
>
> drivers/phy/phy-rockchip-typec.c:295:16: warning:
>  symbol 'usb3_pll_cfg' was not declared. Should it be static?
> drivers/phy/phy-rockchip-typec.c:312:16: warning:
>  symbol 'dp_pll_cfg' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/phy/phy-rockchip-typec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/phy-rockchip-typec.c 
> b/drivers/phy/phy-rockchip-typec.c
> index 7cfb0f8..555604c 100644
> --- a/drivers/phy/phy-rockchip-typec.c
> +++ b/drivers/phy/phy-rockchip-typec.c
> @@ -292,7 +292,7 @@ struct phy_reg {
> u32 addr;
>  };
>
> -struct phy_reg usb3_pll_cfg[] = {
> +static struct phy_reg usb3_pll_cfg[] = {

const as well ?

> { 0xf0, CMN_PLL0_VCOCAL_INIT },
> { 0x18, CMN_PLL0_VCOCAL_ITER },
> { 0xd0, CMN_PLL0_INTDIV },
> @@ -309,7 +309,7 @@ struct phy_reg usb3_pll_cfg[] = {
> { 0x8,  CMN_DIAG_PLL0_LF_PROG },
>  };
>
> -struct phy_reg dp_pll_cfg[] = {
> +static struct phy_reg dp_pll_cfg[] = {

const ?
[..]


Thanks
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH -next] phy: rockchip-typec: fix non static symbol warnings

[Vivek Gautam]

On Wed, Sep 21, 2016 at 8:35 PM, Wei Yongjun  wrote:
> From: Wei Yongjun 
>
> Fixes the following sparse warnings:
>
> drivers/phy/phy-rockchip-typec.c:295:16: warning:
>  symbol 'usb3_pll_cfg' was not declared. Should it be static?
> drivers/phy/phy-rockchip-typec.c:312:16: warning:
>  symbol 'dp_pll_cfg' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/phy/phy-rockchip-typec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/phy-rockchip-typec.c 
> b/drivers/phy/phy-rockchip-typec.c
> index 7cfb0f8..555604c 100644
> --- a/drivers/phy/phy-rockchip-typec.c
> +++ b/drivers/phy/phy-rockchip-typec.c
> @@ -292,7 +292,7 @@ struct phy_reg {
> u32 addr;
>  };
>
> -struct phy_reg usb3_pll_cfg[] = {
> +static struct phy_reg usb3_pll_cfg[] = {

const as well ?

> { 0xf0, CMN_PLL0_VCOCAL_INIT },
> { 0x18, CMN_PLL0_VCOCAL_ITER },
> { 0xd0, CMN_PLL0_INTDIV },
> @@ -309,7 +309,7 @@ struct phy_reg usb3_pll_cfg[] = {
> { 0x8,  CMN_DIAG_PLL0_LF_PROG },
>  };
>
> -struct phy_reg dp_pll_cfg[] = {
> +static struct phy_reg dp_pll_cfg[] = {

const ?
[..]


Thanks
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Hi,

On Tue, Nov 29, 2016 at 6:05 AM, Stephen Boyd <sb...@codeaurora.org> wrote:

Thanks for a thorough review. Please find my comments inline.

> On 11/22, Vivek Gautam wrote:
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index f1dcec1..8970d9e 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -430,6 +430,15 @@ config PHY_STIH407_USB
>> Enable this support to enable the picoPHY device used by USB2
>> and USB3 controllers on STMicroelectronics STiH407 SoC families.
>>
>> +config PHY_QCOM_QMP
>> + tristate "Qualcomm QMP PHY Driver"
>> + depends on OF && (ARCH_QCOM || COMPILE_TEST)
>> + select GENERIC_PHY
>> + select RESET_CONTROLLER
>
> Again, probably should be dropped as we're not providing resets
> here, just using them.

Sure, will drop in v3.

>
>> diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c
>> new file mode 100644
>> index 000..f85289e
>> --- /dev/null
>> +++ b/drivers/phy/phy-qcom-qmp.c
>> @@ -0,0 +1,1141 @@
>> +/*
>> + * 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 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
> [...]
>> +
>> +/* set of registers with offsets different per-PHY */
>> +enum qphy_reg_layout {
>> + /* Common block control registers */
>> + QPHY_COM_SW_RESET,
>> + QPHY_COM_POWER_DOWN_CONTROL,
>> + QPHY_COM_START_CONTROL,
>> + QPHY_COM_PCS_READY_STATUS,
>> + /* PCS registers */
>> + QPHY_PLL_LOCK_CHK_DLY_TIME,
>> + QPHY_FLL_CNTRL1,
>> + QPHY_FLL_CNTRL2,
>> + QPHY_FLL_CNT_VAL_L,
>> + QPHY_FLL_CNT_VAL_H_TOL,
>> + QPHY_FLL_MAN_CODE,
>> + QPHY_PCS_READY_STATUS,
>> +};
>> +
>> +unsigned int pciephy_regs_layout[] = {
>
> static? const?

Will take care of these in v3.
[...]

>> +
>> +/**
>> + * struct qmp_phy_init_cfg:- per-PHY init config.
>
> The colon and dash can't be right. One is kernel-doc, but of
> course there aren't any other member descriptions.

Right, will convert this to a one-line comment.

>
>> + */
>> +struct qmp_phy_init_cfg {
>> + /* phy-type - PCIE/UFS/USB */
>> + unsigned int type;
>> + /* number of lanes provided by phy */
>> + int nlanes;
>> +
>> + /* Initialization sequence for PHY blocks - Serdes, tx, rx, pcs */
>> + struct qmp_phy_init_tbl *phy_init_serdes_tbl;
>> + int phy_init_serdes_tbl_sz;
>> + struct qmp_phy_init_tbl *phy_init_tx_tbl;
>> + int phy_init_tx_tbl_sz;
>> + struct qmp_phy_init_tbl *phy_init_rx_tbl;
>> + int phy_init_rx_tbl_sz;
>> + struct qmp_phy_init_tbl *phy_init_pcs_tbl;
>> + int phy_init_pcs_tbl_sz;
>
> _sz makes it sound like bytes, perhaps _num instead.

sure.

>
>> +
>> + /* array of registers with different offsets */
>> + unsigned int *regs;
>
> const?

taking care of these in v3.

>
>> +
>> + unsigned int mask_start_ctrl;
>> + unsigned int mask_pwr_dn_ctrl;
>> + /* true, if PHY has a separate PHY_COM_CNTRL block */
>> + bool has_phy_com_ctrl;
>> + /* true, if PHY has a reset for individual lanes */
>> + bool has_lane_rst;
>> +};
>> +
>> +/**
>> + * struct qmp_phy_desc:- per-lane phy-descriptor.
>
> Also kernel-doc requests full stop is left out on one line
> descriptions.

sure, will remove it from here and from other places where a full-stop
is not required.

>
>> + *
>> + * @phy: pointer to generic phy
>> + * @tx: pointer to iomapped memory space for PHY's tx
>> + * @rx: pointer to iomapped memory space for PHY's rx
>> + * @pcs: pointer to iomapped memory space for PHY's pcs
>> + * @pipe_clk: pointer to pip

Re: [PATCH v2 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Hi,

On Tue, Nov 29, 2016 at 6:05 AM, Stephen Boyd  wrote:

Thanks for a thorough review. Please find my comments inline.

> On 11/22, Vivek Gautam wrote:
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index f1dcec1..8970d9e 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -430,6 +430,15 @@ config PHY_STIH407_USB
>> Enable this support to enable the picoPHY device used by USB2
>> and USB3 controllers on STMicroelectronics STiH407 SoC families.
>>
>> +config PHY_QCOM_QMP
>> + tristate "Qualcomm QMP PHY Driver"
>> + depends on OF && (ARCH_QCOM || COMPILE_TEST)
>> + select GENERIC_PHY
>> + select RESET_CONTROLLER
>
> Again, probably should be dropped as we're not providing resets
> here, just using them.

Sure, will drop in v3.

>
>> diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c
>> new file mode 100644
>> index 000..f85289e
>> --- /dev/null
>> +++ b/drivers/phy/phy-qcom-qmp.c
>> @@ -0,0 +1,1141 @@
>> +/*
>> + * 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 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
> [...]
>> +
>> +/* set of registers with offsets different per-PHY */
>> +enum qphy_reg_layout {
>> + /* Common block control registers */
>> + QPHY_COM_SW_RESET,
>> + QPHY_COM_POWER_DOWN_CONTROL,
>> + QPHY_COM_START_CONTROL,
>> + QPHY_COM_PCS_READY_STATUS,
>> + /* PCS registers */
>> + QPHY_PLL_LOCK_CHK_DLY_TIME,
>> + QPHY_FLL_CNTRL1,
>> + QPHY_FLL_CNTRL2,
>> + QPHY_FLL_CNT_VAL_L,
>> + QPHY_FLL_CNT_VAL_H_TOL,
>> + QPHY_FLL_MAN_CODE,
>> + QPHY_PCS_READY_STATUS,
>> +};
>> +
>> +unsigned int pciephy_regs_layout[] = {
>
> static? const?

Will take care of these in v3.
[...]

>> +
>> +/**
>> + * struct qmp_phy_init_cfg:- per-PHY init config.
>
> The colon and dash can't be right. One is kernel-doc, but of
> course there aren't any other member descriptions.

Right, will convert this to a one-line comment.

>
>> + */
>> +struct qmp_phy_init_cfg {
>> + /* phy-type - PCIE/UFS/USB */
>> + unsigned int type;
>> + /* number of lanes provided by phy */
>> + int nlanes;
>> +
>> + /* Initialization sequence for PHY blocks - Serdes, tx, rx, pcs */
>> + struct qmp_phy_init_tbl *phy_init_serdes_tbl;
>> + int phy_init_serdes_tbl_sz;
>> + struct qmp_phy_init_tbl *phy_init_tx_tbl;
>> + int phy_init_tx_tbl_sz;
>> + struct qmp_phy_init_tbl *phy_init_rx_tbl;
>> + int phy_init_rx_tbl_sz;
>> + struct qmp_phy_init_tbl *phy_init_pcs_tbl;
>> + int phy_init_pcs_tbl_sz;
>
> _sz makes it sound like bytes, perhaps _num instead.

sure.

>
>> +
>> + /* array of registers with different offsets */
>> + unsigned int *regs;
>
> const?

taking care of these in v3.

>
>> +
>> + unsigned int mask_start_ctrl;
>> + unsigned int mask_pwr_dn_ctrl;
>> + /* true, if PHY has a separate PHY_COM_CNTRL block */
>> + bool has_phy_com_ctrl;
>> + /* true, if PHY has a reset for individual lanes */
>> + bool has_lane_rst;
>> +};
>> +
>> +/**
>> + * struct qmp_phy_desc:- per-lane phy-descriptor.
>
> Also kernel-doc requests full stop is left out on one line
> descriptions.

sure, will remove it from here and from other places where a full-stop
is not required.

>
>> + *
>> + * @phy: pointer to generic phy
>> + * @tx: pointer to iomapped memory space for PHY's tx
>> + * @rx: pointer to iomapped memory space for PHY's rx
>> + * @pcs: pointer to iomapped memory space for PHY's pcs
>> + * @pipe_clk: pointer to pipe lock
>> + * @index: lane index

Re: [PATCH] nvmem: core: Allow ignoring length when reading a cell

[Vivek Gautam]

On Tue, Dec 20, 2016 at 3:17 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> On 12/19, Vivek Gautam wrote:
>> nvmem_cell_read() API fills in the argument 'len' with
>> the number of bytes read from the cell. Many users don't
>> care about this length value. So allow users to pass a
>> NULL pointer to this len field.
>>
>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>> ---
>
> Reviewed-by: Stephen Boyd <sb...@codeaurora.org>

Thanks Stephen.


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] nvmem: core: Allow ignoring length when reading a cell

[Vivek Gautam]

On Tue, Dec 20, 2016 at 3:17 AM, Stephen Boyd  wrote:
> On 12/19, Vivek Gautam wrote:
>> nvmem_cell_read() API fills in the argument 'len' with
>> the number of bytes read from the cell. Many users don't
>> care about this length value. So allow users to pass a
>> NULL pointer to this len field.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>
> Reviewed-by: Stephen Boyd 

Thanks Stephen.


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] nvmem: core: Allow ignoring length when reading a cell

[Vivek Gautam]

nvmem_cell_read() API fills in the argument 'len' with
the number of bytes read from the cell. Many users don't
care about this length value. So allow users to pass a
NULL pointer to this len field.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Based on torvalds's master branch.
 - Tested against 'next-20161219' tag on db410c (apq8016) target
   for thermal sensors.

 drivers/nvmem/core.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 965911d..4c38842 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -970,7 +970,8 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem,
if (cell->bit_offset || cell->nbits)
nvmem_shift_read_buffer_in_place(cell, buf);
 
-   *len = cell->bytes;
+   if (len)
+   *len = cell->bytes;
 
return 0;
 }
@@ -979,7 +980,8 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem,
  * nvmem_cell_read() - Read a given nvmem cell
  *
  * @cell: nvmem cell to be read.
- * @len: pointer to length of cell which will be populated on successful read.
+ * @len: pointer to length of cell which will be populated on successful read;
+ *  can be NULL.
  *
  * Return: ERR_PTR() on error or a valid pointer to a char * buffer on success.
  * The buffer should be freed by the consumer with a kfree().
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] nvmem: core: Allow ignoring length when reading a cell

[Vivek Gautam]

nvmem_cell_read() API fills in the argument 'len' with
the number of bytes read from the cell. Many users don't
care about this length value. So allow users to pass a
NULL pointer to this len field.

Signed-off-by: Vivek Gautam 
---

Based on torvalds's master branch.
 - Tested against 'next-20161219' tag on db410c (apq8016) target
   for thermal sensors.

 drivers/nvmem/core.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 965911d..4c38842 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -970,7 +970,8 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem,
if (cell->bit_offset || cell->nbits)
nvmem_shift_read_buffer_in_place(cell, buf);
 
-   *len = cell->bytes;
+   if (len)
+   *len = cell->bytes;
 
return 0;
 }
@@ -979,7 +980,8 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem,
  * nvmem_cell_read() - Read a given nvmem cell
  *
  * @cell: nvmem cell to be read.
- * @len: pointer to length of cell which will be populated on successful read.
+ * @len: pointer to length of cell which will be populated on successful read;
+ *  can be NULL.
  *
  * Return: ERR_PTR() on error or a valid pointer to a char * buffer on success.
  * The buffer should be freed by the consumer with a kfree().
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Hi Stephen,

On Tue, Nov 29, 2016 at 4:49 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> On 11/22, Vivek Gautam wrote:
>> Qualcomm chipsets have QMP phy controller that provides
>> support to a number of controller, viz. PCIe, UFS, and USB.
>> Adding dt binding information for the same.
>>
>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>> Acked-by: Rob Herring <r...@kernel.org>
>> ---
>>
>> Changes since v1:
>>  - New patch, forked out of the original driver patch:
>>"phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
>>  - updated bindings to include mem resource as a list of
>>offset - length pair for serdes block and for each lane.
>>  - added a new binding for 'lane-offsets' that contains offsets
>>to tx, rx and pcs blocks from each lane base address.
>>
>>  .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 74 
>> ++
>>  1 file changed, 74 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>>
>> 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 000..ffb173b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> @@ -0,0 +1,74 @@
>> +Qualcomm QMP PHY
>> +
>> +
>> +QMP phy controller supports physical layer functionality for a number of
>> +controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.

[...]

>> +Example:
>> + pcie_phy: pciephy@34000 {
>> + compatible = "qcom,msm8996-qmp-pcie-phy";
>> + reg = <0x034000 0x48f>,
>> + <0x035000 0x5bf>,
>> + <0x036000 0x5bf>,
>> + <0x037000 0x5bf>;
>> + /* tx, rx, pcs */
>> + lane-offsets = <0x0 0x200 0x400>;
>> + #phy-cells = <1>;
>> +
>> + clocks = < GCC_PCIE_PHY_AUX_CLK>,
>> + < GCC_PCIE_PHY_CFG_AHB_CLK>,
>> + < MSM8996_RPM_SMD_LN_BB_CLK>,
>> + < GCC_PCIE_CLKREF_CLK>,
>> + < GCC_PCIE_0_PIPE_CLK>,
>> + < GCC_PCIE_1_PIPE_CLK>,
>> + < GCC_PCIE_2_PIPE_CLK>;
>> + clock-names = "aux", "cfg_ahb",
>> + "ref_clk_src", "ref_clk",
>
> Does MSM8996_RPM_SMD_LN_BB_CLK supply the clock source for
> GCC_PCIE_CLKREF_CLK? Did we mess up the parent/child relationship
> in the GCC driver? We may want to fix that so that this node
> only references clocks that actually go into the device, instead
> of clock parents.

The clock documentations do show that the RPM_SMD_LN_BB_CLK provides
the 19.2 MHz phy clocks via pad. So, like you rightly said we may have to
fix the parents for phy reference clocks for difference phy controllers on 8996.

I will gather some more info on this to discuss it further.


Thanks
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Hi Stephen,

On Tue, Nov 29, 2016 at 4:49 AM, Stephen Boyd  wrote:
> On 11/22, Vivek Gautam wrote:
>> Qualcomm chipsets have QMP phy controller that provides
>> support to a number of controller, viz. PCIe, UFS, and USB.
>> Adding dt binding information for the same.
>>
>> Signed-off-by: Vivek Gautam 
>> Acked-by: Rob Herring 
>> ---
>>
>> Changes since v1:
>>  - New patch, forked out of the original driver patch:
>>"phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
>>  - updated bindings to include mem resource as a list of
>>offset - length pair for serdes block and for each lane.
>>  - added a new binding for 'lane-offsets' that contains offsets
>>to tx, rx and pcs blocks from each lane base address.
>>
>>  .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 74 
>> ++
>>  1 file changed, 74 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>>
>> 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 000..ffb173b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> @@ -0,0 +1,74 @@
>> +Qualcomm QMP PHY
>> +
>> +
>> +QMP phy controller supports physical layer functionality for a number of
>> +controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.

[...]

>> +Example:
>> + pcie_phy: pciephy@34000 {
>> + compatible = "qcom,msm8996-qmp-pcie-phy";
>> + reg = <0x034000 0x48f>,
>> + <0x035000 0x5bf>,
>> + <0x036000 0x5bf>,
>> + <0x037000 0x5bf>;
>> + /* tx, rx, pcs */
>> + lane-offsets = <0x0 0x200 0x400>;
>> + #phy-cells = <1>;
>> +
>> + clocks = < GCC_PCIE_PHY_AUX_CLK>,
>> + < GCC_PCIE_PHY_CFG_AHB_CLK>,
>> + < MSM8996_RPM_SMD_LN_BB_CLK>,
>> + < GCC_PCIE_CLKREF_CLK>,
>> + < GCC_PCIE_0_PIPE_CLK>,
>> + < GCC_PCIE_1_PIPE_CLK>,
>> + < GCC_PCIE_2_PIPE_CLK>;
>> + clock-names = "aux", "cfg_ahb",
>> + "ref_clk_src", "ref_clk",
>
> Does MSM8996_RPM_SMD_LN_BB_CLK supply the clock source for
> GCC_PCIE_CLKREF_CLK? Did we mess up the parent/child relationship
> in the GCC driver? We may want to fix that so that this node
> only references clocks that actually go into the device, instead
> of clock parents.

The clock documentations do show that the RPM_SMD_LN_BB_CLK provides
the 19.2 MHz phy clocks via pad. So, like you rightly said we may have to
fix the parents for phy reference clocks for difference phy controllers on 8996.

I will gather some more info on this to discuss it further.


Thanks
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Hi Stephen,

On Tue, Nov 29, 2016 at 4:25 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> On 11/22, Vivek Gautam wrote:
>> 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 000..ffb173b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> @@ -0,0 +1,74 @@
>> +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: list of offset and length pair of the PHY register sets.
>> + at index 0: offset and length of register set for PHY common
>> + serdes block.
>> + from index 1 - N: offset and length of register set for each lane,
>> +   for N number of phy lanes (ports).
>> + - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
>> + - #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,
>
> We typically leave "clk" out of clk names because it's redundant.
>
>> + "pipe" for pipe clock specific to
>> + each port/lane (Optional).
>
> The pipe clocks are orphaned right now. We should add an output
> clock from the phy to go into the controller and back into the
> phy if I recall correctly. The phy should be a clock provider
> itself so it can output the pipe clock source into GCC and back
> into the phy and controller.

You are correct. The pipe clocks come out of PHY controllers and
go back to the gcc that gates them finally.

I will register the phy drivers as clock providers so that gcc can make
reference to it.


Best Regards
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Hi Stephen,

On Tue, Nov 29, 2016 at 4:25 AM, Stephen Boyd  wrote:
> On 11/22, Vivek Gautam wrote:
>> 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 000..ffb173b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> @@ -0,0 +1,74 @@
>> +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: list of offset and length pair of the PHY register sets.
>> + at index 0: offset and length of register set for PHY common
>> + serdes block.
>> + from index 1 - N: offset and length of register set for each lane,
>> +   for N number of phy lanes (ports).
>> + - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
>> + - #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,
>
> We typically leave "clk" out of clk names because it's redundant.
>
>> + "pipe" for pipe clock specific to
>> + each port/lane (Optional).
>
> The pipe clocks are orphaned right now. We should add an output
> clock from the phy to go into the controller and back into the
> phy if I recall correctly. The phy should be a clock provider
> itself so it can output the pipe clock source into GCC and back
> into the phy and controller.

You are correct. The pipe clocks come out of PHY controllers and
go back to the gcc that gates them finally.

I will register the phy drivers as clock providers so that gcc can make
reference to it.


Best Regards
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

On Sat, Dec 3, 2016 at 12:17 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> On 12/01/2016 12:42 AM, Vivek Gautam wrote:
>> On Tue, Nov 29, 2016 at 4:44 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
>>> On 11/22, Vivek Gautam wrote:
>>>> + }
>>>> +
>>>> + /*
>>>> +  * we need to read only one byte here, since the required
>>>> +  * parameter value fits in one nibble
>>>> +  */
>>>> + val = (u8 *)nvmem_cell_read(cell, );
>>> Shouldn't need the cast here. Also it would be nice if
>>> nvmem_cell_read() didn't require a second argument if we don't
>>> care for it. We should update the API to allow NULL there.
>> Will remove the u8 pointer cast.
>>
>> Correct, it makes sense to allow the length pointer to be passed as NULL.
>> We don't care about this length. Will update the nvmem API, to allow this.
>>
>> Also, we should add a check for 'cell' as well. This pointer can be
>> NULL, and the first thing that  nvmem_cell_read does is - deference
>> the pointer 'cell'
>
> It would be pretty stupid to read a cell and pass NULL as the first
> argument. I imagine things would blow up there like we want and we would
> see a nice big stacktrace.

Right, reading a 'NULL' cell doesn't make a sense at all.

>>>> + } else {
>>>> + reset_val |= CLK_REF_SEL;
>>>> + }
>>>> +
>>>> + writel_relaxed(reset_val, qphy->base + QUSB2PHY_PLL_TEST);
>>>> +
>>>> + /* Make sure that above write is completed to get PLL source clock */
>>>> + wmb();
>>>> +
>>>> + /* Required to get PHY PLL lock successfully */
>>>> + usleep_range(100, 110);
>>>> +
>>>> + if (!(readb_relaxed(qphy->base + QUSB2PHY_PLL_STATUS) &
>>>> + PLL_LOCKED)) {
>>>> + dev_err(>dev, "QUSB PHY PLL LOCK fails:%x\n",
>>>> + readb_relaxed(qphy->base + QUSB2PHY_PLL_STATUS));
>>> Would be pretty funny if this was locked now when the error
>>> printk runs. Are there other bits in there that are helpful?
>> This is the only bit that's there to check the PLL locking status.
>> Should we rather poll ?
>>
>
> I'm just saying that the printk may have the "correct" status but the
> check would have failed earlier making the printk confusing. Perhaps
> just save the register value from the first read and print it instead of
> reading it again? Polling would probably be a better design anyway?
> Hopefully the status bit isn't toggling back and forth during those
> 100-100us though, which may be the case here and that would explain why
> it's not a polling design.

Okay, will save the register value.
Will also stick to just checking the status after the delay, like we have in
downstream kernel.


Regards
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

On Sat, Dec 3, 2016 at 12:17 AM, Stephen Boyd  wrote:
> On 12/01/2016 12:42 AM, Vivek Gautam wrote:
>> On Tue, Nov 29, 2016 at 4:44 AM, Stephen Boyd  wrote:
>>> On 11/22, Vivek Gautam wrote:
>>>> + }
>>>> +
>>>> + /*
>>>> +  * we need to read only one byte here, since the required
>>>> +  * parameter value fits in one nibble
>>>> +  */
>>>> + val = (u8 *)nvmem_cell_read(cell, );
>>> Shouldn't need the cast here. Also it would be nice if
>>> nvmem_cell_read() didn't require a second argument if we don't
>>> care for it. We should update the API to allow NULL there.
>> Will remove the u8 pointer cast.
>>
>> Correct, it makes sense to allow the length pointer to be passed as NULL.
>> We don't care about this length. Will update the nvmem API, to allow this.
>>
>> Also, we should add a check for 'cell' as well. This pointer can be
>> NULL, and the first thing that  nvmem_cell_read does is - deference
>> the pointer 'cell'
>
> It would be pretty stupid to read a cell and pass NULL as the first
> argument. I imagine things would blow up there like we want and we would
> see a nice big stacktrace.

Right, reading a 'NULL' cell doesn't make a sense at all.

>>>> + } else {
>>>> + reset_val |= CLK_REF_SEL;
>>>> + }
>>>> +
>>>> + writel_relaxed(reset_val, qphy->base + QUSB2PHY_PLL_TEST);
>>>> +
>>>> + /* Make sure that above write is completed to get PLL source clock */
>>>> + wmb();
>>>> +
>>>> + /* Required to get PHY PLL lock successfully */
>>>> + usleep_range(100, 110);
>>>> +
>>>> + if (!(readb_relaxed(qphy->base + QUSB2PHY_PLL_STATUS) &
>>>> + PLL_LOCKED)) {
>>>> + dev_err(>dev, "QUSB PHY PLL LOCK fails:%x\n",
>>>> + readb_relaxed(qphy->base + QUSB2PHY_PLL_STATUS));
>>> Would be pretty funny if this was locked now when the error
>>> printk runs. Are there other bits in there that are helpful?
>> This is the only bit that's there to check the PLL locking status.
>> Should we rather poll ?
>>
>
> I'm just saying that the printk may have the "correct" status but the
> check would have failed earlier making the printk confusing. Perhaps
> just save the register value from the first read and print it instead of
> reading it again? Polling would probably be a better design anyway?
> Hopefully the status bit isn't toggling back and forth during those
> 100-100us though, which may be the case here and that would explain why
> it's not a polling design.

Okay, will save the register value.
Will also stick to just checking the status after the delay, like we have in
downstream kernel.


Regards
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

Hi Stephen,


On Tue, Nov 29, 2016 at 4:44 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> On 11/22, Vivek Gautam wrote:
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index e8eb7f2..f1dcec1 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -430,6 +430,17 @@ config PHY_STIH407_USB
>> Enable this support to enable the picoPHY device used by USB2
>> and USB3 controllers on STMicroelectronics STiH407 SoC families.
>>
>> +config PHY_QCOM_QUSB2
>> + tristate "Qualcomm QUSB2 PHY Driver"
>> + depends on OF && (ARCH_QCOM || COMPILE_TEST)
>> + select GENERIC_PHY
>> + select RESET_CONTROLLER
>
> This shouldn't be necessary. We only need to select it if we're
> providing resets.

Ok, will drop this.

>
>> + help
>> +   Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
>> +   controllers on Qualcomm chips. This driver supports the high-speed
>> +   PHY which is usually paired with either the ChipIdea or Synopsys DWC3
>> +   USB IPs on MSM SOCs.
>> +
>>  config PHY_QCOM_UFS
>>   tristate "Qualcomm UFS PHY driver"
>>   depends on OF && ARCH_QCOM
>> diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
>> new file mode 100644
>> index 000..d3f9657
>> --- /dev/null
>> +++ b/drivers/phy/phy-qcom-qusb2.c
>> @@ -0,0 +1,549 @@
>> +/*
>> + * 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 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define QUSB2PHY_PLL_TEST0x04
>> +#define CLK_REF_SEL  BIT(7)
>> +
>> +#define QUSB2PHY_PLL_TUNE0x08
>> +#define QUSB2PHY_PLL_USER_CTL1   0x0c
>> +#define QUSB2PHY_PLL_USER_CTL2   0x10
>> +#define QUSB2PHY_PLL_AUTOPGM_CTL10x1c
>> +#define QUSB2PHY_PLL_PWR_CTRL0x18
>> +
>> +#define QUSB2PHY_PLL_STATUS  0x38
>> +#define PLL_LOCKED   BIT(5)
>> +
>> +#define QUSB2PHY_PORT_TUNE1 0x80
>> +#define QUSB2PHY_PORT_TUNE2 0x84
>> +#define QUSB2PHY_PORT_TUNE3 0x88
>> +#define QUSB2PHY_PORT_TUNE4 0x8C
>> +#define QUSB2PHY_PORT_TUNE5  0x90
>> +#define QUSB2PHY_PORT_TEST2  0x9c
>
> Please use lowercase or uppercase consistently (I'd prefer
> lowercase).

Sure, lowercase.

>
>> +
>> +#define QUSB2PHY_PORT_POWERDOWN  0xB4
>> +#define CLAMP_N_EN   BIT(5)
>> +#define FREEZIO_NBIT(1)
>> +#define POWER_DOWN   BIT(0)
>> +
>> +#define QUSB2PHY_REFCLK_ENABLE   BIT(0)
>> +
>> +#define PHY_CLK_SCHEME_SEL   BIT(0)
>> +
>> +struct qusb2_phy_init_tbl {
>> + unsigned int reg_offset;
>> + unsigned int cfg_val;
>> +};
>> +#define QCOM_QUSB2_PHY_INIT_CFG(reg, val) \
>> + {   \
>> + .reg_offset = reg,  \
>> + .cfg_val = val, \
>> + }
>> +
>> +static struct qusb2_phy_init_tbl msm8996_phy_init_tbl[] = {
>
> const?

argh! shouldn't have missed these 'const' and 'static' assignments.
will update for all instances.

>
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE1, 0xF8),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE2, 0xB3),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE3, 0x83),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE4, 0xC0),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_TUNE, 0x30),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL1, 0x79),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL2, 0x21),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_

Re: [PATCH v2 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

Hi Stephen,


On Tue, Nov 29, 2016 at 4:44 AM, Stephen Boyd  wrote:
> On 11/22, Vivek Gautam wrote:
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index e8eb7f2..f1dcec1 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -430,6 +430,17 @@ config PHY_STIH407_USB
>> Enable this support to enable the picoPHY device used by USB2
>> and USB3 controllers on STMicroelectronics STiH407 SoC families.
>>
>> +config PHY_QCOM_QUSB2
>> + tristate "Qualcomm QUSB2 PHY Driver"
>> + depends on OF && (ARCH_QCOM || COMPILE_TEST)
>> + select GENERIC_PHY
>> + select RESET_CONTROLLER
>
> This shouldn't be necessary. We only need to select it if we're
> providing resets.

Ok, will drop this.

>
>> + help
>> +   Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
>> +   controllers on Qualcomm chips. This driver supports the high-speed
>> +   PHY which is usually paired with either the ChipIdea or Synopsys DWC3
>> +   USB IPs on MSM SOCs.
>> +
>>  config PHY_QCOM_UFS
>>   tristate "Qualcomm UFS PHY driver"
>>   depends on OF && ARCH_QCOM
>> diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
>> new file mode 100644
>> index 000..d3f9657
>> --- /dev/null
>> +++ b/drivers/phy/phy-qcom-qusb2.c
>> @@ -0,0 +1,549 @@
>> +/*
>> + * 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 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define QUSB2PHY_PLL_TEST0x04
>> +#define CLK_REF_SEL  BIT(7)
>> +
>> +#define QUSB2PHY_PLL_TUNE0x08
>> +#define QUSB2PHY_PLL_USER_CTL1   0x0c
>> +#define QUSB2PHY_PLL_USER_CTL2   0x10
>> +#define QUSB2PHY_PLL_AUTOPGM_CTL10x1c
>> +#define QUSB2PHY_PLL_PWR_CTRL0x18
>> +
>> +#define QUSB2PHY_PLL_STATUS  0x38
>> +#define PLL_LOCKED   BIT(5)
>> +
>> +#define QUSB2PHY_PORT_TUNE1 0x80
>> +#define QUSB2PHY_PORT_TUNE2 0x84
>> +#define QUSB2PHY_PORT_TUNE3 0x88
>> +#define QUSB2PHY_PORT_TUNE4 0x8C
>> +#define QUSB2PHY_PORT_TUNE5  0x90
>> +#define QUSB2PHY_PORT_TEST2  0x9c
>
> Please use lowercase or uppercase consistently (I'd prefer
> lowercase).

Sure, lowercase.

>
>> +
>> +#define QUSB2PHY_PORT_POWERDOWN  0xB4
>> +#define CLAMP_N_EN   BIT(5)
>> +#define FREEZIO_NBIT(1)
>> +#define POWER_DOWN   BIT(0)
>> +
>> +#define QUSB2PHY_REFCLK_ENABLE   BIT(0)
>> +
>> +#define PHY_CLK_SCHEME_SEL   BIT(0)
>> +
>> +struct qusb2_phy_init_tbl {
>> + unsigned int reg_offset;
>> + unsigned int cfg_val;
>> +};
>> +#define QCOM_QUSB2_PHY_INIT_CFG(reg, val) \
>> + {   \
>> + .reg_offset = reg,  \
>> + .cfg_val = val, \
>> + }
>> +
>> +static struct qusb2_phy_init_tbl msm8996_phy_init_tbl[] = {
>
> const?

argh! shouldn't have missed these 'const' and 'static' assignments.
will update for all instances.

>
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE1, 0xF8),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE2, 0xB3),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE3, 0x83),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE4, 0xC0),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_TUNE, 0x30),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL1, 0x79),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL2, 0x21),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TEST2, 0x14),
>> + QCOM_