Re: [PATCH v5 1/5] PCI: designware: ensure ATU is enabled before IO/conf space accesses

2016-01-04 Thread Stanimir Varbanov
On 12/18/2015 04:41 PM, Pratyush Anand wrote:
> On Fri, Dec 18, 2015 at 6:08 PM, Stanimir Varbanov
>  wrote:
>> There is no guarantees that enabling ATU will hit the hardware
>> immediately, and subsequent accesses to configuration / IO spaces
>> are reliable. So fixing this by read back PCIE_ATU_CR2 register
>> just after writing.
>>
>> Without such a fix the PCI device enumeration during kernel boot
>> is not reliable, and reading configuration space for particular
>> PCI device on the bus returns zero aka no device.
>>
>> Signed-off-by: Stanimir Varbanov 
> 
> Acked-by: Pratyush Anand 

Bjorn, Do you want to resend the whole patchset with collected acks and
tested tags?


-- 
regards,
Stan
--
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


[PATCH v5 3/5] PCI: qcom: Add Qualcomm PCIe controller driver

2015-12-18 Thread Stanimir Varbanov
From: Stanimir Varbanov 

The PCIe driver reuse the Designware common code for host
and MSI initialization, and also program the Qualcomm
application specific registers.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Stanimir Varbanov 
---
 MAINTAINERS  |7 +
 drivers/pci/host/Kconfig |   10 +
 drivers/pci/host/Makefile|1 +
 drivers/pci/host/pcie-qcom.c |  617 ++
 4 files changed, 635 insertions(+)
 create mode 100644 drivers/pci/host/pcie-qcom.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 38df53f828e1..7de5d2597e2b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8247,6 +8247,13 @@ S:   Maintained
 F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F: drivers/pci/host/pcie-hisi.c
 
+PCIE DRIVER FOR QUALCOMM MSM
+M: Stanimir Varbanov 
+L: linux-...@vger.kernel.org
+L: linux-arm-msm@vger.kernel.org
+S: Maintained
+F: drivers/pci/host/*qcom*
+
 PCMCIA SUBSYSTEM
 P: Linux PCMCIA Team
 L: linux-pcm...@lists.infradead.org
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index f131ba947dc6..64d33ba3e336 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -172,4 +172,14 @@ config PCI_HISI
help
  Say Y here if you want PCIe controller support on HiSilicon HIP05 SoC
 
+config PCIE_QCOM
+   bool "Qualcomm PCIe controller"
+   depends on ARCH_QCOM && OF || COMPILE_TEST
+   select PCIE_DW
+   select PCIEPORTBUS
+   help
+ Say Y here to enable PCIe controller support on Qualcomm SoCs. The
+ PCIe controller use Designware core plus Qualcomm specific hardware
+ wrappers.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 9d4d3c6924a1..e523c171febf 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
+obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
new file mode 100644
index ..36c81973467d
--- /dev/null
+++ b/drivers/pci/host/pcie-qcom.c
@@ -0,0 +1,617 @@
+/*
+ * Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ * Copyright 2015 Linaro Limited.
+ *
+ * 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 
+#include 
+
+#include "pcie-designware.h"
+
+#define PCIE20_PARF_PHY_CTRL   0x40
+#define PCIE20_PARF_PHY_REFCLK 0x4C
+#define PCIE20_PARF_DBI_BASE_ADDR  0x168
+#define PCIE20_PARF_SLV_ADDR_SPACE_SIZE0x16c
+#define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT  0x178
+
+#define PCIE20_ELBI_SYS_CTRL   0x04
+#define PCIE20_ELBI_SYS_CTRL_LT_ENABLE BIT(0)
+
+#define PCIE20_CAP 0x70
+
+#define PERST_DELAY_US 1000
+
+struct qcom_pcie_resources_v0 {
+   struct clk *iface_clk;
+   struct clk *core_clk;
+   struct clk *phy_clk;
+   struct reset_control *pci_reset;
+   struct reset_control *axi_reset;
+   struct reset_control *ahb_reset;
+   struct reset_control *por_reset;
+   struct reset_control *phy_reset;
+   struct regulator *vdda;
+   struct regulator *vdda_phy;
+   struct regulator *vdda_refclk;
+};
+
+struct qcom_pcie_resources_v1 {
+   struct clk *iface;
+   struct clk *aux;
+   struct clk *master_bus;
+   struct clk *slave_bus;
+   struct reset_control *core;
+   struct regulator *vdda;
+};
+
+union qcom_pcie_resources {
+   struct qcom_pcie_resources_v0 v0;
+   struct qcom_pcie_resources_v1 v1;
+};
+
+struct qcom_pcie;
+
+struct qcom_pcie_ops {
+   int (*get_resources)(struct qcom_pcie *pcie);
+   int (*init)(struct qcom_pcie *pcie);
+   void (*deinit)(struct qcom_pcie *pcie);
+};
+
+struct qcom_pcie {
+   struct pcie_port pp;
+   struct device *dev;
+   union qcom_pcie_resources res;
+   void __iomem *parf;
+   void __iomem *dbi;
+   void __iomem *elbi;
+   struct phy *phy;
+   struct gpio_desc *reset;
+   struct qcom_pcie_ops *ops;
+};
+
+#define to_qcom_pcie(x)container_of(x, struct q

[PATCH v5 5/5] ARM: dts: ifc6410: enable pcie dt node for this board

2015-12-18 Thread Stanimir Varbanov
Enable pcie dt node and fill pcie dt node with regulator, pinctrl
and reset gpio, to use the pcie on the ifc6410 board.

Signed-off-by: Stanimir Varbanov 
---
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index f40e93f09673..4584850add62 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -47,6 +47,18 @@
bias-disable;
};
};
+
+   pcie_pins: pcie_pinmux {
+   mux {
+   pins = "gpio27";
+   function = "gpio";
+   };
+   conf {
+   pins = "gpio27";
+   drive-strength = <12>;
+   bias-disable;
+   };
+   };
};
 
rpm@108000 {
@@ -123,6 +135,10 @@
lvs1 {
bias-pull-down;
};
+
+   lvs6 {
+   bias-pull-down;
+   };
};
};
 
@@ -231,6 +247,16 @@
status = "okay";
};
 
+   pci@1b50 {
+   status = "ok";
+   vdda-supply = <&pm8921_s3>;
+   vdda_phy-supply = <&pm8921_lvs6>;
+   vdda_refclk-supply = <&ext_3p3v>;
+   pinctrl-0 = <&pcie_pins>;
+   pinctrl-names = "default";
+   perst-gpio = <&tlmm_pinmux 27 GPIO_ACTIVE_LOW>;
+   };
+
qcom,ssbi@50 {
pmic@0 {
gpio@150 {
-- 
1.7.9.5

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


[PATCH v5 4/5] ARM: dts: apq8064: add pcie devicetree node

2015-12-18 Thread Stanimir Varbanov
Add the pcie dt node so that it can probe and used.

Signed-off-by: Stanimir Varbanov 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi |   36 +++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 1a57278cb818..495807eab8f3 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -705,5 +705,41 @@
compatible = "qcom,tcsr-apq8064", "syscon";
reg = <0x1a40 0x100>;
};
+
+   pcie: pci@1b50 {
+   compatible = "qcom,pcie-apq8064", "snps,dw-pcie";
+   reg = <0x1b50 0x1000
+  0x1b502000 0x80
+  0x1b60 0x100
+  0x0ff0 0x10>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   ranges = <0x8100 0 0 0x0fe0 0 0x0010   /* 
I/O */
+ 0x8200 0 0 0x0800 0 0x07e0>; /* 
memory */
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1 &intc 0 36 
IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2 &intc 0 37 
IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3 &intc 0 38 
IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4 &intc 0 39 
IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+   clocks = <&gcc PCIE_A_CLK>,
+<&gcc PCIE_H_CLK>,
+<&gcc PCIE_PHY_REF_CLK>;
+   clock-names = "core", "iface", "phy";
+   resets = <&gcc PCIE_ACLK_RESET>,
+<&gcc PCIE_HCLK_RESET>,
+<&gcc PCIE_POR_RESET>,
+<&gcc PCIE_PCI_RESET>,
+<&gcc PCIE_PHY_RESET>;
+   reset-names = "axi", "ahb", "por", "pci", "phy";
+   status = "disabled";
+   };
};
 };
-- 
1.7.9.5

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


[PATCH v5 2/5] DT: PCI: qcom: Document PCIe devicetree bindings

2015-12-18 Thread Stanimir Varbanov
From: Stanimir Varbanov 

Document Qualcomm PCIe driver devicetree bindings.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Stanimir Varbanov 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/pci/qcom,pcie.txt  |  233 
 1 file changed, 233 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt 
b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
new file mode 100644
index ..6d71ee2e335d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
@@ -0,0 +1,233 @@
+* Qualcomm PCI express root complex
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Value should contain
+   - "qcom,pcie-ipq8064" for ipq8064
+   - "qcom,pcie-apq8064" for apq8064
+   - "qcom,pcie-apq8084" for apq8084
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: Register ranges as listed in the reg-names property
+
+- reg-names:
+   Usage: required
+   Value type: 
+   Definition: Must include the following entries
+   - "parf"   Qualcomm specific registers
+   - "dbi"Designware PCIe registers
+   - "elbi"   External local bus interface registers
+   - "config" PCIe configuration space
+
+- device_type:
+   Usage: required
+   Value type: 
+   Definition: Should be "pci". As specified in designware-pcie.txt
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: Should be set to 3. As specified in designware-pcie.txt
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: Should be set 2. As specified in designware-pcie.txt
+
+- ranges:
+   Usage: required
+   Value type: 
+   Definition: As specified in designware-pcie.txt
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: MSI interrupt
+
+- interrupt-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain "msi"
+
+- #interrupt-cells:
+   Usage: required
+   Value type: 
+   Definition: Should be 1. As specified in designware-pcie.txt
+
+- interrupt-map-mask:
+   Usage: required
+   Value type: 
+   Definition: As specified in designware-pcie.txt
+
+- interrupt-map:
+   Usage: required
+   Value type: 
+   Definition: As specified in designware-pcie.txt
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: List of phandle and clock specifier pairs as listed
+   in clock-names property
+
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain the following entries
+   - "iface"   Configuration AHB clock
+
+- clock-names:
+   Usage: required for ipq/apq8064
+   Value type: 
+   Definition: Should contain the following entries
+   - "core"Clocks the pcie hw block
+   - "phy" Clocks the pcie PHY block
+- clock-names:
+   Usage: required for apq8084
+   Value type: 
+   Definition: Should contain the following entries
+   - "aux" Auxiliary (AUX) clock
+   - "bus_master"  Master AXI clock
+   - "bus_slave"   Slave AXI clock
+- resets:
+   Usage: required
+   Value type: 
+   Definition: List of phandle and reset specifier pairs as listed
+   in reset-names property
+
+- reset-names:
+   Usage: required for ipq/apq8064
+   Value type: 
+   Definition: Should contain the following entries
+   - "axi"  AXI reset
+   - "ahb"  AHB reset
+   - "por"  POR reset
+   - "pci"  PCI reset
+   - "phy"  PHY reset
+
+- reset-names:
+   Usage: required for apq8084
+   Value type: 
+   Definition: Should contain the following entries
+   - "core" Core reset
+
+- power-domains:
+   Usage: required for apq8084
+   Value type: 
+   Definition: A phandle and power domain specifier pair to the
+   power domain which is responsible for collapsing
+   and restoring power to the peripheral
+
+- vdda-supply:
+   Usage: required
+   Value type: 
+   Definition: A phandle to the core analog power supply
+
+- vdda_phy-supply:
+   Usage: required for ipq/apq8064
+   Value type: 
+   Definition: A phandle to the analog power supply for PHY
+
+- vdda_refclk-supply:
+   Usage: required for ipq/

[PATCH v5 0/5] Qualcomm PCIe driver and designware fixes

2015-12-18 Thread Stanimir Varbanov
Hi,

I'm sending v5 with following changes:
- in 1/5 - replace wmb() call with PCIE_ATU_CR2 register read.
- in 3/5 - addressed comments from Born Helgaas about usage of a
standard PCI capabilities register names and rename link training
function to the way that other Designware based drivers use.
- in 5/5 - addressed a comment from Bjorn Andersson about regulator
label duplication.

Comments are welcome!

The previous v4 of the patch set can be found at [1].

regards,
Stan

[1] https://lkml.org/lkml/2015/12/3/370

Stanimir Varbanov (5):
  PCI: designware: ensure ATU is enabled before IO/conf space accesses
  DT: PCI: qcom: Document PCIe devicetree bindings
  PCI: qcom: Add Qualcomm PCIe controller driver
  ARM: dts: apq8064: add pcie devicetree node
  ARM: dts: ifc6410: enable pcie dt node for this board

 .../devicetree/bindings/pci/qcom,pcie.txt  |  233 
 MAINTAINERS|7 +
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   26 +
 arch/arm/boot/dts/qcom-apq8064.dtsi|   36 ++
 drivers/pci/host/Kconfig   |   10 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pcie-designware.c |7 +
 drivers/pci/host/pcie-qcom.c   |  617 
 8 files changed, 937 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt
 create mode 100644 drivers/pci/host/pcie-qcom.c

-- 
1.7.9.5

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


[PATCH v5 1/5] PCI: designware: ensure ATU is enabled before IO/conf space accesses

2015-12-18 Thread Stanimir Varbanov
There is no guarantees that enabling ATU will hit the hardware
immediately, and subsequent accesses to configuration / IO spaces
are reliable. So fixing this by read back PCIE_ATU_CR2 register
just after writing.

Without such a fix the PCI device enumeration during kernel boot
is not reliable, and reading configuration space for particular
PCI device on the bus returns zero aka no device.

Signed-off-by: Stanimir Varbanov 
---
 drivers/pci/host/pcie-designware.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 02a7452bdf23..7880de63895d 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -154,6 +154,8 @@ static int dw_pcie_wr_own_conf(struct pcie_port *pp, int 
where, int size,
 static void dw_pcie_prog_outbound_atu(struct pcie_port *pp, int index,
int type, u64 cpu_addr, u64 pci_addr, u32 size)
 {
+   u32 val;
+
dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | index,
  PCIE_ATU_VIEWPORT);
dw_pcie_writel_rc(pp, lower_32_bits(cpu_addr), PCIE_ATU_LOWER_BASE);
@@ -164,6 +166,11 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port 
*pp, int index,
dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET);
dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
+   /*
+* ensure that the ATU enable has been happaned before accessing
+* pci configuration/io spaces through dw_pcie_cfg_[read|write].
+*/
+   dw_pcie_readl_rc(pp, PCIE_ATU_CR2, &val);
 }
 
 static struct irq_chip dw_msi_irq_chip = {
-- 
1.7.9.5

--
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 v4 5/5] ARM: dts: ifc6410: enable pcie dt node for this board

2015-12-18 Thread Stanimir Varbanov
On 12/17/2015 11:55 PM, Bjorn Andersson wrote:
> On Thu 03 Dec 05:35 PST 2015, Stanimir Varbanov wrote:
> 
>> Enable pcie dt node and fill pcie dt node with regulator, pinctrl
>> and reset gpio, to use the pcie on the ifc6410 board.
>>
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   26 ++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
>> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
>> index 11ac608b6d50..f203b94ee460 100644
>> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
>> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
>> @@ -47,6 +47,18 @@
>>  bias-disable;
>>  };
>>  };
>> +
>> +pcie_pins: pcie_pinmux {
>> +mux {
>> +pins = "gpio27";
>> +function = "gpio";
>> +};
>> +conf {
>> +pins = "gpio27";
>> +drive-strength = <12>;
>> +bias-disable;
>> +};
>> +};
>>  };
>>  
>>  rpm@108000 {
>> @@ -123,6 +135,10 @@
>>  pm8921_lvs1: lvs1 {
>>  bias-pull-down;
>>  };
>> +
>> +pm8921_lvs6: lvs6 {
>> +bias-pull-down;
>> +};
> 
> Please don't duplicate the labels in the dts files.

Sorry, I based those dts patches before [1] has been applied in -next. I
will rebase this patch on top of [1]. Thanks!

[1] "ARM: dts: qcom: apq8064: Declare all pm8921 regulators"

-- 
regards,
Stan
--
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 v4 1/5] PCI: designware: add memory barrier after enabling region

2015-12-17 Thread Stanimir Varbanov
On 12/11/2015 06:05 AM, Pratyush Anand wrote:
> On Wed, Dec 9, 2015 at 3:53 PM, Russell King - ARM Linux
>  wrote:
> 
> [...]
> 
>   dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
> + /*
> +  * ensure that the ATU enable has been happaned before accessing
> +  * pci configuration/io spaces through dw_pcie_cfg_[read|write].
> +  */
> + wmb();
>  }
>
>>>
>>>
>>> My understnading is that since writel() of dw_pcie_writel_rc() in
>>> above code and readl(), writel() of dw_pcie_cfg_[read|write]() (which
>>> will follow) goes through same device (ie PCIe host here). So, it is
>>> guaranteed that 1st writel() will be executed before later
>>> readl()/writel(). If that is true then we do not need any explicit
>>> barrier here.
>>>
>>> Arnd, Russel: whats your opinion here.
>>   ^l
> 
> Sorry :(
> 
>>
>> writel() has a barrier _before_ the access but not after.
>>
>> The fact is that there's nothing which guarantees that the write will hit
>> the hardware in a timely manner (forget any rules about PCI config space,
>> the PCI ordering rules apply to the PCI bus, not to the ARM buses.)
>>
>> If you need this write to have hit the hardware before continuing, you
>> need to read back from the same register.
> 
> OK, so better to replace wmb() with read back of control register.

Would the patch be acceptable if I replace wmb with read?

-- 
regards,
Stan
--
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 v4 3/5] PCI: qcom: Add Qualcomm PCIe controller driver

2015-12-17 Thread Stanimir Varbanov
Bjorn, thanks for the comments!

On 12/16/2015 11:53 PM, Bjorn Helgaas wrote:
> On Thu, Dec 03, 2015 at 03:35:22PM +0200, Stanimir Varbanov wrote:
>> From: Stanimir Varbanov 
>>
>> The PCIe driver reuse the Designware common code for host
>> and MSI initialization, and also program the Qualcomm
>> application specific registers.
>>
>> Signed-off-by: Stanimir Varbanov 
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  MAINTAINERS  |7 +
>>  drivers/pci/host/Kconfig |   10 +
>>  drivers/pci/host/Makefile|1 +
>>  drivers/pci/host/pcie-qcom.c |  624 
>> ++
> 
>> +#define PCIE20_CAP  0x70
>> +#define PCIE20_CAP_LINKCTRLSTATUS   (PCIE20_CAP + 0x10)
>> +#define PCIE20_CAP_LINKCTRLSTATUS_LINK_UP   BIT(29)
> 
> This looks like it could be referring to a standard PCIe Capability;
> could you use the existing PCI_EXP_LNKSTA and PCI_EXP_LNKSTA_DLLLA
> symbols here?  And readw() instead of readl()?

Yes, that is possible but I still need to keep PCIE20_CAP capabilities
offset.

> 
>> +static int qcom_pcie_enable_link_training(struct qcom_pcie *pcie)
>> +{
>> +struct device *dev = pcie->dev;
>> +u32 val;
>> +int ret;
>> +
>> +/* enable link training */
>> +val = readl(pcie->elbi + PCIE20_ELBI_SYS_CTRL);
>> +val |= PCIE20_ELBI_SYS_CTRL_LT_ENABLE;
>> +writel(val, pcie->elbi + PCIE20_ELBI_SYS_CTRL);
>> +
>> +/* wait for up to 100ms for the link to come up */
>> +ret = readl_poll_timeout(pcie->elbi + PCIE20_ELBI_SYS_STTS, val,
>> + val & XMLH_LINK_UP, LINKUP_DELAY_US,
>> + LINKUP_TIMEOUT_US);
>> +
>> +if (ret < 0 || !dw_pcie_link_up(&pcie->pp)) {
>> +dev_err(dev, "link initialization failed\n");
>> +return -ETIMEDOUT;
>> +}
>> +
>> +return 0;
>> +}
> 
> This looks a lot like the *_establish_link() functions in other
> DesignWare-based drivers.  Can you make it look even more similar,
> e.g., by renaming it to qcom_pcie_establish_link() and maybe moving
> some of the PHY functionality here?
> 
> readl_poll_timeout() is nice and avoids the hand-coded timeout loop
> the other drivers use.  But is there benefit in checking for
> XMLH_LINK_UP, or could you simply poll dw_pcie_link_up() like the
> others do?  If it's sufficient, I'd prefer using dw_pcie_link_up()
> by itself because it's a little more generic.

OK I will modify the code to use dw_pcie_link_up() and ensure that this
check is sufficient.

-- 
regards,
Stan
--
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 v4 3/5] PCI: qcom: Add Qualcomm PCIe controller driver

2015-12-15 Thread Stanimir Varbanov
On 12/03/2015 03:35 PM, Stanimir Varbanov wrote:
> From: Stanimir Varbanov 
> 
> The PCIe driver reuse the Designware common code for host
> and MSI initialization, and also program the Qualcomm
> application specific registers.
> 
> Signed-off-by: Stanimir Varbanov 
> Signed-off-by: Stanimir Varbanov 
> ---
>  MAINTAINERS  |7 +
>  drivers/pci/host/Kconfig |   10 +
>  drivers/pci/host/Makefile|1 +
>  drivers/pci/host/pcie-qcom.c |  624 
> ++
>  4 files changed, 642 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-qcom.c

Hi Bjorn, any chance to get this merged in 4.5 ?


-- 
regards,
Stan
--
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 3/4] dmaengine: qcom_bam_dma: use correct pipe FIFO size

2015-12-10 Thread Stanimir Varbanov
On 12/02/2015 07:22 PM, Andy Gross wrote:
> On Wed, Dec 02, 2015 at 06:44:11PM +0200, Stanimir Varbanov wrote:
>> On 12/01/2015 07:23 PM, Andy Gross wrote:
>>> On Tue, Dec 01, 2015 at 11:14:58AM +0200, Stanimir Varbanov wrote:
>>>> The pipe fifo size register must instruct the bam hw
>>>> how many hw descriptors can be pushed to fifo. Currently
>>>> we isntruct the hw with 32KBytes but wrap the tail in
>>>> bam_start_dma in BAM_P_EVNT_REG on 4095 i.e. 32760. This
>>>> leads to stalled transactions when the tail wraps.
>>>>
>>>> Fix this by use the correct fifo size in BAM_P_FIFO_SIZES
>>>> register i.e. 32K - 8.
>>>>
>>>> Signed-off-by: Stanimir Varbanov 
>>>> ---
>>>>  drivers/dma/qcom_bam_dma.c |2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
>>>> index 0f06f3b7a72b..6d290de9ab2b 100644
>>>> --- a/drivers/dma/qcom_bam_dma.c
>>>> +++ b/drivers/dma/qcom_bam_dma.c
>>>> @@ -458,7 +458,7 @@ static void bam_chan_init_hw(struct bam_chan *bchan,
>>>> */
>>>>writel_relaxed(ALIGN(bchan->fifo_phys, sizeof(struct bam_desc_hw)),
>>>>bam_addr(bdev, bchan->id, BAM_P_DESC_FIFO_ADDR));
>>>> -  writel_relaxed(BAM_DESC_FIFO_SIZE,
>>>> +  writel_relaxed(BAM_MAX_DATA_SIZE,
>>>>bam_addr(bdev, bchan->id, BAM_P_FIFO_SIZES));
>>>
>>> This is just using the #define.  That is ok, but if you use this instead of 
>>> the
>>> BAM_P_FIFO_SIZES then you need to fix your comment.  Or actually use the
>>> register value otherwise looks fine.
>>
>> I did not follow your comment, but the intension of the patch is to set
>> the proper FIFO size in BAM_P_FIFO_SIZES register, i.e. 32K - 8.
> 
> Sorry, I mixed up the usage and was thinking there was something you read out
> that told you the size.  That's not how it works, unfortunately.  The
> MAX_DATA_SIZE is fine, but the name is a little misleading.  Perhaps just
> BAM_FIFO_SIZE?

OK I can rename BAM_MAX_DATA_SIZE to BAM_FIFO_SIZE, and use it when
setting BAM_P_FIFO_SIZES register. Is that fine to you?


-- 
regards,
Stan
--
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 v4 1/5] PCI: designware: add memory barrier after enabling region

2015-12-09 Thread Stanimir Varbanov
On 12/09/2015 11:52 AM, Arnd Bergmann wrote:
> On Wednesday 09 December 2015 10:10:05 Pratyush Anand wrote:
>> On Tue, Dec 8, 2015 at 2:31 PM, Stanimir Varbanov
>>>> Signed-off-by: Stanimir Varbanov 
>>>> ---
>>>>  drivers/pci/host/pcie-designware.c |5 +
>>>>  1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/host/pcie-designware.c 
>>>> b/drivers/pci/host/pcie-designware.c
>>>> index 02a7452bdf23..ed4dc2e2553b 100644
>>>> --- a/drivers/pci/host/pcie-designware.c
>>>> +++ b/drivers/pci/host/pcie-designware.c
>>>> @@ -164,6 +164,11 @@ static void dw_pcie_prog_outbound_atu(struct 
>>>> pcie_port *pp, int index,
>>>>   dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), 
>>>> PCIE_ATU_UPPER_TARGET);
>>>>   dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
>>>>   dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
>>>> + /*
>>>> +  * ensure that the ATU enable has been happaned before accessing
>>>> +  * pci configuration/io spaces through dw_pcie_cfg_[read|write].
>>>> +  */
>>>> + wmb();
>>>>  }
>>>>
>>
>>
>> My understnading is that since writel() of dw_pcie_writel_rc() in
>> above code and readl(), writel() of dw_pcie_cfg_[read|write]() (which
>> will follow) goes through same device (ie PCIe host here). So, it is
>> guaranteed that 1st writel() will be executed before later
>> readl()/writel(). If that is true then we do not need any explicit
>> barrier here.
>>
>> Arnd, Russel: whats your opinion here.
> 
> I think the ordering is only enforced if the two register accesses are
> on the same device as seen from the bus, and it's possible that the
> RC registers and the config space registers are not considered the
> same thing here.
> 
> For config write, this is not a problem, because the config space write
> has a wmb() that enforces ordering, but it's possible that the config
> space read may hit the device in parallel with the PCIE_ATU_ENABLE
> write.

Hmm, just a matter of fact - as I described in the patch description
this wmb() fixed an issue with pcie device enumeration (I came down to
pci_bus_read_dev_vendor_id() returns zero) i.e. exactly a pci
configuration space read.

-- 
regards,
Stan
--
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 v4 1/5] PCI: designware: add memory barrier after enabling region

2015-12-08 Thread Stanimir Varbanov
On 12/03/2015 03:35 PM, Stanimir Varbanov wrote:
> Add 'write memory' barrier after enable region in PCIE_ATU_CR2
> register. The barrier is needed to ensure that the region enable
> request has been reached it's destination at time when we
> read/write to PCI configuration space.
> 
> Without this barrier PCI device enumeration during kernel boot
> is not reliable, and reading configuration space for particular
> PCI device on the bus returns zero aka no device.

Anand, Jingoo, what is your opinion?

> 
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/pci/host/pcie-designware.c |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/pci/host/pcie-designware.c 
> b/drivers/pci/host/pcie-designware.c
> index 02a7452bdf23..ed4dc2e2553b 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -164,6 +164,11 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port 
> *pp, int index,
>   dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET);
>   dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
>   dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
> + /*
> +  * ensure that the ATU enable has been happaned before accessing
> +  * pci configuration/io spaces through dw_pcie_cfg_[read|write].
> +  */
> + wmb();
>  }
>  
>  static struct irq_chip dw_msi_irq_chip = {
> 


-- 
regards,
Stan
--
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


[PATCH v4 1/5] PCI: designware: add memory barrier after enabling region

2015-12-03 Thread Stanimir Varbanov
Add 'write memory' barrier after enable region in PCIE_ATU_CR2
register. The barrier is needed to ensure that the region enable
request has been reached it's destination at time when we
read/write to PCI configuration space.

Without this barrier PCI device enumeration during kernel boot
is not reliable, and reading configuration space for particular
PCI device on the bus returns zero aka no device.

Signed-off-by: Stanimir Varbanov 
---
 drivers/pci/host/pcie-designware.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 02a7452bdf23..ed4dc2e2553b 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -164,6 +164,11 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port 
*pp, int index,
dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET);
dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
+   /*
+* ensure that the ATU enable has been happaned before accessing
+* pci configuration/io spaces through dw_pcie_cfg_[read|write].
+*/
+   wmb();
 }
 
 static struct irq_chip dw_msi_irq_chip = {
-- 
1.7.9.5

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


[PATCH v4 3/5] PCI: qcom: Add Qualcomm PCIe controller driver

2015-12-03 Thread Stanimir Varbanov
From: Stanimir Varbanov 

The PCIe driver reuse the Designware common code for host
and MSI initialization, and also program the Qualcomm
application specific registers.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Stanimir Varbanov 
---
 MAINTAINERS  |7 +
 drivers/pci/host/Kconfig |   10 +
 drivers/pci/host/Makefile|1 +
 drivers/pci/host/pcie-qcom.c |  624 ++
 4 files changed, 642 insertions(+)
 create mode 100644 drivers/pci/host/pcie-qcom.c

diff --git a/MAINTAINERS b/MAINTAINERS
index cba790b42f23..c07377148399 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8247,6 +8247,13 @@ S:   Maintained
 F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F: drivers/pci/host/pcie-hisi.c
 
+PCIE DRIVER FOR QUALCOMM MSM
+M: Stanimir Varbanov 
+L: linux-...@vger.kernel.org
+L: linux-arm-msm@vger.kernel.org
+S: Maintained
+F: drivers/pci/host/*qcom*
+
 PCMCIA SUBSYSTEM
 P: Linux PCMCIA Team
 L: linux-pcm...@lists.infradead.org
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index f131ba947dc6..64d33ba3e336 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -172,4 +172,14 @@ config PCI_HISI
help
  Say Y here if you want PCIe controller support on HiSilicon HIP05 SoC
 
+config PCIE_QCOM
+   bool "Qualcomm PCIe controller"
+   depends on ARCH_QCOM && OF || COMPILE_TEST
+   select PCIE_DW
+   select PCIEPORTBUS
+   help
+ Say Y here to enable PCIe controller support on Qualcomm SoCs. The
+ PCIe controller use Designware core plus Qualcomm specific hardware
+ wrappers.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 9d4d3c6924a1..e523c171febf 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
+obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
new file mode 100644
index ..7d9b7f14354b
--- /dev/null
+++ b/drivers/pci/host/pcie-qcom.c
@@ -0,0 +1,624 @@
+/*
+ * Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ * Copyright 2015 Linaro Limited.
+ *
+ * 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 
+#include 
+
+#include "pcie-designware.h"
+
+#define PCIE20_PARF_PHY_CTRL   0x40
+#define PCIE20_PARF_PHY_REFCLK 0x4C
+#define PCIE20_PARF_DBI_BASE_ADDR  0x168
+#define PCIE20_PARF_SLV_ADDR_SPACE_SIZE0x16c
+#define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT  0x178
+
+#define PCIE20_ELBI_SYS_CTRL   0x04
+#define PCIE20_ELBI_SYS_CTRL_LT_ENABLE BIT(0)
+
+#define PCIE20_ELBI_SYS_STTS   0x08
+#define XMLH_LINK_UP   BIT(10)
+
+#define PCIE20_CAP 0x70
+#define PCIE20_CAP_LINKCTRLSTATUS  (PCIE20_CAP + 0x10)
+#define PCIE20_CAP_LINKCTRLSTATUS_LINK_UP  BIT(29)
+
+#define PERST_DELAY_US 1000
+
+#define LINKUP_DELAY_US5000
+#define LINKUP_TIMEOUT_US  10
+
+struct qcom_pcie_resources_v0 {
+   struct clk *iface_clk;
+   struct clk *core_clk;
+   struct clk *phy_clk;
+   struct reset_control *pci_reset;
+   struct reset_control *axi_reset;
+   struct reset_control *ahb_reset;
+   struct reset_control *por_reset;
+   struct reset_control *phy_reset;
+   struct regulator *vdda;
+   struct regulator *vdda_phy;
+   struct regulator *vdda_refclk;
+};
+
+struct qcom_pcie_resources_v1 {
+   struct clk *iface;
+   struct clk *aux;
+   struct clk *master_bus;
+   struct clk *slave_bus;
+   struct reset_control *core;
+   struct regulator *vdda;
+};
+
+union qcom_pcie_resources {
+   struct qcom_pcie_resources_v0 v0;
+   struct qcom_pcie_resources_v1 v1;
+};
+
+struct qcom_pcie;
+
+struct qcom_pcie_ops {
+   int (*get_resources)(struct qcom_pcie *pcie);
+   int (*init)(struct qcom_pcie *pcie);
+   void (*deinit)(struct qcom_pcie *pcie);
+};
+
+struc

[PATCH v4 4/5] ARM: dts: apq8064: add pcie devicetree node

2015-12-03 Thread Stanimir Varbanov
Add the pcie dt node so that it can probe and used.

Signed-off-by: Stanimir Varbanov 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi |   36 +++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index a4c1762b53ea..847150fbfdbf 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -659,5 +659,41 @@
compatible = "qcom,tcsr-apq8064", "syscon";
reg = <0x1a40 0x100>;
};
+
+   pcie: pci@1b50 {
+   compatible = "qcom,pcie-apq8064", "snps,dw-pcie";
+   reg = <0x1b50 0x1000
+  0x1b502000 0x80
+  0x1b60 0x100
+  0x0ff0 0x10>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   ranges = <0x8100 0 0 0x0fe0 0 0x0010   /* 
I/O */
+ 0x8200 0 0 0x0800 0 0x07e0>; /* 
memory */
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1 &intc 0 36 
IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2 &intc 0 37 
IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3 &intc 0 38 
IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4 &intc 0 39 
IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+   clocks = <&gcc PCIE_A_CLK>,
+<&gcc PCIE_H_CLK>,
+<&gcc PCIE_PHY_REF_CLK>;
+   clock-names = "core", "iface", "phy";
+   resets = <&gcc PCIE_ACLK_RESET>,
+<&gcc PCIE_HCLK_RESET>,
+<&gcc PCIE_POR_RESET>,
+<&gcc PCIE_PCI_RESET>,
+<&gcc PCIE_PHY_RESET>;
+   reset-names = "axi", "ahb", "por", "pci", "phy";
+   status = "disabled";
+   };
};
 };
-- 
1.7.9.5

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


[PATCH v4 5/5] ARM: dts: ifc6410: enable pcie dt node for this board

2015-12-03 Thread Stanimir Varbanov
Enable pcie dt node and fill pcie dt node with regulator, pinctrl
and reset gpio, to use the pcie on the ifc6410 board.

Signed-off-by: Stanimir Varbanov 
---
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 11ac608b6d50..f203b94ee460 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -47,6 +47,18 @@
bias-disable;
};
};
+
+   pcie_pins: pcie_pinmux {
+   mux {
+   pins = "gpio27";
+   function = "gpio";
+   };
+   conf {
+   pins = "gpio27";
+   drive-strength = <12>;
+   bias-disable;
+   };
+   };
};
 
rpm@108000 {
@@ -123,6 +135,10 @@
pm8921_lvs1: lvs1 {
bias-pull-down;
};
+
+   pm8921_lvs6: lvs6 {
+   bias-pull-down;
+   };
};
};
 
@@ -231,6 +247,16 @@
status = "okay";
};
 
+   pci@1b50 {
+   status = "ok";
+   vdda-supply = <&pm8921_s3>;
+   vdda_phy-supply = <&pm8921_lvs6>;
+   vdda_refclk-supply = <&ext_3p3v>;
+   pinctrl-0 = <&pcie_pins>;
+   pinctrl-names = "default";
+   perst-gpio = <&tlmm_pinmux 27 GPIO_ACTIVE_LOW>;
+   };
+
qcom,ssbi@50 {
pmic@0 {
gpio@150 {
-- 
1.7.9.5

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


[PATCH v4 2/5] DT: PCI: qcom: Document PCIe devicetree bindings

2015-12-03 Thread Stanimir Varbanov
From: Stanimir Varbanov 

Document Qualcomm PCIe driver devicetree bindings.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Stanimir Varbanov 
---
 .../devicetree/bindings/pci/qcom,pcie.txt  |  233 
 1 file changed, 233 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt 
b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
new file mode 100644
index ..6d71ee2e335d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
@@ -0,0 +1,233 @@
+* Qualcomm PCI express root complex
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Value should contain
+   - "qcom,pcie-ipq8064" for ipq8064
+   - "qcom,pcie-apq8064" for apq8064
+   - "qcom,pcie-apq8084" for apq8084
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: Register ranges as listed in the reg-names property
+
+- reg-names:
+   Usage: required
+   Value type: 
+   Definition: Must include the following entries
+   - "parf"   Qualcomm specific registers
+   - "dbi"Designware PCIe registers
+   - "elbi"   External local bus interface registers
+   - "config" PCIe configuration space
+
+- device_type:
+   Usage: required
+   Value type: 
+   Definition: Should be "pci". As specified in designware-pcie.txt
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: Should be set to 3. As specified in designware-pcie.txt
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: Should be set 2. As specified in designware-pcie.txt
+
+- ranges:
+   Usage: required
+   Value type: 
+   Definition: As specified in designware-pcie.txt
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: MSI interrupt
+
+- interrupt-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain "msi"
+
+- #interrupt-cells:
+   Usage: required
+   Value type: 
+   Definition: Should be 1. As specified in designware-pcie.txt
+
+- interrupt-map-mask:
+   Usage: required
+   Value type: 
+   Definition: As specified in designware-pcie.txt
+
+- interrupt-map:
+   Usage: required
+   Value type: 
+   Definition: As specified in designware-pcie.txt
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: List of phandle and clock specifier pairs as listed
+   in clock-names property
+
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain the following entries
+   - "iface"   Configuration AHB clock
+
+- clock-names:
+   Usage: required for ipq/apq8064
+   Value type: 
+   Definition: Should contain the following entries
+   - "core"Clocks the pcie hw block
+   - "phy" Clocks the pcie PHY block
+- clock-names:
+   Usage: required for apq8084
+   Value type: 
+   Definition: Should contain the following entries
+   - "aux" Auxiliary (AUX) clock
+   - "bus_master"  Master AXI clock
+   - "bus_slave"   Slave AXI clock
+- resets:
+   Usage: required
+   Value type: 
+   Definition: List of phandle and reset specifier pairs as listed
+   in reset-names property
+
+- reset-names:
+   Usage: required for ipq/apq8064
+   Value type: 
+   Definition: Should contain the following entries
+   - "axi"  AXI reset
+   - "ahb"  AHB reset
+   - "por"  POR reset
+   - "pci"  PCI reset
+   - "phy"  PHY reset
+
+- reset-names:
+   Usage: required for apq8084
+   Value type: 
+   Definition: Should contain the following entries
+   - "core" Core reset
+
+- power-domains:
+   Usage: required for apq8084
+   Value type: 
+   Definition: A phandle and power domain specifier pair to the
+   power domain which is responsible for collapsing
+   and restoring power to the peripheral
+
+- vdda-supply:
+   Usage: required
+   Value type: 
+   Definition: A phandle to the core analog power supply
+
+- vdda_phy-supply:
+   Usage: required for ipq/apq8064
+   Value type: 
+   Definition: A phandle to the analog power supply for PHY
+
+- vdda_refclk-supply:
+   Usage: required for ipq/apq8064
+   Value

[PATCH v4 0/5] Qualcomm PCIe driver and designware fixes

2015-12-03 Thread Stanimir Varbanov
Hi,

Here is v4, comments from Bjorn and Rob have been addressed.
The previous version can be found at [1].

regards,
Stan

[1] https://lkml.org/lkml/2015/11/23/114

Stanimir Varbanov (5):
  PCI: designware: add memory barrier after enabling region
  DT: PCI: qcom: Document PCIe devicetree bindings
  PCI: qcom: Add Qualcomm PCIe controller driver
  ARM: dts: apq8064: add pcie devicetree node
  ARM: dts: ifc6410: enable pcie dt node for this board

 .../devicetree/bindings/pci/qcom,pcie.txt  |  233 
 MAINTAINERS|7 +
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   26 +
 arch/arm/boot/dts/qcom-apq8064.dtsi|   36 ++
 drivers/pci/host/Kconfig   |   10 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pcie-designware.c |5 +
 drivers/pci/host/pcie-qcom.c   |  624 
 8 files changed, 942 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt
 create mode 100644 drivers/pci/host/pcie-qcom.c

-- 
1.7.9.5

--
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 2/4] dmaengine: qcom_bam_dma: clear BAM interrupt only if it is rised

2015-12-02 Thread Stanimir Varbanov
On 12/02/2015 03:05 PM, Arnd Bergmann wrote:
> On Wednesday 02 December 2015 14:56:57 Stanimir Varbanov wrote:
>> On 12/01/2015 12:29 PM, Arnd Bergmann wrote:
>>> On Tuesday 01 December 2015 11:14:57 Stanimir Varbanov wrote:
>>>> +   if (srcs & BAM_IRQ) {
>>>> clr_mask = readl_relaxed(bam_addr(bdev, 0, BAM_IRQ_STTS));
>>>>  
>>>> -   /* don't allow reorder of the various accesses to the BAM 
>>>> registers */
>>>> -   mb();
>>>> +   /*
>>>> +* don't allow reorder of the various accesses to the BAM
>>>> +* registers
>>>> +*/
>>>> +   mb();
>>>>  
>>>> -   writel_relaxed(clr_mask, bam_addr(bdev, 0, BAM_IRQ_CLR));
>>>> +   writel_relaxed(clr_mask, bam_addr(bdev, 0, BAM_IRQ_CLR));
>>>> +   }
>>>>
>>>
>>> I think the comment here should be moved: change the writel_relaxed()
>>> to writel(), which already includes the appropriate barriers, and
>>
>> If we agree with such a change it should be subject to another patch.
> 
> Correct.
> 
>>> add a comment at the readl_relaxed() to explain why it doesn't need
>>> a barrier.
>>
>> Infact I'm not sure that readl_relaxed(BAM_IRQ_STTS) does not need
>> barrier. If I read the code above correctly the mb() should guarantee
>> that all load and store operations before it are happened before the
>> write to BAM_IRQ_CLR register, and on the other hand if we replace
>> writel_relaxed with writel, the writel has wmb() which guarantees only
>> store operations. Did I miss something?
> 
> You are right, we only guarantee that stores to memory are complete
> before we writel() an MMIO register.
> 
> What do you gain from synchronizing reads before an MMIO write?

I don't know just tried to understand the meaning of mb() above.

-- 
regards,
Stan
--
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 3/4] dmaengine: qcom_bam_dma: use correct pipe FIFO size

2015-12-02 Thread Stanimir Varbanov
On 12/01/2015 07:23 PM, Andy Gross wrote:
> On Tue, Dec 01, 2015 at 11:14:58AM +0200, Stanimir Varbanov wrote:
>> The pipe fifo size register must instruct the bam hw
>> how many hw descriptors can be pushed to fifo. Currently
>> we isntruct the hw with 32KBytes but wrap the tail in
>> bam_start_dma in BAM_P_EVNT_REG on 4095 i.e. 32760. This
>> leads to stalled transactions when the tail wraps.
>>
>> Fix this by use the correct fifo size in BAM_P_FIFO_SIZES
>> register i.e. 32K - 8.
>>
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  drivers/dma/qcom_bam_dma.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
>> index 0f06f3b7a72b..6d290de9ab2b 100644
>> --- a/drivers/dma/qcom_bam_dma.c
>> +++ b/drivers/dma/qcom_bam_dma.c
>> @@ -458,7 +458,7 @@ static void bam_chan_init_hw(struct bam_chan *bchan,
>>   */
>>  writel_relaxed(ALIGN(bchan->fifo_phys, sizeof(struct bam_desc_hw)),
>>  bam_addr(bdev, bchan->id, BAM_P_DESC_FIFO_ADDR));
>> -writel_relaxed(BAM_DESC_FIFO_SIZE,
>> +writel_relaxed(BAM_MAX_DATA_SIZE,
>>  bam_addr(bdev, bchan->id, BAM_P_FIFO_SIZES));
> 
> This is just using the #define.  That is ok, but if you use this instead of 
> the
> BAM_P_FIFO_SIZES then you need to fix your comment.  Or actually use the
> register value otherwise looks fine.

I did not follow your comment, but the intension of the patch is to set
the proper FIFO size in BAM_P_FIFO_SIZES register, i.e. 32K - 8.

-- 
regards,
Stan
--
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 2/4] dmaengine: qcom_bam_dma: clear BAM interrupt only if it is rised

2015-12-02 Thread Stanimir Varbanov
On 12/01/2015 12:29 PM, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 11:14:57 Stanimir Varbanov wrote:
>> +   if (srcs & BAM_IRQ) {
>> clr_mask = readl_relaxed(bam_addr(bdev, 0, BAM_IRQ_STTS));
>>  
>> -   /* don't allow reorder of the various accesses to the BAM registers 
>> */
>> -   mb();
>> +   /*
>> +* don't allow reorder of the various accesses to the BAM
>> +* registers
>> +*/
>> +   mb();
>>  
>> -   writel_relaxed(clr_mask, bam_addr(bdev, 0, BAM_IRQ_CLR));
>> +   writel_relaxed(clr_mask, bam_addr(bdev, 0, BAM_IRQ_CLR));
>> +   }
>>
> 
> I think the comment here should be moved: change the writel_relaxed()
> to writel(), which already includes the appropriate barriers, and

If we agree with such a change it should be subject to another patch.

> add a comment at the readl_relaxed() to explain why it doesn't need
> a barrier.

Infact I'm not sure that readl_relaxed(BAM_IRQ_STTS) does not need
barrier. If I read the code above correctly the mb() should guarantee
that all load and store operations before it are happened before the
write to BAM_IRQ_CLR register, and on the other hand if we replace
writel_relaxed with writel, the writel has wmb() which guarantees only
store operations. Did I miss something?

-- 
regards,
Stan
--
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


[PATCH 2/4] dmaengine: qcom_bam_dma: clear BAM interrupt only if it is rised

2015-12-01 Thread Stanimir Varbanov
Currently we write BAM_IRQ_CLR register with zero even when no
BAM_IRQ occured. This write has some bad side effects when the
BAM instance is for the crypto engine. In case of crypto engine
some of the BAM registers are xPU protected and they cannot be
controlled by the driver.

Signed-off-by: Stanimir Varbanov 
---
 drivers/dma/qcom_bam_dma.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
index dc9da477eb69..0f06f3b7a72b 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom_bam_dma.c
@@ -800,13 +800,17 @@ static irqreturn_t bam_dma_irq(int irq, void *data)
if (srcs & P_IRQ)
tasklet_schedule(&bdev->task);
 
-   if (srcs & BAM_IRQ)
+   if (srcs & BAM_IRQ) {
clr_mask = readl_relaxed(bam_addr(bdev, 0, BAM_IRQ_STTS));
 
-   /* don't allow reorder of the various accesses to the BAM registers */
-   mb();
+   /*
+* don't allow reorder of the various accesses to the BAM
+* registers
+*/
+   mb();
 
-   writel_relaxed(clr_mask, bam_addr(bdev, 0, BAM_IRQ_CLR));
+   writel_relaxed(clr_mask, bam_addr(bdev, 0, BAM_IRQ_CLR));
+   }
 
return IRQ_HANDLED;
 }
-- 
1.7.9.5

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


[PATCH 3/4] dmaengine: qcom_bam_dma: use correct pipe FIFO size

2015-12-01 Thread Stanimir Varbanov
The pipe fifo size register must instruct the bam hw
how many hw descriptors can be pushed to fifo. Currently
we isntruct the hw with 32KBytes but wrap the tail in
bam_start_dma in BAM_P_EVNT_REG on 4095 i.e. 32760. This
leads to stalled transactions when the tail wraps.

Fix this by use the correct fifo size in BAM_P_FIFO_SIZES
register i.e. 32K - 8.

Signed-off-by: Stanimir Varbanov 
---
 drivers/dma/qcom_bam_dma.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
index 0f06f3b7a72b..6d290de9ab2b 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom_bam_dma.c
@@ -458,7 +458,7 @@ static void bam_chan_init_hw(struct bam_chan *bchan,
 */
writel_relaxed(ALIGN(bchan->fifo_phys, sizeof(struct bam_desc_hw)),
bam_addr(bdev, bchan->id, BAM_P_DESC_FIFO_ADDR));
-   writel_relaxed(BAM_DESC_FIFO_SIZE,
+   writel_relaxed(BAM_MAX_DATA_SIZE,
bam_addr(bdev, bchan->id, BAM_P_FIFO_SIZES));
 
/* enable the per pipe interrupts, enable EOT, ERR, and INT irqs */
-- 
1.7.9.5

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


[PATCH 1/4] dmaengine: qcom_bam_dma: fix dma free memory on remove

2015-12-01 Thread Stanimir Varbanov
Building the driver as a module and when removing the already
inserted module gives below:

[ 1389.392788] Unable to handle kernel paging request at virtual address 
ffbdc01c
[ 1389.421321] pgd = ffc02fa87000
[ 1389.447899] [ffbdc01c] *pgd=, *pud=
[ 1389.460142] Internal error: Oops: 9606 [#1] PREEMPT SMP
[ 1389.466963] Modules linked in: qcom_bam_dma(-)
[ 1389.486608] CPU: 2 PID: 2442 Comm: rmmod Not tainted 4.2.0+ #407
[ 1389.493885] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
[ 1389.501196] task: ffc035bae2c0 ti: ffc0368a8000 task.ti: 
ffc0368a8000
[ 1389.508566] PC is at __free_pages+0xc/0x40
[ 1389.515893] LR is at free_pages.part.93+0x30/0x38
[ 1389.523141] pc : [] lr : [] pstate: 
8145
[ 1389.530602] sp : ffc0368abc20
[ 1389.537931] x29: ffc0368abc20 x28: ffc0368a8000
[ 1389.549153] x27:  x26: 
[ 1389.560412] x25: ffc000cb2000 x24: 0170
[ 1389.571530] x23: 0004 x22: ffc036bc5010
[ 1389.582721] x21: ffc036bc5010 x20: 
[ 1389.593981] x19: 0002 x18: 007fcbc8e8b0
[ 1389.605301] x17: 007f9b8226ec x16: ffc0002089e8
[ 1389.616647] x15: 007f9b8a0588 x14: 0ffc
[ 1389.628039] x13: 0030 x12: 
[ 1389.639436] x11: 0008 x10: ffc000ecc000
[ 1389.650872] x9 : ffc035bae2c0 x8 : ffc035bae9a8
[ 1389.662367] x7 : ffc035bae9a0 x6 : 
[ 1389.673906] x5 : ffbdc01c x4 : 8000
[ 1389.685475] x3 : ffbdc000 x2 : 00408000
[ 1389.697049] x1 : 0003 x0 : ffbdc000

The memory has been already freed by bam_free_chan() so fix this
by skiping already freed memory.

Signed-off-by: Stanimir Varbanov 
---
 drivers/dma/qcom_bam_dma.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
index 5a250cdc8376..dc9da477eb69 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom_bam_dma.c
@@ -1231,6 +1231,9 @@ static int bam_dma_remove(struct platform_device *pdev)
bam_dma_terminate_all(&bdev->channels[i].vc.chan);
tasklet_kill(&bdev->channels[i].vc.task);
 
+   if (!bdev->channels[i].fifo_virt)
+   continue;
+
dma_free_writecombine(bdev->dev, BAM_DESC_FIFO_SIZE,
bdev->channels[i].fifo_virt,
bdev->channels[i].fifo_phys);
-- 
1.7.9.5

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


[PATCH 4/4] dmaengine: qcom_bam_dma: add controlled remotely dt property

2015-12-01 Thread Stanimir Varbanov
Some of the peripherals has bam which is controlled by remote
processor, thus the bam dma driver must avoid register writes
which initialise bam hw block. Those registers are protected
from xPU block and any writes to them will lead to secure
violation and system reboot.

Adding the contolled_remotely flag in bam driver to avoid
not permitted register writes in bam_init function.

Signed-off-by: Stanimir Varbanov 
---
 .../devicetree/bindings/dma/qcom_bam_dma.txt   |2 ++
 drivers/dma/qcom_bam_dma.c |7 +++
 2 files changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt 
b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
index 1c9d48ea4914..87b6b2bf5e1e 100644
--- a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
@@ -13,6 +13,8 @@ Required properties:
 - clock-names: must contain "bam_clk" entry
 - qcom,ee : indicates the active Execution Environment identifier (0-7) used in
   the secure world.
+- qcom,controlled-remotely : optional, indicates that the bam is controled by
+  remote proccessor i.e. execution enviroment.
 
 Example:
 
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
index 6d290de9ab2b..5dedab77180a 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom_bam_dma.c
@@ -387,6 +387,7 @@ struct bam_device {
 
/* execution environment ID, from DT */
u32 ee;
+   bool controlled_remotely;
 
const struct reg_offset_data *layout;
 
@@ -1039,6 +1040,9 @@ static int bam_init(struct bam_device *bdev)
val = readl_relaxed(bam_addr(bdev, 0, BAM_NUM_PIPES));
bdev->num_channels = val & BAM_NUM_PIPES_MASK;
 
+   if (bdev->controlled_remotely)
+   return 0;
+
/* s/w reset bam */
/* after reset all pipes are disabled and idle */
val = readl_relaxed(bam_addr(bdev, 0, BAM_CTRL));
@@ -1126,6 +1130,9 @@ static int bam_dma_probe(struct platform_device *pdev)
return ret;
}
 
+   bdev->controlled_remotely = of_property_read_bool(pdev->dev.of_node,
+   "qcom,controlled-remotely");
+
bdev->bamclk = devm_clk_get(bdev->dev, "bam_clk");
if (IS_ERR(bdev->bamclk))
return PTR_ERR(bdev->bamclk);
-- 
1.7.9.5

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


[PATCH 0/4] bam dma fixes and one dt extension

2015-12-01 Thread Stanimir Varbanov
Here are three bam dma fixes, which I made during testing qcrypto
driver. The first one is a real fix, the second one is related to
peripherals on which the BAM IP is initialized by remote execution
environment, and the third one is a sleeping bug IMO.

The last patch is a extension again for peripherals which BAM is
remotely controlled by other execution environment.

All patches has been tested on db410c board with apq8016.

Comments are welcome!

regards,
Stan

Stanimir Varbanov (4):
  dmaengine: qcom_bam_dma: fix dma free memory on remove
  dmaengine: qcom_bam_dma: clear BAM interrupt only if it is rised
  dmaengine: qcom_bam_dma: use correct pipe FIFO size
  dmaengine: qcom_bam_dma: add controlled remotely dt property

 .../devicetree/bindings/dma/qcom_bam_dma.txt   |2 ++
 drivers/dma/qcom_bam_dma.c |   24 
 2 files changed, 21 insertions(+), 5 deletions(-)

-- 
1.7.9.5

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


[PATCH] PCI: designware: remove wrong io_base assignment

2015-11-24 Thread Stanimir Varbanov
The io_base is used to keep the cpu physical address parsed
from ranges dt property. After issue pci_remap_iospace the
io_base has been assigned with io->start, which is not correct
cause io->start is a PCI bus address.

Fixes: 0021d22b73d6 ("PCI: designware: Use of_pci_get_host_bridge_resources() 
to parse DT")
Reviewed-by: Arnd Bergmann 
Signed-off-by: Stanimir Varbanov 
---
 drivers/pci/host/pcie-designware.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 540f077c37ea..02a7452bdf23 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -440,7 +440,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
 ret, pp->io);
continue;
}
-   pp->io_base = pp->io->start;
break;
case IORESOURCE_MEM:
pp->mem = win->res;
-- 
1.7.9.5

--
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 1/6] PCI: designware: remove wrong io_base assignment

2015-11-24 Thread Stanimir Varbanov
On 11/23/2015 06:40 PM, Arnd Bergmann wrote:
> On Monday 23 November 2015 18:23:47 Stanimir Varbanov wrote:
>>>>
>>>> Fixes: 0021d22b73d6 ("PCI: designware: Use 
>>>> of_pci_get_host_bridge_resources()
>>>> to parse DT")
>>>> Reviewed-by: Arnd Bergmann 
>>
>> I think the bug is introduced in:
>>
>> cbce7900598c ("PCI: designware: Make driver arch-agnostic")
>>
>> cause the io_base is correctly calculated in 0021d22b73d6, do you agree?
> 
> 
> I think cbce7900598c just slightly changes the io_base value, but
> it's still referring to a bus address, not a cpu address, both before
> and after the patch.
> 
> 0021d22b73d6 hower seems to remove the correct 'pp->io_base = range.cpu_addr;'
> and replaces it with 'pp->io_base = pp->io->start;', so it's now in
> the wrong address space.
> 
>   Arnd
> 

OK, I will resend this as separate patch, and will drop it from this series.

-- 
regards,
Stan
--
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 3/6] DT: PCI: qcom: Document PCIe devicetree bindings

2015-11-24 Thread Stanimir Varbanov
Thanks for the comments!

On 11/24/2015 01:17 AM, Rob Herring wrote:
> On Mon, Nov 23, 2015 at 11:29:00AM +0200, Stanimir Varbanov wrote:
>> From: Stanimir Varbanov 
>>
>> Document Qualcomm PCIe driver devicetree bindings.
>>
>> Signed-off-by: Stanimir Varbanov 
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  .../devicetree/bindings/pci/qcom,pcie.txt  |  231 
>> 
>>  1 file changed, 231 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt 
>> b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>> new file mode 100644
>> index ..d7640d45fa31
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>> @@ -0,0 +1,231 @@
>> +* Qualcomm PCI express root complex
>> +
>> +- compatible:
>> +Usage: required
>> +Value type: 
>> +Definition: Value shall include
>> +- "qcom,pcie-v0" for apq/ipq8064
>> +- "qcom,pcie-v1" for apq8084
> 
> Use chip part numbers, not versions.

Sure.

> 
> Also, shouldn't you have the Designware compatible in addition.
> 
> [...]
> 
>> +
>> +- -gpio:
> 
> Use -gpios

Ok I will.

-- 
regards,
Stan
--
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 3/6] DT: PCI: qcom: Document PCIe devicetree bindings

2015-11-24 Thread Stanimir Varbanov
Bjorn, thanks for the comments!

On 11/23/2015 08:13 PM, Bjorn Andersson wrote:
> On Mon 23 Nov 01:29 PST 2015, Stanimir Varbanov wrote:
> 
>> From: Stanimir Varbanov 
>>
>> Document Qualcomm PCIe driver devicetree bindings.
>>
>> Signed-off-by: Stanimir Varbanov 
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  .../devicetree/bindings/pci/qcom,pcie.txt  |  231 
>> 
>>  1 file changed, 231 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt 
>> b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>> new file mode 100644
>> index ..d7640d45fa31
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>> @@ -0,0 +1,231 @@
>> +* Qualcomm PCI express root complex
>> +
>> +- compatible:
>> +Usage: required
>> +Value type: 
>> +Definition: Value shall include
>> +- "qcom,pcie-v0" for apq/ipq8064
>> +- "qcom,pcie-v1" for apq8084
> 
> Do you know if we have the same v1 of this block in 8994?

I have no idea, but looking in caf msm-3.18 it should be possible to
reuse the code for v1.

> 
> [..]
>> +- clock-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain the following entries
>> +* should be populated for v0 and v1
>> +- "iface"  Configuration AHB clock
>> +
>> +* should be populated for v0
>> +- "core"   Clocks the pcie hw block
>> +- "phy"Clocks the pcie PHY block
>> +
>> +* should be populated for v1
>> +- "aux"Auxiliary (AUX) clock
>> +- "bus_master" Master AXI clock
>> +- "bus_slave"  Slave AXI clock
> 
> You have white spaces among your tabs here.

Ops, I forgot to remove the white spaces.

> 
> [..]
>> +- -supply:
>> +Usage: required
>> +Value type: 
>> +Definition: List of phandles to the power supply regulator(s)
>> +* should be populated for v0 and v1
>> +- "vdda"core analog power supply
>> +
>> +* should be populated for v0
>> +- "vdda_phy"analog power supply for PHY
>> +- "vdda_refclk" analog power supply for IC which 
>> generate
>> +reference clock
> 
> Exploding these into 3 different property descriptions would make it
> easier to read, and you can say "required for v0" for the latter
> two and simply "required" on the vdda.

yes, that is a good idea.

> 
> [..]
>> +- -gpio:
>> +Usage: optional
>> +Value type: 
>> +Definition: List of phandle and gpio specifier pairs. Should contain
>> +- "perst"  PCIe endpoint reset signal line
>> +- "pewake" PCIe endpoint wake signal line
> 
> This property should be pluralized, i.e. it's -gpios.

I hope you mean :

- "perst-gpios" PCIe endpoint reset signal line
- "pewake-gpios" PCIe endpoint wake signal line


> 
> Are these identifiers coming from some data sheet? Or could we simply
> name them "reset" and "wakeup"?

In the pcie express card electromechanical specification we have signal
names PERST# and WAKE#, so I'd like to keep as they are in the
specification, thus the wake# is wrong and I will rename it to wake-gpios.

> 
>> +
>> +- pinctrl-0:
>> +Usage: required
>> +Value type: 
>> +Definition: List of phandles pointing at a pin(s) configuration
> 
> This is not required and as it's a property applicable to all devices we
> normally don't mention them.

agreed.

> 
>> +
>> +- pinctrl-names
>> +Usage: required
>> +Value type: 
>> +Definition: List of names of pinctrl-0 state
>> +
> 
> dito
> 
> 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,
Stan
--
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 1/6] PCI: designware: remove wrong io_base assignment

2015-11-23 Thread Stanimir Varbanov
On 11/23/2015 12:27 PM, Gabriele Paoloni wrote:
> Hi Stanimir, Many Thanks for this fix
> 
>> -Original Message-
>> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
>> ow...@vger.kernel.org] On Behalf Of Arnd Bergmann
>> Sent: 23 November 2015 10:00
>> To: Stanimir Varbanov
>> Cc: linux-arm-msm@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm-
>> ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
>> p...@vger.kernel.org; Bjorn Helgaas; Srinivas Kandagatla; Rob Herring; Rob
>> Herring; Mark Rutland; Pawel Moll; Ian Campbell; Jingoo Han; Pratyush Anand;
>> Bjorn Andersson
>> Subject: Re: [PATCH v3 1/6] PCI: designware: remove wrong io_base assignment
>>
>> On Monday 23 November 2015 11:28:58 Stanimir Varbanov wrote:
>>> The io_base is used to keep the cpu physical address parsed
>>> from ranges dt property. After issue pci_remap_iospace the
>>> io_base has been assigned with io->start, which is not correct
>>> cause io->start is a PCI bus address.
>>>
>>> Signed-off-by: Stanimir Varbanov 
>>> ---
>>>  drivers/pci/host/pcie-designware.c |1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-
>> designware.c
>>> index 540f077c37ea..02a7452bdf23 100644
>>> --- a/drivers/pci/host/pcie-designware.c
>>> +++ b/drivers/pci/host/pcie-designware.c
>>> @@ -440,7 +440,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
>>>  ret, pp->io);
>>> continue;
>>> }
>>> -   pp->io_base = pp->io->start;
>>> break;
>>> case IORESOURCE_MEM:
>>> pp->mem = win->res;
>>
>> I was surprised to see such an obvious bug here, as we had spent a lot of
>> time trying to get it right. However, it broke only recently and it's
>> worth mentioning what commit did it, so
> 
> Looking at 
> "[PATCH v12 0/8] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05":
> 
> actually the bug came in as patch 3/6 of v11 patchset split
> 
> [...]
> 
> Change from v11:
> - Split 3/6 in v11 to 3/8, 4/8, 5/8 in v12.
> 
> [...]
> 
> This was not present in v11...sorry about this.
> 
> Gab
> 
>>
>> Fixes: 0021d22b73d6 ("PCI: designware: Use of_pci_get_host_bridge_resources()
>> to parse DT")
>> Reviewed-by: Arnd Bergmann 

I think the bug is introduced in:

cbce7900598c ("PCI: designware: Make driver arch-agnostic")

cause the io_base is correctly calculated in 0021d22b73d6, do you agree?

-- 
regards,
Stan
--
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 2/6] PCI: designware: add memory barrier after enabling region

2015-11-23 Thread Stanimir Varbanov
On 11/23/2015 01:27 PM, Russell King - ARM Linux wrote:
> On Mon, Nov 23, 2015 at 11:28:59AM +0200, Stanimir Varbanov wrote:
>> Add 'write memory' barrier after enable region in PCIE_ATU_CR2
>> register. The barrier is needed to ensure that the region enable
>> request has been reached it's destination at time when we
>> read/write to PCI configuration space.
>>
>> Without this barrier PCI device enumeration during kernel boot
>> is not reliable, and reading configuration space for particular
>> PCI device on the bus returns zero aka no device.
>>
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  drivers/pci/host/pcie-designware.c |5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/pci/host/pcie-designware.c 
>> b/drivers/pci/host/pcie-designware.c
>> index 02a7452bdf23..e15a2ae1583f 100644
>> --- a/drivers/pci/host/pcie-designware.c
>> +++ b/drivers/pci/host/pcie-designware.c
>> @@ -164,6 +164,11 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port 
>> *pp, int index,
>>  dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET);
>>  dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
>>  dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
>> +/*
>> + * ensure that the ATU enable has been happaned before accessing
>> + * pci configuration/io spaces through dw_pcie_cfg_[read|write].
>> + */
>> +smp_wmb();
> 
> So, why is this a SMP barrier?
> 

I wrongly assumed that smp_wmb will come down to wmb(), I have no excuse.

But despite my ignorant, as I noted in cover letter I want this patch to
be treated as an RFC (maybe I had to add it in the subject).

Do we really need a memory barrier after enabling ATU in PCI_ATU_CR2
register and before first access to pci configuration space using
read[lwb] (see dw_pcie_rd_other_conf)? Or I have made totally wrong
assumption.

-- 
regards,
Stan
--
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


[PATCH v3 0/6] Qualcomm PCIe driver and designware fixes

2015-11-23 Thread Stanimir Varbanov
This patch set is continuation of previous v2 at [1]. This time I
decided to drop the PHY driver needed by pcie driver for apq8084
and send it separately soon (when sort out the need of separate phy
driver).

First two patches in the set are fixes in pcie designware driver
found during testing the qcom pcie driver. The second patch can
be treated as an RFC.

Next two patches adds DT binding document and the driver itself.

The last two patches just adds relevant dt node for apq8064 and
enable pcie usage on ifc6410 development board. The testing has been
made on ifc6410 development board.

Comments are welcome!

Here is edited description:

This patchset introduces a Qualcomm PCIe root complex driver for
Snapdragon 805 (APQ8084) and Snapdragon 600 (APQ8064). The PCIe
hardware use Designware IP core plus Qualcomm application
specific hw wrappers.

[1] https://lkml.org/lkml/2015/5/4/267

Stanimir Varbanov (6):
  PCI: designware: remove wrong io_base assignment
  PCI: designware: add memory barrier after enabling region
  DT: PCI: qcom: Document PCIe devicetree bindings
  PCI: qcom: Add Qualcomm PCIe controller driver
  ARM: dts: apq8064: add pcie devicetree node
  ARM: dts: ifc6410: enable pcie dt node for this board

 .../devicetree/bindings/pci/qcom,pcie.txt  |  231 
 MAINTAINERS|7 +
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   26 +
 arch/arm/boot/dts/qcom-apq8064.dtsi|   36 ++
 drivers/pci/host/Kconfig   |   10 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pcie-designware.c |6 +-
 drivers/pci/host/pcie-qcom.c   |  623 
 8 files changed, 939 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt
 create mode 100644 drivers/pci/host/pcie-qcom.c

-- 
1.7.9.5

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


[PATCH v3 1/6] PCI: designware: remove wrong io_base assignment

2015-11-23 Thread Stanimir Varbanov
The io_base is used to keep the cpu physical address parsed
from ranges dt property. After issue pci_remap_iospace the
io_base has been assigned with io->start, which is not correct
cause io->start is a PCI bus address.

Signed-off-by: Stanimir Varbanov 
---
 drivers/pci/host/pcie-designware.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 540f077c37ea..02a7452bdf23 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -440,7 +440,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
 ret, pp->io);
continue;
}
-   pp->io_base = pp->io->start;
break;
case IORESOURCE_MEM:
pp->mem = win->res;
-- 
1.7.9.5

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


[PATCH v3 5/6] ARM: dts: apq8064: add pcie devicetree node

2015-11-23 Thread Stanimir Varbanov
Add the pcie dt node so that it can probe and used.

Signed-off-by: Stanimir Varbanov 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi |   36 +++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index a4c1762b53ea..bb7181e8ef2f 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -659,5 +659,41 @@
compatible = "qcom,tcsr-apq8064", "syscon";
reg = <0x1a40 0x100>;
};
+
+   pcie: pci@1b50 {
+   compatible = "qcom,pcie-v0", "snps,dw-pcie";
+   reg = <0x1b50 0x1000
+  0x1b502000 0x80
+  0x1b60 0x100
+  0x0ff0 0x10>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   ranges = <0x8100 0 0 0x0fe0 0 0x0010   /* 
I/O */
+ 0x8200 0 0 0x0800 0 0x07e0>; /* 
memory */
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1 &intc 0 36 
IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2 &intc 0 37 
IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3 &intc 0 38 
IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4 &intc 0 39 
IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+   clocks = <&gcc PCIE_A_CLK>,
+<&gcc PCIE_H_CLK>,
+<&gcc PCIE_PHY_REF_CLK>;
+   clock-names = "core", "iface", "phy";
+   resets = <&gcc PCIE_ACLK_RESET>,
+<&gcc PCIE_HCLK_RESET>,
+<&gcc PCIE_POR_RESET>,
+<&gcc PCIE_PCI_RESET>,
+<&gcc PCIE_PHY_RESET>;
+   reset-names = "axi", "ahb", "por", "pci", "phy";
+   status = "disabled";
+   };
};
 };
-- 
1.7.9.5

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


[PATCH v3 3/6] DT: PCI: qcom: Document PCIe devicetree bindings

2015-11-23 Thread Stanimir Varbanov
From: Stanimir Varbanov 

Document Qualcomm PCIe driver devicetree bindings.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Stanimir Varbanov 
---
 .../devicetree/bindings/pci/qcom,pcie.txt  |  231 
 1 file changed, 231 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt 
b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
new file mode 100644
index ..d7640d45fa31
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
@@ -0,0 +1,231 @@
+* Qualcomm PCI express root complex
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Value shall include
+   - "qcom,pcie-v0" for apq/ipq8064
+   - "qcom,pcie-v1" for apq8084
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: Register ranges as listed in the reg-names property
+
+- reg-names:
+   Usage: required
+   Value type: 
+   Definition: Must include the following entries
+   - "parf"   Qualcomm specific registers
+   - "dbi"Designware PCIe registers
+   - "elbi"   External local bus interface registers
+   - "config" PCIe configuration space
+
+- device_type:
+   Usage: required
+   Value type: 
+   Definition: Should be "pci". As specified in designware-pcie.txt
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: Should be set to 3. As specified in designware-pcie.txt
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: Should be set 2. As specified in designware-pcie.txt
+
+- ranges:
+   Usage: required
+   Value type: 
+   Definition: As specified in designware-pcie.txt
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: MSI interrupt
+
+- interrupt-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain "msi"
+
+- #interrupt-cells:
+   Usage: required
+   Value type: 
+   Definition: Should be 1. As specified in designware-pcie.txt
+
+- interrupt-map-mask:
+   Usage: required
+   Value type: 
+   Definition: As specified in designware-pcie.txt
+
+- interrupt-map:
+   Usage: required
+   Value type: 
+   Definition: As specified in designware-pcie.txt
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: List of phandle and clock specifier pairs as listed
+   in clock-names property
+
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain the following entries
+   * should be populated for v0 and v1
+   - "iface"  Configuration AHB clock
+
+   * should be populated for v0
+   - "core"   Clocks the pcie hw block
+   - "phy"Clocks the pcie PHY block
+
+   * should be populated for v1
+   - "aux"Auxiliary (AUX) clock
+   - "bus_master" Master AXI clock
+   - "bus_slave"  Slave AXI clock
+
+- resets:
+   Usage: required
+   Value type: 
+   Definition: List of phandle and reset specifier pairs as listed
+   in reset-names property
+
+- reset-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain the following entries
+   * should be populated for v0
+   - "axi"  AXI reset
+   - "ahb"  AHB reset
+   - "por"  POR reset
+   - "pci"  PCI reset
+   - "phy"  PHY reset
+
+   * should be populated for v1
+   - "core" Core reset
+
+- power-domains:
+   Usage: required (for v1 only)
+   Value type: 
+   Definition: A phandle and power domain specifier pair to the
+   power domain which is responsible for collapsing
+   and restoring power to the peripheral
+
+- -supply:
+   Usage: required
+   Value type: 
+   Definition: List of phandles to the power supply regulator(s)
+   * should be populated for v0 and v1
+   - "vdda"core analog power supply
+
+   * should be populated for v0
+   - "vdda_phy"analog power supply for PHY
+   - "vdda_refclk" analog power supply for IC which 
generate
+   reference clock
+
+- phys:
+   Usage: required (for v1 only)
+   Value typ

[PATCH v3 4/6] PCI: qcom: Add Qualcomm PCIe controller driver

2015-11-23 Thread Stanimir Varbanov
From: Stanimir Varbanov 

The PCIe driver reuse the Designware common code for host
and MSI initialization, and also program the Qualcomm
application specific registers.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Stanimir Varbanov 
---
 MAINTAINERS  |7 +
 drivers/pci/host/Kconfig |   10 +
 drivers/pci/host/Makefile|1 +
 drivers/pci/host/pcie-qcom.c |  623 ++
 4 files changed, 641 insertions(+)
 create mode 100644 drivers/pci/host/pcie-qcom.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b16bffabe70a..878d9068fe75 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8231,6 +8231,13 @@ S:   Maintained
 F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F: drivers/pci/host/pcie-hisi.c
 
+PCIE DRIVER FOR QUALCOMM MSM
+M: Stanimir Varbanov 
+L: linux-...@vger.kernel.org
+L: linux-arm-msm@vger.kernel.org
+S: Maintained
+F: drivers/pci/host/*qcom*
+
 PCMCIA SUBSYSTEM
 P: Linux PCMCIA Team
 L: linux-pcm...@lists.infradead.org
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index f131ba947dc6..64d33ba3e336 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -172,4 +172,14 @@ config PCI_HISI
help
  Say Y here if you want PCIe controller support on HiSilicon HIP05 SoC
 
+config PCIE_QCOM
+   bool "Qualcomm PCIe controller"
+   depends on ARCH_QCOM && OF || COMPILE_TEST
+   select PCIE_DW
+   select PCIEPORTBUS
+   help
+ Say Y here to enable PCIe controller support on Qualcomm SoCs. The
+ PCIe controller use Designware core plus Qualcomm specific hardware
+ wrappers.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 9d4d3c6924a1..e523c171febf 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
+obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
new file mode 100644
index ..5f1957988503
--- /dev/null
+++ b/drivers/pci/host/pcie-qcom.c
@@ -0,0 +1,623 @@
+/*
+ * Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ * Copyright 2015 Linaro Limited.
+ *
+ * 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 
+#include 
+
+#include "pcie-designware.h"
+
+#define PCIE20_PARF_PHY_CTRL   0x40
+#define PCIE20_PARF_PHY_REFCLK 0x4C
+#define PCIE20_PARF_DBI_BASE_ADDR  0x168
+#define PCIE20_PARF_SLV_ADDR_SPACE_SIZE0x16c
+#define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT  0x178
+
+#define PCIE20_ELBI_SYS_CTRL   0x04
+#define PCIE20_ELBI_SYS_CTRL_LT_ENABLE BIT(0)
+
+#define PCIE20_ELBI_SYS_STTS   0x08
+#define XMLH_LINK_UP   BIT(10)
+
+#define PCIE20_CAP 0x70
+#define PCIE20_CAP_LINKCTRLSTATUS  (PCIE20_CAP + 0x10)
+#define PCIE20_CAP_LINKCTRLSTATUS_LINK_UP  BIT(29)
+
+#define PERST_DELAY_MS 1
+
+#define LINKUP_DELAY_US5000
+#define LINKUP_TIMEOUT_US  10
+
+struct qcom_pcie_resources_v0 {
+   struct clk *iface_clk;
+   struct clk *core_clk;
+   struct clk *phy_clk;
+   struct reset_control *pci_reset;
+   struct reset_control *axi_reset;
+   struct reset_control *ahb_reset;
+   struct reset_control *por_reset;
+   struct reset_control *phy_reset;
+   struct regulator *vdda;
+   struct regulator *vdda_phy;
+   struct regulator *vdda_refclk;
+};
+
+struct qcom_pcie_resources_v1 {
+   struct clk *iface;
+   struct clk *aux;
+   struct clk *master_bus;
+   struct clk *slave_bus;
+   struct reset_control *core;
+   struct regulator *vdda;
+};
+
+union qcom_pcie_resources {
+   struct qcom_pcie_resources_v0 v0;
+   struct qcom_pcie_resources_v1 v1;
+};
+
+struct qcom_pcie;
+
+struct qcom_pcie_ops {
+   int (*get_resources)(struct qcom_pcie *pcie);
+   int (*init)(struct qcom_pcie *pcie);
+   void (*deinit)(struct qcom_pcie *pcie);
+};
+
+struc

[PATCH v3 2/6] PCI: designware: add memory barrier after enabling region

2015-11-23 Thread Stanimir Varbanov
Add 'write memory' barrier after enable region in PCIE_ATU_CR2
register. The barrier is needed to ensure that the region enable
request has been reached it's destination at time when we
read/write to PCI configuration space.

Without this barrier PCI device enumeration during kernel boot
is not reliable, and reading configuration space for particular
PCI device on the bus returns zero aka no device.

Signed-off-by: Stanimir Varbanov 
---
 drivers/pci/host/pcie-designware.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 02a7452bdf23..e15a2ae1583f 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -164,6 +164,11 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port 
*pp, int index,
dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET);
dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
+   /*
+* ensure that the ATU enable has been happaned before accessing
+* pci configuration/io spaces through dw_pcie_cfg_[read|write].
+*/
+   smp_wmb();
 }
 
 static struct irq_chip dw_msi_irq_chip = {
-- 
1.7.9.5

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


[PATCH v3 6/6] ARM: dts: ifc6410: enable pcie dt node for this board

2015-11-23 Thread Stanimir Varbanov
Enable pcie dt node and fill pcie dt node with regulator, pinctrl
and reset gpio, to use the pcie on the ifc6410 board.

Signed-off-by: Stanimir Varbanov 
---
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 11ac608b6d50..bdee36a9b418 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -47,6 +47,18 @@
bias-disable;
};
};
+
+   pcie0_pins: pcie0_pinmux {
+   mux {
+   pins = "gpio27";
+   function = "gpio";
+   };
+   conf {
+   pins = "gpio27";
+   drive-strength = <12>;
+   bias-disable;
+   };
+   };
};
 
rpm@108000 {
@@ -123,6 +135,10 @@
pm8921_lvs1: lvs1 {
bias-pull-down;
};
+
+   pm8921_lvs6: lvs6 {
+   bias-pull-down;
+   };
};
};
 
@@ -231,6 +247,16 @@
status = "okay";
};
 
+   pci@1b50 {
+   status = "ok";
+   vdda-supply = <&pm8921_s3>;
+   vdda_phy-supply = <&pm8921_lvs6>;
+   vdda_refclk-supply = <&ext_3p3v>;
+   pinctrl-0 = <&pcie0_pins>;
+   pinctrl-names = "default";
+   perst-gpio = <&tlmm_pinmux 27 GPIO_ACTIVE_LOW>;
+   };
+
qcom,ssbi@50 {
pmic@0 {
gpio@150 {
-- 
1.7.9.5

--
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 v2 4/5] PCI: qcom: Add Qualcomm PCIe controller driver

2015-11-09 Thread Stanimir Varbanov
Hi Bjorn,

On 11/06/2015 10:50 PM, Bjorn Andersson wrote:
> On Mon 04 May 05:42 PDT 2015, Stanimir Varbanov wrote:
> 
>> The PCIe driver reuse the Designware common code for host
>> and MSI initialization, and also program the Qualcomm
>> application specific registers.
>>
> 
> I want to get the ethernet on the ifc6410 running and this seems like
> the last patchset for the PCIe.
> 
>> Signed-off-by: Stanimir Varbanov 
> [..]
>> diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
>> new file mode 100644
>> index 000..4f083c6
>> --- /dev/null
>> +++ b/drivers/pci/host/pcie-qcom.c
>> @@ -0,0 +1,677 @@
>> +/*
>> + * Copyright (c) 2014, The Linux Foundation. All rights reserved.
> 
> Bump the year, it's the future now :)

yep, thanks for the valuable comments I will address all of them on next
version.

I will probably restart the work on the driver this week.

-- 
regards,
Stan
--
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] soc/qcom: add OCMEM driver

2015-10-23 Thread Stanimir Varbanov
Hi Rob,

On 10/13/2015 12:45 AM, Rob Clark wrote:
> The OCMEM driver handles allocation and configuration of the On Chip
> MEMory that is present on some snapdragon devices.
> 
> Devices which have OCMEM do not have GMEM inside the gpu core, so the
> gpu must instead use OCMEM to be functional.  Since currently the gpu
> is the only OCMEM user with an upstream driver, this is just a minimal
> implementation sufficient for statically allocating to the gpu it's
> chunk of OCMEM.
> 
> v2: minor updates from review comments (use devm_ioremap_resource(),
> devm_clk_get() doesn't return NULL, etc..)
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/soc/qcom/Kconfig |   6 +
>  drivers/soc/qcom/Makefile|   1 +
>  drivers/soc/qcom/ocmem.c | 401 
> +++
>  drivers/soc/qcom/ocmem.xml.h | 106 
>  include/soc/qcom/ocmem.h |  40 +
>  5 files changed, 554 insertions(+)
>  create mode 100644 drivers/soc/qcom/ocmem.c
>  create mode 100644 drivers/soc/qcom/ocmem.xml.h
>  create mode 100644 include/soc/qcom/ocmem.h
> 
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 266060b..b485043 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -74,3 +74,9 @@ config QCOM_WCNSS_CTRL
>   help
> Client driver for the WCNSS_CTRL SMD channel, used to download nv
> firmware to a newly booted WCNSS chip.
> +
> +config QCOM_OCMEM
> + tristate "Qualcomm OCMEM driver"
> + depends on QCOM_SMD

Why this driver depends on SMD, I cannot see where smd is used here.

Maybe depends on ARCH_QCOM should be sufficient?

> + help
> +   Allocator for OCMEM (On Chip MEMory).
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index fdd664e..940bb35 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
>  obj-$(CONFIG_QCOM_SMP2P) += smp2p.o
>  obj-$(CONFIG_QCOM_SMSM)  += smsm.o
>  obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
> +obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
> diff --git a/drivers/soc/qcom/ocmem.c b/drivers/soc/qcom/ocmem.c
> new file mode 100644
> index 000..506a072
> --- /dev/null
> +++ b/drivers/soc/qcom/ocmem.c
> @@ -0,0 +1,401 @@
> +/*
> + * Copyright (C) 2015 Red Hat
> + * Author: Rob Clark 
> + *
> + * 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.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Do we need to update the Kconfig to enable/depend on scm driver?

> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include "ocmem.xml.h"
> +
> +enum region_mode {
> + WIDE_MODE = 0x0,
> + THIN_MODE,
> + MODE_DEFAULT = WIDE_MODE,
> +};
> +
> +struct ocmem_region {
> + unsigned psgsc_ctrl;

this is not used

> + bool interleaved;
> + enum region_mode mode;
> + unsigned int num_macros;
> + enum ocmem_macro_state macro_state[4];
> + unsigned long macro_size;
> + unsigned long region_size;
> +};
> +



> +
> +static const struct of_device_id ocmem_dt_match[] = {
> + { .compatible = "qcom,ocmem-msm8974", .data = &ocmem_8974_config },
> + {}
> +};
> +
> +static int ocmem_dev_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + const struct ocmem_config *config = NULL;
> + const struct of_device_id *match;
> + struct resource *res;
> + uint32_t reg, num_banks, region_size;
> + int i, j, ret;
> +
> + /* we need scm to be available: */
> + if (!qcom_scm_is_available())
> + return -EPROBE_DEFER;
> +
> + match = of_match_device(ocmem_dt_match, dev);
> + if (match)
> + config = match->data;
> +
> + if (!config) {
> + dev_err(dev, "unknown config: %s\n", dev->of_node->name);
> + return -ENXIO;
> + }
> +
> + ocmem = devm_kzalloc(dev, sizeof(*ocmem), GFP_KERNEL);
> + if (!ocmem)
> + return -ENOMEM;
> +
> + ocmem->dev = dev;
> + ocmem->config = config;
> +
> + ocmem->core_clk = devm_clk_get(dev, "core_clk");

We have a convention to avoid _clk suffix for qcom clocks in dt nodes.

> + if (IS_ERR(ocmem->core_clk)) {
> + dev_info(dev, "Unable to get the core clock\n");
> + return PTR_ERR(ocmem->core_clk);
> + }
> +
> + ocmem->iface_clk = devm_

Re: [PATCH] soc/qcom: add OCMEM driver

2015-10-06 Thread Stanimir Varbanov
Hi Rob,



> +
> +struct ocmem_config {
> + uint8_t  num_regions;

u8

> + uint32_t macro_size;

u32


> +static const struct ocmem_config ocmem_8974_config = {
> + .num_regions = 3, .macro_size = SZ_128K,
> +};
> +
> +static const struct of_device_id ocmem_dt_match[] = {
> + { .compatible = "qcom,ocmem-msm8974", .data = &ocmem_8974_config },

Just a suggestion. As we have REG_OCMEM_HW_PROFILE and
REG_OCMEM_HW_VERSION register why not distinguish by version and hw
profile instead of SoC?

> + {}
> +};
> +
> +static int ocmem_dev_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + const struct ocmem_config *config = NULL;
> + const struct of_device_id *match;
> + struct resource *res;
> + uint32_t reg, num_banks, region_size;
> + int i, j, ret;
> +
> + /* we need scm to be available: */
> + if (!qcom_scm_is_available())
> + return -EPROBE_DEFER;
> +
> + match = of_match_device(ocmem_dt_match, dev);
> + if (match)
> + config = match->data;
> +
> + if (!config) {
> + dev_err(dev, "unknown config: %s\n", dev->of_node->name);
> + return -ENXIO;
> + }
> +
> + ocmem = devm_kzalloc(dev, sizeof(*ocmem), GFP_KERNEL);
> + if (!ocmem)
> + return -ENOMEM;
> +
> + ocmem->dev = dev;
> + ocmem->config = config;
> +
> + ocmem->core_clk = devm_clk_get(dev, "core_clk");
> + if (IS_ERR(ocmem->core_clk)) {
> + dev_err(dev, "Unable to get the core clock\n");

this dev_err will flood console in EPROBE_DEFER case, IMO should be removed.

> + return PTR_ERR(ocmem->core_clk);
> + }
> +
> + ocmem->iface_clk = devm_clk_get(dev, "iface_clk");
> + if (IS_ERR_OR_NULL(ocmem->iface_clk)) {
> + ret = PTR_ERR(ocmem->iface_clk);
> + ocmem->iface_clk = NULL;
> + /* in probe-defer case, propagate error up and try again later: 
> */
> + if (ret == -EPROBE_DEFER)
> + goto fail;

Why error path of the iface clock is different comparing with core clk.
Also I failed to found a case when common clk framework will return NULL?

if (IS_ERR(ocmem->iface_clk)
return PTR_ERR(ocmem->iface_clk);

this should be enough.

> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + "ocmem_ctrl_physical");
> + if (!res) {
> + dev_err(&pdev->dev, "failed to get memory resource\n");
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + ocmem->mmio = devm_ioremap_nocache(&pdev->dev, res->start,
> + resource_size(res));

I think you could use following to simplify ioremap:

res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
"ocmem_ctrl_physical");
ocmem->mmio = devm_ioremap_resource(dev, res);
if (IS_ERR(ocmem->mmio))
return PTR_ERR(ocmem->mmio);

> + if (IS_ERR(ocmem->mmio)) {
> + dev_err(&pdev->dev, "failed to ioremap memory resource\n");
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + ocmem->ocmem_mem = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + "ocmem_physical");
> + if (!ocmem->ocmem_mem) {
> + dev_err(dev, "could not get OCMEM region\n");
> + return -ENXIO;
> + }
> +



-- 
regards,
Stan
--
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 6/6] drm/msm: add OCMEM driver

2015-10-01 Thread Stanimir Varbanov
On 09/30/2015 02:45 PM, Rob Clark wrote:
> On Wed, Sep 30, 2015 at 7:31 AM, Rob Clark  wrote:
>> On Wed, Sep 30, 2015 at 3:51 AM, Stanimir Varbanov
>>  wrote:
>>> Hi Rob,
>>>
>>> Thanks for your work.
>>>
>>> On 09/29/2015 10:48 PM, Rob Clark wrote:
>>>> For now, since the GPU is the only upstream consumer, just stuff this
>>>> into drm/msm.  Eventually if we have other consumers, we'll have to
>>>
>>> As the video encoder/decoder driver (vidc) for apq8084 && msm8974 also
>>> use the ocmem for scratch buffers, it might be better to relocate the
>>> ocmem driver in drivers/soc/qcom from the beginning?
>>
>> I wasn't really sure how soon vidc would support 8084/8974 (I assume
>> first target is 8916 which fortunately doesn't have ocmem), or if it

My expectations are that the same driver will work on apq8084, as well.

>> was mandatory or just power optimization..  but yes, the plan was to
>> move it somewhere else (not sure quite where, drivers/doc/qcom?)
>> sometime..  Preferably when someone who understands all the other
>> ocmem use-cases better could figure out what we really need to add to
>> the driver.
>>
>> In downstream driver there is a lot of complexity that appears to be
>> in order to allow two clients to each allocate a portion of a macro
>> within a region (ie. aggregate_macro_state(), apply_macro_vote(),
>> etc), and I wanted to figure out if that is even a valid use-case
>> before trying to make ocmem something that could actually support
>> multiple clients.
>>
>> There is also some complexity about ensuring that if clients aren't
>> split up on region boundaries, that you don't have one client in
>> region asking for wide-mode and other for narrow-mode..
>> (switch_region_mode()) but maybe we could handle that by just
>> allocating wide from bottom and narrow from top.  Also seems to be
>> some craziness for allowing one client to pre-empt/evict another.. a
>> dm engine, etc, etc..
>>
>> All I know is gpu just statically allocates one big region aligned
>> chunk of ocmem, so I ignored the rest of the crazy (maybe or maybe not
>> hypothetical) use-cases for now...

OK, I will try to sort out ocmem use cases for vidc driver.

> 
> btw, I should add that I don't mind adding it in drivers/soc/qcom (or
> somewhere else?) to start with if others prefer, I just didn't want to
> give the wrong impression that it is ready yet for multiple clients.

I see. Then to avoid confusions you could remove all clients and keep
only graphics from ocmem_client enum.

> 
> All I know is the gpu uses it statically and is pretty much useless
> without ocmem, so for lack of understanding of the other use cases I
> just tried to add simply what the gpu needs..

Got it now, thanks.

-- 
regards,
Stan
--
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 6/6] drm/msm: add OCMEM driver

2015-09-30 Thread Stanimir Varbanov
Hi Rob,

Thanks for your work.

On 09/29/2015 10:48 PM, Rob Clark wrote:
> For now, since the GPU is the only upstream consumer, just stuff this
> into drm/msm.  Eventually if we have other consumers, we'll have to

As the video encoder/decoder driver (vidc) for apq8084 && msm8974 also
use the ocmem for scratch buffers, it might be better to relocate the
ocmem driver in drivers/soc/qcom from the beginning?

I'm working on vidc driver upstream version so it will be nice to test
ocmem driver from it, too.

> split this out and make the allocation less hard coded.  But I'll punt
> on that until I better understand the non-gpu uses-cases (and whether
> the allocation *really* needs to be as complicated as it is in the
> downstream driver).
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/Makefile  |   3 +-
>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c |  19 +-
>  drivers/gpu/drm/msm/adreno/a4xx_gpu.c |  19 +-
>  drivers/gpu/drm/msm/msm_drv.c |   2 +
>  drivers/gpu/drm/msm/msm_gpu.h |   3 +
>  drivers/gpu/drm/msm/ocmem/ocmem.c | 399 
> ++
>  drivers/gpu/drm/msm/ocmem/ocmem.h |  46 
>  7 files changed, 463 insertions(+), 28 deletions(-)
>  create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.c
>  create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.h
> 



-- 
regards,
Stan
--
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 1/4] dt-binding: gpio: Add Qualcomm SMSM device tree documentation

2015-09-01 Thread Stanimir Varbanov
On 08/27/2015 08:37 PM, Bjorn Andersson wrote:
> This documents a device tree binding for exposing the Qualcomm Shared
> Memory State Machine as a set of gpio- and interrupt-controllers.
> 
> Signed-off-by: Bjorn Andersson 
> ---
>  .../devicetree/bindings/gpio/qcom,smsm.txt | 114 
> +



> += EXAMPLE
> +The following example shows the SMEM setup for controlling properties of the
> +wireless processor, defined from the 8974 apps processor's point-of-view. It
> +encompasses one outbound entry and the outgoing interrupt for the wireless
> +processor.
> +
> +smsm {
> + compatible = "qcom,smsm";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + qcom,ipc-3 = <&apcs 8 19>;

Can we use something more descriptive here, for example

qcom,ipc-rpm = <&apcs 8 19>;

and replace these magic numbers with defines?

> +
> + apps_smsm: apps@0 {
> + reg = <0>;
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> + wcnss_smsm: wcnss@7 {
> + reg = <7>;
> + interrupts = <0 144 1>;
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +};


-- 
regards,
Stan
--
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 v2] soc: qcom: smd: Use correct remote processor ID

2015-08-27 Thread Stanimir Varbanov
On 08/26/2015 10:42 PM, Andy Gross wrote:
> This patch fixes SMEM addressing issues when remote processors need to use
> secure SMEM partitions.
> 
> Signed-off-by: Andy Gross 
> ---
>  .../devicetree/bindings/soc/qcom/qcom,smd.txt  |6 ++
>  drivers/soc/qcom/smd.c |   15 +++
>  2 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt 
> b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> index f65c76d..97d9b3e 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> @@ -37,6 +37,12 @@ The edge is described by the following properties:
>   Definition: the identifier of the remote processor in the smd channel
>   allocation table
>  
> +- qcom,remote-pid:
> + Usage: optional
> + Value type: 
> + Definition: the identifier for the remote processor as known by the rest
> + of the system.
> +
>  = SMD DEVICES
>  
>  In turn, subnodes of the "edges" represent devices tied to SMD channels on 
> that
> diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
> index 327adcf..5706a81 100644
> --- a/drivers/soc/qcom/smd.c
> +++ b/drivers/soc/qcom/smd.c
> @@ -111,6 +111,7 @@ struct qcom_smd_edge {
>   struct qcom_smd *smd;
>   struct device_node *of_node;
>   unsigned edge_id;
> + unsigned remote_pid;

Andy, you forgot to add this new field in structure description header.



-- 
regards,
Stan
--
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


[PATCH] arm64: dts: qcom: Add RNG device tree node

2015-08-25 Thread Stanimir Varbanov
Adds rng device tree node for msm8916 SoCs.

Signed-off-by: Stanimir Varbanov 
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 0f49ebd0aa8b..060c6c53ff33 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -215,5 +215,12 @@
interrupt-controller;
#interrupt-cells = <4>;
};
+
+   rng@22000 {
+   compatible = "qcom,prng";
+   reg = <0x00022000 0x200>;
+   clocks = <&gcc GCC_PRNG_AHB_CLK>;
+   clock-names = "core";
+   };
};
 };
-- 
1.7.9.5

--
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 v7 12/13] clk: qcom: gdsc: Add GDSCs in apq8084 MMCC

2015-07-31 Thread Stanimir Varbanov



>  
> +static struct gdsc venus0_gdsc = {
> + .gdscr = 0x1024,
> + .pd = {
> + .name = "venus0",
> + },
> + .pwrsts = PWRSTS_OFF_ON,
> + .con_ids = { NULL },
> +};
> +

Rajendra, according to downstream kernel apq8084 has second instance of
gdsc i.e. venus1_gdsc, is that correct?


-- 
regards,
Stan
--
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: drm: msm: run into issues

2015-07-23 Thread Stanimir Varbanov
On 07/23/2015 06:59 PM, Rob Clark wrote:
> On Thu, Jul 23, 2015 at 5:02 AM, Stanimir Varbanov
>  wrote:
>> Hi Rob,
>>
>> I run into issues with msm drm driver while implementing a test
>> application which use v4l2 vidc (venus) decoder driver to decode videos
>> and msm drm driver to display the decoded frames. The v4l2 test
>> application use msm drm as dmabuf exporter by DRM_IOCTL_MODE_CREATE_DUMB
>> and DRM_IOCTL_PRIME_HANDLE_TO_FD from libdrm.
>>
>> So far the test app is able to decode and display using dmabuf type of
>> buffers (so, to honest it is slower than using mmap & memcpy but this is
>> another story). The problems start when destroying drm buffers by call
>> to DRM_IOCTL_MODE_DESTROY_DUMB ioctl and also when closing dmabuf fd.
>> The issues I'm seeing are:
>>
>> - the first and the major one happens in msm_gem_free_object() where we
>> are trying to free sg table which table is already freed by drm_prime
>> core in dmabuf .detach callback. In fact the msm_gem_free_object is
>> called by dmabuf .release callback which should be happened after
>> .detach. I find weird to call sg_table_free in .detach callback and did
>> not understand why it is there.
> 
> so, I think in msm_gem_prime_get_sg_table() we need to create a
> duplicate sgt.. since dma_buf_map_attachment() (and therefore
> ->gem_prime_get_sg_table()) returns ownership of the sgt.  So it is
> not correct to be returning our own internal copy.
> 
>> - the second one is again in msm_gem.c::put_pages dma_unmap_sg call.
>> Some background, vidc (venus) driver use dma-iommu infrastructure copped
>> from qcom downstream kernel to abstract iommu map/unmap [1].
>> On the other side when drm driver is exporter it use swiotbl [2] dma map
>> operations, dma_map_sg will fill sg->dma_address with phy addresses. So
>> when vidc call dma_map_sg the sg dma_address is filled with iova address
>> then drm call dma_unmap_sg expecting phy addresses.
> 
> hmm.. so drm_gem_map_dma_buf() should dma_map_sg() using attach->dev
> (which should be vidc, not drm).  Maybe something unexepected was
> happening there since we were incorrectly returning our own sgt (which
> had already been dma_map_sg()'d w/ the drm device for cache
> maintenance?

In fact this is consequence of the first issue.

> 
> Could you try:
> 
> -
> diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c
> b/drivers/gpu/drm/msm/msm_gem_prime.c
> index dd7a7ab..831461b 100644
> --- a/drivers/gpu/drm/msm/msm_gem_prime.c
> +++ b/drivers/gpu/drm/msm/msm_gem_prime.c
> @@ -23,8 +23,12 @@
>  struct sg_table *msm_gem_prime_get_sg_table(struct drm_gem_object *obj)
>  {
>  struct msm_gem_object *msm_obj = to_msm_bo(obj);
> -BUG_ON(!msm_obj->sgt);  /* should have already pinned! */
> -return msm_obj->sgt;
> +int npages = obj->size >> PAGE_SHIFT;
> +
> +if (WARN_ON(!msm_obj->pages))  /* should have already pinned! */
> +return NULL;
> +
> +return drm_prime_pages_to_sg(msm_obj->pages, npages);
>  }
> 

Brilliant diff, duplicating sgt fixed both issues!

Care to fix this in mainline?

-- 
regards,
Stan
--
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 v6 03/13] clk: qcom: gdsc: Use PM clocks to control gdsc clocks

2015-07-23 Thread Stanimir Varbanov
On 07/23/2015 11:34 AM, Rajendra Nayak wrote:
> On 07/23/2015 06:31 AM, Stephen Boyd wrote:
>> On 07/22/2015 12:10 AM, Rajendra Nayak wrote:
>>> @@ -104,6 +105,37 @@ static int gdsc_disable(struct generic_pm_domain
>>> *domain)
>>>   return gdsc_toggle_logic(sc, false);
>>>   }
>>> +static int gdsc_attach(struct generic_pm_domain *domain, struct
>>> device *dev)
>>> +{
>>> +int ret;
>>> +struct gdsc *sc = domain_to_gdsc(domain);
>>> +char **con_id, *con_ids[] = { "core", "iface", NULL };
>>
>> const?
>>
>> This is where I get scared of sniffing too much SoC glue. What's to
>> enforce the "core", and "iface" naming scheme? What's to enforce there
>> being two clocks vs. one? Maybe a better approach would be to use
>> of_clk_get() and iterate through all clocks of the device, or to encode
>> the clock names in the gdsc structure.
> 
> I had the clock names in the gdsc structure in v5. I should probably go
> back to having it that way.

Rajendra, If you decide to go back please look at that comment [1], as well.

-- 
regards,
Stan

[1] http://www.spinics.net/lists/linux-arm-msm/msg15040.html
--
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 v6 01/13] clk: qcom: Add support for GDSCs

2015-07-23 Thread Stanimir Varbanov


>> +
>> +int gdsc_register(struct device *dev, struct gdsc **scs, size_t num,
>> +  struct regmap *regmap)
>> +{
>> +int i, ret;
>> +struct genpd_onecell_data *data;
>> +
>> +data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>> +if (!data)
>> +return -ENOMEM;
>> +
>> +data->domains = devm_kcalloc(dev, num, sizeof(*data->domains),
>> + GFP_KERNEL);
>> +if (!data->domains)
>> +return -ENOMEM;
>> +
>> +data->num_domains = num;
>> +for (i = 0; i < num; i++) {
>> +if (!scs[i])
>> +continue;
>> +scs[i]->regmap = regmap;
>> +ret = gdsc_init(scs[i]);
>> +if (ret)
>> +return ret;
>> +data->domains[i] = &scs[i]->pd;
>> +}
>> +
>> +return of_genpd_add_provider_onecell(dev->of_node, data);
>> +}
> 
> EXPORT_SYMBOL?
> 
>> +
>> +void gdsc_unregister(struct device *dev)
>> +{
>> +of_genpd_del_provider(dev->of_node);
>> +}
> 
> EXPORT_SYMBOL?

Stephen, gdsc_register/unregister are internal to the qcom clk driver
why to export them?

-- 
regards,
Stan
--
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


drm: msm: run into issues

2015-07-23 Thread Stanimir Varbanov
Hi Rob,

I run into issues with msm drm driver while implementing a test
application which use v4l2 vidc (venus) decoder driver to decode videos
and msm drm driver to display the decoded frames. The v4l2 test
application use msm drm as dmabuf exporter by DRM_IOCTL_MODE_CREATE_DUMB
and DRM_IOCTL_PRIME_HANDLE_TO_FD from libdrm.

So far the test app is able to decode and display using dmabuf type of
buffers (so, to honest it is slower than using mmap & memcpy but this is
another story). The problems start when destroying drm buffers by call
to DRM_IOCTL_MODE_DESTROY_DUMB ioctl and also when closing dmabuf fd.
The issues I'm seeing are:

- the first and the major one happens in msm_gem_free_object() where we
are trying to free sg table which table is already freed by drm_prime
core in dmabuf .detach callback. In fact the msm_gem_free_object is
called by dmabuf .release callback which should be happened after
.detach. I find weird to call sg_table_free in .detach callback and did
not understand why it is there.

- the second one is again in msm_gem.c::put_pages dma_unmap_sg call.
Some background, vidc (venus) driver use dma-iommu infrastructure copped
from qcom downstream kernel to abstract iommu map/unmap [1].
On the other side when drm driver is exporter it use swiotbl [2] dma map
operations, dma_map_sg will fill sg->dma_address with phy addresses. So
when vidc call dma_map_sg the sg dma_address is filled with iova address
then drm call dma_unmap_sg expecting phy addresses.

If I didn't express myself well, see the hack bellow which I made to
prevent kernel crash.

Any thoughts?

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7482b06cd08f..c4c0f8084b11 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -155,10 +155,10 @@ static void drm_gem_map_detach(struct dma_buf
*dma_buf,
if (prime_attach->dir != DMA_NONE)
dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
prime_attach->dir);
-   sg_free_table(sgt);
+/* sg_free_table(sgt);*/
}

-   kfree(sgt);
+/* kfree(sgt);*/
kfree(prime_attach);
attach->priv = NULL;
 }
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 9b6220140e99..a78a24ca2fda 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -116,9 +116,10 @@ static void put_pages(struct drm_gem_object *obj)
/* For non-cached buffers, ensure the new pages are clean
 * because display controller, GPU, etc. are not coherent:
 */
-   if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
+/* if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents,
DMA_BIDIRECTIONAL);
+*/
sg_free_table(msm_obj->sgt);
kfree(msm_obj->sgt);


-- 
regards,
Stan

[1]
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/blob/refs/heads/release/qcomlt-4.0:/arch/arm64/mm/dma-mapping.c#l1315

[2]
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/blob/refs/heads/release/qcomlt-4.0:/arch/arm64/mm/dma-mapping.c#l350
--
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 v2 2/5] phy: qcom: Add Qualcomm PCIe PHY

2015-05-22 Thread Stanimir Varbanov
On 05/20/2015 04:23 PM, Bjorn Helgaas wrote:
> On Wed, May 20, 2015 at 8:08 AM, Kishon Vijay Abraham I  wrote:
>> Hi Bjorn,
>>
>>
>> On Wednesday 20 May 2015 04:11 AM, Bjorn Helgaas wrote:
>>>
>>> On Mon, May 04, 2015 at 06:24:10PM +0300, Stanimir Varbanov wrote:
>>>>
>>>> On 05/04/2015 05:35 PM, Kishon Vijay Abraham I wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Monday 04 May 2015 06:12 PM, Stanimir Varbanov wrote:
>>>>>>
>>>>>> Add a PCIe PHY driver used by PCIe host controller driver
>>>>>> on Qualcomm SoCs like Snapdragon 805.
>>>>>>
>>>>>> Signed-off-by: Stanimir Varbanov 
>>>>>> ---
>>>>>>drivers/phy/Kconfig |9 ++
>>>>>>drivers/phy/Makefile|1 +
>>>>>>drivers/phy/phy-qcom-pcie.c |  291
>>>>>> +++
>>>>>
>>>>>
>>>>> Why do you need a new PHY driver for this? Why not use the existing QCOM
>>>>> PHY driver. I can see the registers used here in
>>>>> phy-qcom-ufs-qmp-14nm.h?
>>>>
>>>>
>>>> I agree that on first glance there are similarities, but I'm not sure
>>>> does the PHYs are the same IP blocks. Or at least they are different
>>>> revisions which have too many differences. So trying to combine them
>>>> will lead to more code than now.
>>>>
>>>> Either way I will try to understand how many the differences are.
>>>
>>>
>>> Ping, where are we with this?  Should I wait for something else, or are
>>> you
>>> convinced there's enough difference to warrant a new PHY driver, Kishon?
>>
>>
>> I'd like to wait to see if Stanimir can use existing driver instead of
>> creating a new driver.
> 
> OK, I'm waiting for a v3 with either tweaks to the QCOM PHY driver, or
> stronger justification as to why that's impossible.  It's hard to
> quantify statements like "there are similarities, but there are too
> many differences," so you might have to actually attempt a patch for
> the QCOM code and we can see how ugly that would turn out to be.

Kishon,

I'm still checking the differences, sorry for the delay.

Bjorn, is the pcie driver looks good enough to be merged?

-- 
regards,
Stan
--
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 v2 2/6] clk: qcom: gdsc: Prepare common clk probe to register gdscs

2015-03-19 Thread Stanimir Varbanov
Hi Rajendra,

Thanks for the patch!

On 03/19/2015 10:02 AM, Rajendra Nayak wrote:
> The common clk probe registers a clk provider and a reset controller.
> Update it to register a genpd provider using the gdsc data provided
> by each platform.
> 
> Signed-off-by: Rajendra Nayak 
> ---
>  drivers/clk/qcom/common.c | 14 +-
>  drivers/clk/qcom/common.h |  2 ++
>  drivers/clk/qcom/gdsc.c   | 34 +-
>  drivers/clk/qcom/gdsc.h   |  9 -
>  4 files changed, 56 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
> index a946b48..cc9f56f 100644
> --- a/drivers/clk/qcom/common.c
> +++ b/drivers/clk/qcom/common.c
> @@ -21,6 +21,7 @@
>  #include "clk-rcg.h"
>  #include "clk-regmap.h"
>  #include "reset.h"
> +#include "gdsc.h"
>  
>  struct qcom_cc {
>   struct qcom_reset_controller reset;
> @@ -125,8 +126,18 @@ int qcom_cc_really_probe(struct platform_device *pdev,
>  
>   ret = reset_controller_register(&reset->rcdev);
>   if (ret)
> - of_clk_del_provider(dev->of_node);
> + goto err_reset;
>  
> + ret = gdsc_register(dev, desc->gdscs, desc->num_gdscs, regmap);
> + if (ret)
> + goto err_pd;
> +
> + return 0;
> +err_pd:
> + dev_err(dev, "Failed to register power domains\n");
> + reset_controller_unregister(&reset->rcdev);
> +err_reset:
> + of_clk_del_provider(dev->of_node);
>   return ret;
>  }
>  EXPORT_SYMBOL_GPL(qcom_cc_really_probe);
> @@ -145,6 +156,7 @@ EXPORT_SYMBOL_GPL(qcom_cc_probe);
>  
>  void qcom_cc_remove(struct platform_device *pdev)
>  {
> + of_genpd_del_provider(pdev->dev.of_node);

It would be nice to introduce gdsc_unregister() for symmetry.

>   of_clk_del_provider(pdev->dev.of_node);
>   reset_controller_unregister(platform_get_drvdata(pdev));
>  }



> +
> +int gdsc_register(struct device *dev, struct gdsc **scs, size_t num,
> +   struct regmap *regmap)
> +{

Could you squash implementation of this function with the first patch 1/6.

> + int i, ret;
> + struct genpd_onecell_data *data;
> +
> + if (!num || !scs || !dev || !dev->of_node)
> + return 0;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->domains = devm_kzalloc(dev, sizeof(*data->domains) * num,
> +  GFP_KERNEL);

Just wondering, are there some obstacles to embed struct
genpd_onecell_data in struct gdsc, and thus avoid having two memory
allocations?

> + if (!data->domains)
> + return -ENOMEM;
> +
> + data->num_domains = num;
> + for (i = 0; i < num; i++) {
> + if (!scs[i])
> + continue;
> + scs[i]->regmap = regmap;
> + ret = gdsc_init(scs[i]);
> + if (ret)
> + return ret;
> + data->domains[i] = &scs[i]->pd;
> + }
> + return of_genpd_add_provider_onecell(dev->of_node, data);
> +}
> diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
> index ac6a2d5..14de304 100644
> --- a/drivers/clk/qcom/gdsc.h
> +++ b/drivers/clk/qcom/gdsc.h
> @@ -32,5 +32,12 @@ struct gdsc {
>  
>  #define domain_to_gdsc(domain) container_of(domain, struct gdsc, pd)

This is used only from gdsc.c, please move it there.



-- 
regards,
Stan
--
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 1/2] DT: arm64: msm8916: add all SPI DT nodes

2015-03-18 Thread Stanimir Varbanov
On 03/18/2015 02:26 PM, Srinivas Kandagatla wrote:
> 
> 
> On 17/03/15 16:25, Stanimir Varbanov wrote:
>> +
>> +spi4_sleep: spi4_sleep {
>> +pinmux {
>> +function = "gpio";
>> +pins = "gpio12", "gpio13", "gpio14", "gpio15";
>> +   
> 
> 
>> +
>> +spi5_sleep: spi4_sleep {
> Will result in Duplicate node name error for "spi4_sleep"

thanks for the catch, it was a typo.

-- 
regards,
Stan
--
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


[PATCH 2/2] DT: arm64: msm8916-mtp: enable spi3

2015-03-17 Thread Stanimir Varbanov
This enable spi3 on msm8916 mtp board

Signed-off-by: Stanimir Varbanov 
---
 arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
index 270ba55..fa229d0 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
@@ -26,3 +26,11 @@
};
};
 };
+
+&blsp_dma {
+   status = "okay";
+};
+
+&blsp_spi3 {
+   status = "okay";
+};
-- 
1.7.0.4

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


[PATCH 1/2] DT: arm64: msm8916: add all SPI DT nodes

2015-03-17 Thread Stanimir Varbanov
Add SPI DT nodes for the SoC. Every SPI DT node has reference to
blsp dma node with relevant dma channels and appropriate pinctrl
nodes to configure SPI pins.

Signed-off-by: Stanimir Varbanov 
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi |  317 +
 1 files changed, 317 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 8c8fd49..b5be833 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -96,6 +96,210 @@
bias-pull-down;
};
};
+
+   spi1_default: spi1_default {
+   pinmux {
+   function = "blsp_spi1";
+   pins = "gpio0", "gpio1", "gpio3";
+   };
+   pinmux_cs {
+   function = "gpio";
+   pins = "gpio2";
+   };
+   pinconf {
+   pins = "gpio0", "gpio1", "gpio3";
+   drive-strength = <12>;
+   bias-disable;
+   };
+   pinconf_cs {
+   pins = "gpio2";
+   drive-strength = <2>;
+   bias-disable;
+   output-high;
+   };
+   };
+
+   spi1_sleep: spi1_sleep {
+   pinmux {
+   function = "gpio";
+   pins = "gpio0", "gpio1", "gpio2", 
"gpio3";
+   };
+   pinconf {
+   pins = "gpio0", "gpio1", "gpio2", 
"gpio3";
+   drive-strength = <2>;
+   bias-pull-down;
+   };
+   };
+
+   spi2_default: spi2_default {
+   pinmux {
+   function = "blsp_spi2";
+   pins = "gpio4", "gpio5", "gpio7";
+   };
+   pinmux_cs {
+   function = "gpio";
+   pins = "gpio6";
+   };
+   pinconf {
+   pins = "gpio4", "gpio5", "gpio6", 
"gpio7";
+   drive-strength = <12>;
+   bias-disable;
+   };
+   pinconf_cs {
+   pins = "gpio6";
+   drive-strength = <2>;
+   bias-disable;
+   output-high;
+   };
+   };
+
+   spi2_sleep: spi2_sleep {
+   pinmux {
+   function = "gpio";
+   pins = "gpio4", "gpio5", "gpio6", 
"gpio7";
+   };
+   pinconf {
+   pins = "gpio4", "gpio5", "gpio6", 
"gpio7";
+   drive-strength = <2>;
+   bias-pull-down;
+   };
+   };
+
+   spi3_default: spi3_default {
+   pinmux {
+   function = "blsp_spi3";
+   pins = "gpio8", "gpio9", "gpio11";
+   };
+   pinmux_cs {
+   function = "gpio";
+   pins = "gpio10";
+   };
+   pinconf {
+

Re: [PATCH 5/6] dts: msm8974: Add blsp2_bam dma node

2015-03-17 Thread Stanimir Varbanov
On 03/13/2015 07:49 PM, Sricharan R wrote:
> Signed-off-by: Sricharan R 
> ---
>  arch/arm/boot/dts/qcom-msm8974.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index e265ec1..3f648ae 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -247,5 +247,15 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   };
> +
> + blsp2_dma: dma@f9944000 {
> + compatible = "qcom,bam-v1.4.0";
> + reg = <0xf9944000 0x19000>;
> + interrupts = <0 239 0>;

for completeness this should be:

interrupts = ;

-- 
regards,
Stan
--
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 v5 2/4] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts

2015-03-17 Thread Stanimir Varbanov
On 03/13/2015 06:06 PM, Kumar Gala wrote:
> Add initial device tree support for Qualcomm MSM8916 SoC and MTP8916
> evaluation board.  At the current time we only boot up a single processor.
> 
> Signed-off-by: Kumar Gala 
> ---
> v5:
> * killed use of skeleton, moved to addr/size cells both being 2
> * Added serial alias in prep of being able to spec uart params
>   in chosen node
> 
> v4:
> * Added chosen node so we dont need to spec everything for earlycon
> * fixed up timer node to armv8, dropped clock-frequency
> 
> v3:
> * Removed qcom,msm-id and qcom,board-id
> * Added top level compat for "qcom,msm8916-mtp-smb1360"
> 
> v2:
> * Updated to dropping CONFIG_ARCH_QCOM_MSM8916
> * Updated to use qcom-ids.h
> 
>  arch/arm64/boot/dts/Makefile  |   1 +
>  arch/arm64/boot/dts/qcom/Makefile |   5 +
>  arch/arm64/boot/dts/qcom/msm8916-mtp.dts  |  21 
>  arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi |  32 +
>  arch/arm64/boot/dts/qcom/msm8916.dtsi | 195 
> ++
>  5 files changed, 254 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/Makefile
>  create mode 100644 arch/arm64/boot/dts/qcom/msm8916-mtp.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
>  create mode 100644 arch/arm64/boot/dts/qcom/msm8916.dtsi
> 
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index e0350ca..8517f15 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -5,5 +5,6 @@ dts-dirs += cavium
>  dts-dirs += exynos
>  dts-dirs += freescale
>  dts-dirs += mediatek
> +dts-dirs += qcom
>  
>  subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/qcom/Makefile 
> b/arch/arm64/boot/dts/qcom/Makefile
> new file mode 100644
> index 000..360ec4c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -0,0 +1,5 @@
> +dtb-$(CONFIG_ARCH_QCOM)  += msm8916-mtp.dtb
> +
> +always   := $(dtb-y)
> +subdir-y := $(dts-dirs)
> +clean-files  := *.dtb
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts 
> b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
> new file mode 100644
> index 000..784ad92
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
> @@ -0,0 +1,21 @@
> +/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.

multi line comment rules

> +*
> +* 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.
> +*/
> +
> +/dts-v1/;
> +
> +#include "msm8916-mtp.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. MSM 8916 MTP";
> + compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp-smb1360",
> + "qcom,msm8916", "qcom,mtp";
> +};
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
> new file mode 100644
> index 000..8dbb77f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
> @@ -0,0 +1,32 @@
> +/* Copyright (c) 2014-2014, The Linux Foundation. All rights reserved.

multi line comment rules and 2014-2015

> + *
> + * 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 "msm8916.dtsi"
> +
> +/ {
> + aliases {
> + serial0 = &blsp1_uart2;
> + };
> +
> + chosen {
> + stdout-path = "serial0";
> + };
> +
> + soc {
> + serial@78b {
> + status = "okay";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&blsp1_uart2_default>;
> + pinctrl-1 = <&blsp1_uart2_sleep>;
> + };
> + };

Why don't describe this as:

&blsp1_uart2 {
status = "okay";
pinctrl-names = ;

};

it looks more readable and obvious. This is what the other boards doing
as well.



-- 
regards,
Stan
--
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] spmi: pmic_arb: enable build on arm64 platforms

2015-03-09 Thread Stanimir Varbanov
On 02/23/2015 02:57 PM, Ivan T. Ivanov wrote:
> 
> On Wed, 2015-02-04 at 19:46 +0100, Paul Bolle wrote:
>> On Wed, 2015-02-04 at 17:27 +0200, Stanimir Varbanov wrote:
>>> On 02/04/2015 05:14 PM, Paul Bolle wrote:
>>>> On Wed, 2015-02-04 at 17:05 +0200, Stanimir Varbanov wrote:
>>>>> On 02/03/2015 10:42 PM, Paul Bolle wrote:
>>>>>> On Tue, 2015-02-03 at 15:50 +0200, Stanimir Varbanov wrote:
>>>>>>> diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
>>>>>>> index bf1295e..115348c 100644
>>>>>>> --- a/drivers/spmi/Kconfig
>>>>>>> +++ b/drivers/spmi/Kconfig
>>>>>>> @@ -12,7 +12,7 @@ if SPMI
>>>>>>>
>>>>>>>  config SPMI_MSM_PMIC_ARB
>>>>>>> tristate "Qualcomm MSM SPMI Controller (PMIC Arbiter)"
>>>>>>> -   depends on ARM
>>>>>>> +   depends on ARM || ARM64
>>>>>>> depends on IRQ_DOMAIN
>>>>>>> depends on ARCH_QCOM || COMPILE_TEST
>>>>>>> default ARCH_QCOM
>>>>>>
>>>>>> But only if COMPILE_TEST is set too, isn't it? Is that intended?
>>>>>
>>>>> No, the driver will be used on arm64 qcom platforms, also.
>>>>
>>>> But ARCH_QCOM currently is (32 bit) arch/arm only, isn't it?
>>>
>>> Currently yes, but we want to be prepared to support PMIC's which will
>>> be used on arm64 platforms, although they are not upstream yet.
>>
>> Please make the commit summary reflect that, as in:
>> "spmi: pmic_arb: enable test build on arm64"
>>
>> Commit explanation likewise.
> 
> What if we just drop ARM dependency? 

I'm fine with this, Paul?

-- 
regards,
Stan
--
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 0/6] Add support for QCOM GDSCs

2015-03-05 Thread Stanimir Varbanov
On 03/02/2015 09:02 AM, Rajendra Nayak wrote:
> GDSCs (Global Distributed Switch Controllers) control switches
> that supply power to an on-chip power domain and hence can be
> programmed in SW to safely power collapse and restore power to the
> respective PDs. They are part of a considerable number of recent QCOM
> SoCs (This series adds support for msm8974, msm8916 and apq8084 devices)
> and are part of the Clock control block.
> 
> The series implements support for GDSC using the genpd framework
> modelling these as SW controllable power domains.
> 
> 8916 support has a dependency on the Global Clock controller support [1]
> posted by Georgi Djakov.
> 
> [1] 
> https://lkml.org/lkml/2015/2/25/416
> 
> Rajendra Nayak (3):
>   clk: qcom: gdsc: Prepare common clk probe to register gdscs
>   clk: qcom: gdsc: Add GDSCs in msm8916 GCC
>   clk: qcom: gdsc: Add GDSCs in apq8084 GCC
> 
> Stephen Boyd (3):
>   clk: qcom: Add support for GDSCs
>   clk: qcom: gdsc: Add GDSCs in msm8974 GCC
>   clk: qcom: gdsc: Add GDSCs in msm8974 MMCC
> 
>  drivers/clk/qcom/Kconfig  |   8 ++
>  drivers/clk/qcom/Makefile |   1 +
>  drivers/clk/qcom/common.c |  27 +-
>  drivers/clk/qcom/common.h |   2 +
>  drivers/clk/qcom/gcc-apq8084.c|  38 
>  drivers/clk/qcom/gcc-msm8916.c|  46 +
>  drivers/clk/qcom/gcc-msm8974.c|  14 +++
>  drivers/clk/qcom/gdsc.c   | 130 
> ++
>  drivers/clk/qcom/gdsc.h   |  43 +
>  drivers/clk/qcom/mmcc-msm8974.c   |  54 +++
>  include/dt-bindings/clock/qcom,gcc-apq8084.h  |   6 ++
>  include/dt-bindings/clock/qcom,gcc-msm8916.h  |   8 ++
>  include/dt-bindings/clock/qcom,gcc-msm8974.h  |   3 +
>  include/dt-bindings/clock/qcom,mmcc-msm8974.h |   8 ++
>  14 files changed, 387 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/clk/qcom/gdsc.c
>  create mode 100644 drivers/clk/qcom/gdsc.h
> 

You missed a patch who adds appropriate changes in qcom,gcc.txt
(qcom,mmcc.txt), at least #power-domain-cells property should be described.

-- 
regards,
Stan
--
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 v2] dmaengine: bam-dma: fix a warning about missing capabilities

2015-03-05 Thread Stanimir Varbanov
On 03/05/2015 06:15 PM, Vinod Koul wrote:
> On Thu, Mar 05, 2015 at 03:03:04PM +0200, Stanimir Varbanov wrote:
>> Avoid the warning below triggered during dmaengine async device
>> registration.
>>
>> WARNING: CPU: 1 PID: 1 at linux/drivers/dma/dmaengine.c:863
>> dma_async_device_register+0x2a8/0x4b8()
>> this driver doesn't support generic slave capabilities reporting
>>
>> To do that fill mandatory .directions bit mask,
>> .src/dst_addr_widths and .residue_granularity dma_device fields
>> with appropriate values.
>>
> Applied, thanks
> 

Thanks Vinod!

While you are at bam-dma driver, I have posted one more patch which
could be treated as a fix here [1]. If it is fine with you could you
take it, too?

[1] https://lkml.org/lkml/2015/2/19/285

-- 
regards,
Stan
--
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


[PATCH v2] dmaengine: bam-dma: fix a warning about missing capabilities

2015-03-05 Thread Stanimir Varbanov
Avoid the warning below triggered during dmaengine async device
registration.

WARNING: CPU: 1 PID: 1 at linux/drivers/dma/dmaengine.c:863
dma_async_device_register+0x2a8/0x4b8()
this driver doesn't support generic slave capabilities reporting

To do that fill mandatory .directions bit mask,
.src/dst_addr_widths and .residue_granularity dma_device fields
with appropriate values.

Signed-off-by: Stanimir Varbanov 
---

v1 -> v2

  - the patch subject has been changed
  - now fill also .residue_granularity and src/dts_addr_widths
  - added the warning in patch description

v1 can be found at https://lkml.org/lkml/2015/3/4/896

 drivers/dma/qcom_bam_dma.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
index c3113e3..9c914d6 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom_bam_dma.c
@@ -1143,6 +1143,10 @@ static int bam_dma_probe(struct platform_device *pdev)
dma_cap_set(DMA_SLAVE, bdev->common.cap_mask);
 
/* initialize dmaengine apis */
+   bdev->common.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+   bdev->common.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
+   bdev->common.src_addr_widths = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   bdev->common.dst_addr_widths = DMA_SLAVE_BUSWIDTH_4_BYTES;
bdev->common.device_alloc_chan_resources = bam_alloc_chan;
bdev->common.device_free_chan_resources = bam_free_chan;
bdev->common.device_prep_slave_sg = bam_prep_slave_sg;
-- 
1.7.0.4

--
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 1/6] clk: qcom: Add support for GDSCs

2015-03-05 Thread Stanimir Varbanov
On 03/02/2015 09:02 AM, Rajendra Nayak wrote:
> From: Stephen Boyd 
> 
> GDSCs (Global Distributed Switch Controllers) are responsible for
> safely collapsing and restoring power to peripherals in the SoC.
> These are best modelled as power domains using genpd and given
> the registers are scattered throughout the clock controller register
> space, its best to have the support added through the clock driver.
> 
> Signed-off-by: Stephen Boyd 
> Signed-off-by: Rajendra Nayak 
> ---
>  drivers/clk/qcom/Kconfig  |   5 ++
>  drivers/clk/qcom/Makefile |   1 +
>  drivers/clk/qcom/gdsc.c   | 130 
> ++
>  drivers/clk/qcom/gdsc.h   |  43 +++
>  4 files changed, 179 insertions(+)
>  create mode 100644 drivers/clk/qcom/gdsc.c
>  create mode 100644 drivers/clk/qcom/gdsc.h
> 



> --- /dev/null
> +++ b/drivers/clk/qcom/gdsc.c
> @@ -0,0 +1,130 @@
> +/*



> +
> +#include "gdsc.h"
> +
> +#define PWR_ON_MASK  BIT(31)
> +#define EN_REST_WAIT_MASK(0xF << 20)

you can use GENMASK(23, 20) here and below

> +#define EN_FEW_WAIT_MASK (0xF << 16)
> +#define CLK_DIS_WAIT_MASK(0xF << 12)
> +#define SW_OVERRIDE_MASK BIT(2)
> +#define HW_CONTROL_MASK  BIT(1)
> +#define SW_COLLAPSE_MASK BIT(0)
> +
> +/* Wait 2^n CXO cycles between all states. Here, n=2 (4 cycles). */
> +#define EN_REST_WAIT_VAL (0x2 << 20)
> +#define EN_FEW_WAIT_VAL  (0x8 << 16)
> +#define CLK_DIS_WAIT_VAL (0x2 << 12)
> +
> +#define TIMEOUT_US   100
> +
> +static int gdsc_is_enabled(struct gdsc *sc)
> +{
> + u32 val;
> +
> + regmap_read(sc->regmap, sc->gdscr, &val);

please, check the regmap_read for error, here and on few places below.

> + return !!(val & PWR_ON_MASK);
> +}
> +
> +static int gdsc_toggle_logic(struct gdsc *sc, bool en)
> +{
> + int ret;
> + u32 val = en ? 0 : SW_COLLAPSE_MASK;
> + u32 check = en ? PWR_ON_MASK : 0;
> + unsigned long timeout;
> +
> + ret = regmap_update_bits(sc->regmap, sc->gdscr, SW_COLLAPSE_MASK, val);
> + if (ret)
> + return ret;
> +
> + timeout = jiffies + usecs_to_jiffies(TIMEOUT_US);
> + do {
> + regmap_read(sc->regmap, sc->gdscr, &val);
> + if ((val & PWR_ON_MASK) == check)
> + return 0;
> + } while (time_before(jiffies, timeout));

blank line here will be better.

> + regmap_read(sc->regmap, sc->gdscr, &val);
> + if ((val & PWR_ON_MASK) == check)
> + return 0;
> +
> + pr_err("%s %s timed out\n", en ? "enabling" : "disabling", sc->pd.name);

use dev_err() or giving the error to the upper layers should be enough.

> + return -ETIMEDOUT;
> +}
> +
> +static int gdsc_enable(struct generic_pm_domain *domain)
> +{
> + struct gdsc *sc = domain_to_gdsc(domain);
> + int ret;
> +
> + ret = gdsc_toggle_logic(sc, true);
> + if (ret)
> + return ret;
> + /*
> +  * If clocks to this power domain were already on, they will take an
> +  * additional 4 clock cycles to re-enable after the power domain is
> +  * enabled. Delay to account for this. A delay is also needed to ensure
> +  * clocks are not enabled within 400ns of enabling power to the
> +  * memories.
> +  */
> + udelay(1);
> +
> + return 0;
> +}
> +
> +static int gdsc_disable(struct generic_pm_domain *domain)
> +{
> + struct gdsc *sc = domain_to_gdsc(domain);
> + int ret = 0;
> +
> + ret = gdsc_toggle_logic(sc, false);
> + if (ret)
> + return ret;
> +
> + return ret;

return gdsc_toggle_logic(sc, false);

> +}
> +
> +int gdsc_init(struct generic_pm_domain *domain, struct regmap *regmap)
> +{
> + struct gdsc *sc = domain_to_gdsc(domain);
> + u32 mask;
> + u32 val;
> + int on;
> +
> + sc->regmap = regmap;
> +
> + /*
> +  * Disable HW trigger: collapse/restore occur based on registers writes.
> +  * Disable SW override: Use hardware state-machine for sequencing.
> +  * Configure wait time between states.
> +  */
> + mask = HW_CONTROL_MASK | SW_OVERRIDE_MASK |
> +EN_REST_WAIT_MASK | EN_FEW_WAIT_MASK | CLK_DIS_WAIT_MASK;
> + val = EN_REST_WAIT_VAL | EN_FEW_WAIT_VAL | CLK_DIS_WAIT_VAL;
> + regmap_update_bits(sc->regmap, sc->gdscr, mask, val);
> +
> + on = gdsc_is_enabled(sc);
> +
> + pm_genpd_init(&sc->pd, NULL, !on);
> + sc->pd.power_off = gdsc_disable;
> + sc->pd.power_on = gdsc_enable;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(gdsc_init);

gdsc_init is used in common.c, no need to export it.



-- 
regards,
Stan
--
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 2/6] clk: qcom: gdsc: Prepare common clk probe to register gdscs

2015-03-05 Thread Stanimir Varbanov
On 03/02/2015 09:02 AM, Rajendra Nayak wrote:
> The common clk probe registers a clk provider and a reset controller.
> Update it to register a genpd provider using the gdsc data provided
> by each platform.
> 
> Signed-off-by: Rajendra Nayak 
> ---
>  drivers/clk/qcom/common.c | 27 ++-
>  drivers/clk/qcom/common.h |  2 ++
>  2 files changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
> index e20d947..d5b65fa 100644
> --- a/drivers/clk/qcom/common.c
> +++ b/drivers/clk/qcom/common.c
> @@ -21,10 +21,12 @@
>  #include "clk-rcg.h"
>  #include "clk-regmap.h"
>  #include "reset.h"
> +#include "gdsc.h"
>  
>  struct qcom_cc {
>   struct qcom_reset_controller reset;
>   struct clk_onecell_data data;
> + struct genpd_onecell_data pd_data;

IMO this pd_data belongs to struct gdsc ...

>   struct clk *clks[];
>  };
>  
> @@ -66,10 +68,12 @@ int qcom_cc_really_probe(struct platform_device *pdev,
>   struct device *dev = &pdev->dev;
>   struct clk *clk;
>   struct clk_onecell_data *data;
> + struct genpd_onecell_data *pd;
>   struct clk **clks;
>   struct qcom_reset_controller *reset;
>   struct qcom_cc *cc;
>   size_t num_clks = desc->num_clks;
> + size_t num_gdscs = desc->num_gdscs;
>   struct clk_regmap **rclks = desc->clks;
>  
>   cc = devm_kzalloc(dev, sizeof(*cc) + sizeof(*clks) * num_clks,
> @@ -79,8 +83,11 @@ int qcom_cc_really_probe(struct platform_device *pdev,
>  
>   clks = cc->clks;
>   data = &cc->data;
> + pd = &cc->pd_data;
>   data->clks = clks;
>   data->clk_num = num_clks;
> + pd->domains = desc->gdscs;
> + pd->num_domains = num_gdscs;
>  
>   for (i = 0; i < num_clks; i++) {
>   if (!rclks[i]) {
> @@ -108,8 +115,25 @@ int qcom_cc_really_probe(struct platform_device *pdev,
>  
>   ret = reset_controller_register(&reset->rcdev);
>   if (ret)
> - of_clk_del_provider(dev->of_node);
> + goto err_reset;
>  
> + if (num_gdscs) {
> + for (i = 0; i < num_gdscs; i++) {
> + if (!desc->gdscs[i])
> + continue;
> + gdsc_init(desc->gdscs[i], regmap);
> + }
> +
> + ret = of_genpd_add_provider_onecell(dev->of_node, pd);
> + if (ret)
> + goto err_pd;
> + }

... and this code snippet should be moved in new gdsc_register()
function located in gdsc.c ...

> +
> + return 0;
> +err_pd:
> + reset_controller_unregister(&reset->rcdev);
> +err_reset:
> + of_clk_del_provider(dev->of_node);
>   return ret;
>  }
>  EXPORT_SYMBOL_GPL(qcom_cc_really_probe);
> @@ -128,6 +152,7 @@ EXPORT_SYMBOL_GPL(qcom_cc_probe);
>  
>  void qcom_cc_remove(struct platform_device *pdev)
>  {
> + of_genpd_del_provider(pdev->dev.of_node);
>   of_clk_del_provider(pdev->dev.of_node);
>   reset_controller_unregister(platform_get_drvdata(pdev));
>  }
> diff --git a/drivers/clk/qcom/common.h b/drivers/clk/qcom/common.h
> index f519322..55e69c5 100644
> --- a/drivers/clk/qcom/common.h
> +++ b/drivers/clk/qcom/common.h
> @@ -26,6 +26,8 @@ struct qcom_cc_desc {
>   size_t num_clks;
>   const struct qcom_reset_map *resets;
>   size_t num_resets;
> + struct generic_pm_domain **gdscs;

... and also replace struct generic_pm_domain with struct gdsc. This way
we will have the same abstraction level as reset controller?

> + size_t num_gdscs;
>  };



-- 
regards,
Stan
--
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] dmaengine: bam-dma: fill slave directions bit mask

2015-03-05 Thread Stanimir Varbanov
On 03/04/2015 09:44 PM, Andy Gross wrote:
> On Wed, Mar 04, 2015 at 09:32:13PM +0530, Vinod Koul wrote:
>> On Wed, Mar 04, 2015 at 05:25:10PM +0200, Stanimir Varbanov wrote:
>>> This will avoid warning during async device registration.
>>>
>>> Signed-off-by: Stanimir Varbanov 
>>> ---
>>>  drivers/dma/qcom_bam_dma.c |1 +
>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
>>> index c3113e3..cc9e5ee 100644
>>> --- a/drivers/dma/qcom_bam_dma.c
>>> +++ b/drivers/dma/qcom_bam_dma.c
>>> @@ -1143,6 +1143,7 @@ static int bam_dma_probe(struct platform_device *pdev)
>>> dma_cap_set(DMA_SLAVE, bdev->common.cap_mask);
>>>  
>>> /* initialize dmaengine apis */
>>> +   bdev->common.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
>>> bdev->common.device_alloc_chan_resources = bam_alloc_chan;
>>> bdev->common.device_free_chan_resources = bam_free_chan;
>>> bdev->common.device_prep_slave_sg = bam_prep_slave_sg;
>> You need to fill other fields, src/dstn_addr_widths and
>> residue_granularity...
> 
> Add segment granularity for BAM, as we can read the current completed segment.
> bdev->common.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
> 
> Use DMA_SLAVE_BUSWIDTH_4_BYTES for the src/dst addr width:
> bdev->common.src_addr_widths = DMA_SLAVE_BUSWIDTH_4_BYTES;
> bdev->common.dst_addr_widths = DMA_SLAVE_BUSWIDTH_4_BYTES;
> 

Thanks Andy, will add those fields too.

-- 
regards,
Stan
--
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


[PATCH] dmaengine: bam-dma: fill slave directions bit mask

2015-03-04 Thread Stanimir Varbanov
This will avoid warning during async device registration.

Signed-off-by: Stanimir Varbanov 
---
 drivers/dma/qcom_bam_dma.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
index c3113e3..cc9e5ee 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom_bam_dma.c
@@ -1143,6 +1143,7 @@ static int bam_dma_probe(struct platform_device *pdev)
dma_cap_set(DMA_SLAVE, bdev->common.cap_mask);
 
/* initialize dmaengine apis */
+   bdev->common.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
bdev->common.device_alloc_chan_resources = bam_alloc_chan;
bdev->common.device_free_chan_resources = bam_free_chan;
bdev->common.device_prep_slave_sg = bam_prep_slave_sg;
-- 
1.7.0.4

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


[PATCH v2 0/2] pinctrl: qcom: enable generic pinconf and input-enable

2015-03-04 Thread Stanimir Varbanov
From: Stanimir Varbanov 

v1 -> v2

 - addressed a review comment from Linus about returned error in 1/2
 - added Reviewed-by tag in 1/2
 - 2/2 has no changes

First version of the patchset can be found at
https://lkml.org/lkml/2015/1/30/202


v1:

Here is splitted version of the previous patch at [1].

The major change is in 3/3 where now we check oe_bit in control register
instead of in_bit in io register.

regards
Stan

[1] https://lkml.org/lkml/2015/1/26/514

Stanimir Varbanov (2):
  pinctrl: qcom: enable generic pinconf
  pinctrl: qcom: handle input-enable pinconf property

 drivers/pinctrl/qcom/pinctrl-msm.c |   17 +
 1 files changed, 13 insertions(+), 4 deletions(-)

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


[PATCH v2 1/2] pinctrl: qcom: enable generic pinconf

2015-03-04 Thread Stanimir Varbanov
This makes the pinctrl driver to use the generic pinconf
interface. Mainly it gives us a way to use debugfs to dump
group configurations.

Signed-off-by: Stanimir Varbanov 
Reviewed-by: Linus Walleij 
---
 drivers/pinctrl/qcom/pinctrl-msm.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
index a535f9c..d36e511 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -197,7 +197,6 @@ static int msm_config_reg(struct msm_pinctrl *pctrl,
*mask = 1;
break;
default:
-   dev_err(pctrl->dev, "Invalid config param %04x\n", param);
return -ENOTSUPP;
}
 
@@ -262,9 +261,7 @@ static int msm_config_group_get(struct pinctrl_dev *pctldev,
arg = !!(val & BIT(g->in_bit));
break;
default:
-   dev_err(pctrl->dev, "Unsupported config parameter: %x\n",
-   param);
-   return -EINVAL;
+   return -ENOTSUPP;
}
 
*config = pinconf_to_config_packed(param, arg);
@@ -357,6 +354,7 @@ static int msm_config_group_set(struct pinctrl_dev *pctldev,
 }
 
 static const struct pinconf_ops msm_pinconf_ops = {
+   .is_generic = true,
.pin_config_group_get   = msm_config_group_get,
.pin_config_group_set   = msm_config_group_set,
 };
-- 
1.7.0.4

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


[PATCH v2 2/2] pinctrl: qcom: handle input-enable pinconf property

2015-03-04 Thread Stanimir Varbanov
This enables support of 'input-enable' pinconf generic property in
the pinctrl driver.

Signed-off-by: Stanimir Varbanov 
---
 drivers/pinctrl/qcom/pinctrl-msm.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
index d36e511..f3d800f 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -193,6 +193,7 @@ static int msm_config_reg(struct msm_pinctrl *pctrl,
*mask = 7;
break;
case PIN_CONFIG_OUTPUT:
+   case PIN_CONFIG_INPUT_ENABLE:
*bit = g->oe_bit;
*mask = 1;
break;
@@ -260,6 +261,12 @@ static int msm_config_group_get(struct pinctrl_dev 
*pctldev,
val = readl(pctrl->regs + g->io_reg);
arg = !!(val & BIT(g->in_bit));
break;
+   case PIN_CONFIG_INPUT_ENABLE:
+   /* Pin is output */
+   if (arg)
+   return -EINVAL;
+   arg = 1;
+   break;
default:
return -ENOTSUPP;
}
@@ -330,6 +337,10 @@ static int msm_config_group_set(struct pinctrl_dev 
*pctldev,
/* enable output */
arg = 1;
break;
+   case PIN_CONFIG_INPUT_ENABLE:
+   /* disable output */
+   arg = 0;
+   break;
default:
dev_err(pctrl->dev, "Unsupported config parameter: 
%x\n",
param);
-- 
1.7.0.4

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


[PATCH v4] spi: qup: Add DMA capabilities

2015-03-04 Thread Stanimir Varbanov
From: Andy Gross 

This patch adds DMA capabilities to the spi-qup driver.  If DMA channels are
present, the QUP will use DMA instead of block mode for transfers to/from SPI
peripherals for transactions larger than the length of a block.

Signed-off-by: Andy Gross 
Signed-off-by: Stanimir Varbanov 
---

v3 -> v4
 - correct error path when setting to reset state fails

Third version can be found at https://lkml.org/lkml/2015/2/27/369
v2 -> v3
 - now using one dma done callback on rx channel if bidirectional transfer
   and on tx channel if only transmit transfer
 - rearranged the spi_qup_transfer_one() in order to reuse wait for
   completion and completion init code
 - move dma init function early in .probe to avoid controller reset if
   probe deffer
 - add function to get controller mode
   
Second version can be found at https://lkml.org/lkml/2015/2/24/316


v1 -> v2
This is reworked version with comments addressed
 - use SPI core DMA mapping code
 - implemented .can_dma callback
 - use dmaengine api's to account deferred_probe

First version can be found at https://lkml.org/lkml/2014/6/26/481

regards,
Stan

 .../devicetree/bindings/spi/qcom,spi-qup.txt   |8 +
 drivers/spi/spi-qup.c  |  336 ++--
 2 files changed, 312 insertions(+), 32 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt 
b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt
index e2c88df..5c09077 100644
--- a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt
@@ -33,6 +33,11 @@ Optional properties:
nodes.  If unspecified, a single SPI device without a chip
select can be used.
 
+- dmas: Two DMA channel specifiers following the convention outlined
+in bindings/dma/dma.txt
+- dma-names:Names for the dma channels, if present. There must be at
+least one channel named "tx" for transmit and named "rx" for
+receive.
 
 SPI slave nodes must be children of the SPI master node and can contain
 properties described in Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -51,6 +56,9 @@ Example:
clocks = <&gcc GCC_BLSP2_QUP2_SPI_APPS_CLK>, <&gcc 
GCC_BLSP2_AHB_CLK>;
clock-names = "core", "iface";
 
+   dmas = <&blsp1_bam 13>, <&blsp1_bam 12>;
+   dma-names = "rx", "tx";
+
pinctrl-names = "default";
pinctrl-0 = <&spi8_default>;
 
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index ff9cdbd..4b5fc4d 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define QUP_CONFIG 0x
 #define QUP_STATE  0x0004
@@ -116,6 +118,8 @@
 
 #define SPI_NUM_CHIPSELECTS4
 
+#define SPI_MAX_DMA_XFER   (SZ_64K - 64)
+
 /* high speed mode is when bus rate is greater then 26MHz */
 #define SPI_HS_MIN_RATE2600
 #define SPI_MAX_RATE   5000
@@ -140,9 +144,14 @@ struct spi_qup {
struct completion   done;
int error;
int w_size; /* bytes per SPI word */
+   int n_words;
int tx_bytes;
int rx_bytes;
int qup_v1;
+
+   int use_dma;
+   struct dma_slave_config rx_conf;
+   struct dma_slave_config tx_conf;
 };
 
 
@@ -198,7 +207,6 @@ static int spi_qup_set_state(struct spi_qup *controller, 
u32 state)
return 0;
 }
 
-
 static void spi_qup_fifo_read(struct spi_qup *controller,
struct spi_transfer *xfer)
 {
@@ -266,6 +274,107 @@ static void spi_qup_fifo_write(struct spi_qup *controller,
}
 }
 
+static void spi_qup_dma_done(void *data)
+{
+   struct spi_qup *qup = data;
+
+   complete(&qup->done);
+}
+
+static int spi_qup_prep_sg(struct spi_master *master, struct spi_transfer 
*xfer,
+  enum dma_transfer_direction dir,
+  dma_async_tx_callback callback)
+{
+   struct spi_qup *qup = spi_master_get_devdata(master);
+   unsigned long flags = DMA_PREP_INTERRUPT | DMA_PREP_FENCE;
+   struct dma_async_tx_descriptor *desc;
+   struct scatterlist *sgl;
+   struct dma_chan *chan;
+   dma_cookie_t cookie;
+   unsigned int nents;
+
+   if (dir == DMA_MEM_TO_DEV) {
+   chan = master->dma_tx;
+   nents = xfer->tx_sg.nents;
+   sgl = xfer->tx_sg.sgl;
+   } el

Re: [PATCH v3 3/3] pinctrl: qcom: Add msm8916 pinctrl driver

2015-03-04 Thread Stanimir Varbanov
On 03/02/2015 04:40 PM, Linus Walleij wrote:
> On Wed, Feb 4, 2015 at 3:39 PM, Stanimir Varbanov  
> wrote:
>> On 02/03/2015 06:47 PM, Andy Gross wrote:
>>> On Fri, Jan 30, 2015 at 12:04:01PM +0200, Stanimir Varbanov wrote:
>>>> From: Joonwoo Park 
>>>>
>>>> Add initial pinctrl driver to support pin configuration with
>>>> pinctrl framework for msm8916.
>>>>
>>>> Signed-off-by: Joonwoo Park 
>>>> Signed-off-by: Stanimir Varbanov 
>>>> Reviewed-by: Bjorn Andersson 
>>>
>>> Looks good.
>>>
>>> Reviewed-by: Andy Gross 
>>>
>>
>> Linus, do you want me to resend the patchset including this Reviewed-by tag?
> 
> 1/3 is already merged upstream.
> 
> 2/3 has an unaddressed review comment. Please fix that and resent.
> 
> So this 3/3 can be resent as well, with the Review tag.
> 
> But it's down to just two patches now atleast.

Sure, will resend it as a new patch set, thanks. And of course you are
talking for "[PATCH 0/3] pinctrl: qcom: enable generic pinconf and
input-enable" patch set.

-- 
regards,
Stan
--
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] spi: qup: Add DMA capabilities

2015-03-04 Thread Stanimir Varbanov
On 03/04/2015 10:38 AM, Ivan T. Ivanov wrote:
> 
> Hi Stan,
> 
> It looks good now, except it doesn't apply and two small issues below:
> 



> 
>> +
>> +   /* set DMA parameters */
>> +   rx_conf->direction = DMA_DEV_TO_MEM;
>> +   rx_conf->device_fc = 1;
> 
> Strictly speeching this is a bool not int.

sure will correct.

>>
>> +   ret = spi_qup_init_dma(master, res->start);
>> +   if (ret == -EPROBE_DEFER)
>> +   goto error;
>> +   else if (!ret)
>> +   master->can_dma = spi_qup_can_dma;
>> +
>> /* set v1 flag if device is version 1 */
>> if (of_device_is_compatible(dev->of_node, "qcom,spi-qup-v1.1.1"))
>> controller->qup_v1 = 1;
> 
> It is not visible from this patch, but in case of error reseting
> SPI controller (QUP_STATE_RESET), exit error path should be 
> 'error_dma' and not 'error' label.

my fault, will correct.

regards,
Stan


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


[PATCH v3] spi: qup: Add DMA capabilities

2015-02-27 Thread Stanimir Varbanov
From: Andy Gross 

This patch adds DMA capabilities to the spi-qup driver.  If DMA channels are
present, the QUP will use DMA instead of block mode for transfers to/from SPI
peripherals for transactions larger than the length of a block.

Signed-off-by: Andy Gross 
Signed-off-by: Stanimir Varbanov 
---

v2 -> v3
 - now using one dma done callback on rx channel if bidirectional transfer
   and on tx channel if only transmit transfer
 - rearranged the spi_qup_transfer_one() in order to reuse wait for
   completion and completion init code
 - move dma init function early in .probe to avoid controller reset if
   probe deffer
 - add function to get controller mode
   
Second version can be found at https://lkml.org/lkml/2015/2/24/316


v1 -> v2
This is reworked version with comments addressed
 - use SPI core DMA mapping code
 - implemented .can_dma callback
 - use dmaengine api's to account deferred_probe

First version can be found at https://lkml.org/lkml/2014/6/26/481

regards,
Stan

 .../devicetree/bindings/spi/qcom,spi-qup.txt   |8 +
 drivers/spi/spi-qup.c  |  334 ++--
 2 files changed, 311 insertions(+), 31 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt 
b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt
index e2c88df..5c09077 100644
--- a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt
@@ -33,6 +33,11 @@ Optional properties:
nodes.  If unspecified, a single SPI device without a chip
select can be used.
 
+- dmas: Two DMA channel specifiers following the convention outlined
+in bindings/dma/dma.txt
+- dma-names:Names for the dma channels, if present. There must be at
+least one channel named "tx" for transmit and named "rx" for
+receive.
 
 SPI slave nodes must be children of the SPI master node and can contain
 properties described in Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -51,6 +56,9 @@ Example:
clocks = <&gcc GCC_BLSP2_QUP2_SPI_APPS_CLK>, <&gcc 
GCC_BLSP2_AHB_CLK>;
clock-names = "core", "iface";
 
+   dmas = <&blsp1_bam 13>, <&blsp1_bam 12>;
+   dma-names = "rx", "tx";
+
pinctrl-names = "default";
pinctrl-0 = <&spi8_default>;
 
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index e7fb5a0..81539d5 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define QUP_CONFIG 0x
 #define QUP_STATE  0x0004
@@ -116,6 +118,8 @@
 
 #define SPI_NUM_CHIPSELECTS4
 
+#define SPI_MAX_DMA_XFER   (SZ_64K - 64)
+
 /* high speed mode is when bus rate is greater then 26MHz */
 #define SPI_HS_MIN_RATE2600
 #define SPI_MAX_RATE   5000
@@ -140,9 +144,14 @@ struct spi_qup {
struct completion   done;
int error;
int w_size; /* bytes per SPI word */
+   int n_words;
int tx_bytes;
int rx_bytes;
int qup_v1;
+
+   int use_dma;
+   struct dma_slave_config rx_conf;
+   struct dma_slave_config tx_conf;
 };
 
 
@@ -198,7 +207,6 @@ static int spi_qup_set_state(struct spi_qup *controller, 
u32 state)
return 0;
 }
 
-
 static void spi_qup_fifo_read(struct spi_qup *controller,
struct spi_transfer *xfer)
 {
@@ -266,6 +274,107 @@ static void spi_qup_fifo_write(struct spi_qup *controller,
}
 }
 
+static void spi_qup_dma_done(void *data)
+{
+   struct spi_qup *qup = data;
+
+   complete(&qup->done);
+}
+
+static int spi_qup_prep_sg(struct spi_master *master, struct spi_transfer 
*xfer,
+  enum dma_transfer_direction dir,
+  dma_async_tx_callback callback)
+{
+   struct spi_qup *qup = spi_master_get_devdata(master);
+   unsigned long flags = DMA_PREP_INTERRUPT | DMA_PREP_FENCE;
+   struct dma_async_tx_descriptor *desc;
+   struct scatterlist *sgl;
+   struct dma_chan *chan;
+   dma_cookie_t cookie;
+   unsigned int nents;
+
+   if (dir == DMA_MEM_TO_DEV) {
+   chan = master->dma_tx;
+   nents = xfer->tx_sg.nents;
+   sgl = xfer->tx_sg.sgl;
+   } else {
+   chan = master->dma_rx;
+   nents = xfer->rx_sg.nents;
+   sgl = xfer->rx_sg.sgl;
+   }
+

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-27 Thread Stanimir Varbanov
On 02/26/2015 04:33 AM, Mark Brown wrote:
> On Tue, Feb 24, 2015 at 06:08:54PM +0200, Stanimir Varbanov wrote:
> 
>> yes, there is a potential race between atomic_inc and dma callback. I
>> reordered these calls to save few checks, and now it returns to me.
> 
>> I imagine few options here:
> 
>>  - reorder the dmaengine calls and atomic operations, i.e.
>> call atomic_inc for rx and tx channels before corresponding
>> dmaengine_submit and dmaengine_issue_pending.
> 
>>  - have two different dma callbacks and two completions and waiting for
>> the two.
> 
>>  - manage to receive only one dma callback, i.e. the last transfer in
>> case of presence of the rx_buf and tx_buf at the same time.
> 
>>  - let me see for better solution.
> 
> Any solution which doesn't make use of atomics is likely to be better,
> as I said they are enormously error prone.  A more common approach is a
> single completion triggering on the RX (for RX only or bidirectional
> transfers) or TX if that's the only thing active.  For most hardware you
> can just use the RX to manage completion since it must of necessity
> complete at the same time as or later than the transmit side, transmit
> often completes early since the DMA completes when the FIFO is full not
> when the data is on the wire.
> 

yep, that's what I wanted to express in third option above.

-- 
regards,
Stan
--
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 v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Stanimir Varbanov
On 02/24/2015 03:56 PM, Mark Brown wrote:
> On Tue, Feb 24, 2015 at 03:00:03PM +0200, Stanimir Varbanov wrote:
> 
>> +static void spi_qup_dma_done(void *data)
>> +{
>> +struct spi_qup *qup = data;
>> +
>> +if (atomic_dec_and_test(&qup->dma_outstanding))
>> +complete(&qup->done);
>> +}
> 
> I'm finding it hard to be thrilled about the use of atomics for
> synchronization (they're just generally hard to work with) and...
> 
>> +cookie = dmaengine_submit(desc);
>> +ret = dma_submit_error(cookie);
>> +if (ret)
>> +return ret;
> 
>> +atomic_inc(&qup->dma_outstanding);
> 
> ..don't we have two potential races here: one if somehow the DMA manages
> to complete prior to the atomic_inc() (unlikely but that's what race
> conditions are all about really) and one if we are issuing multiple DMAs
> and the early ones complete before the later ones are issued?
> 

yes, there is a potential race between atomic_inc and dma callback. I
reordered these calls to save few checks, and now it returns to me.

I imagine few options here:

 - reorder the dmaengine calls and atomic operations, i.e.
call atomic_inc for rx and tx channels before corresponding
dmaengine_submit and dmaengine_issue_pending.

 - have two different dma callbacks and two completions and waiting for
the two.

 - manage to receive only one dma callback, i.e. the last transfer in
case of presence of the rx_buf and tx_buf at the same time.

 - let me see for better solution.

Thanks for the comments.

regards,
Stan



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


[PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Stanimir Varbanov
From: Andy Gross 

This patch adds DMA capabilities to the spi-qup driver.  If DMA channels are
present, the QUP will use DMA instead of block mode for transfers to/from SPI
peripherals for transactions larger than the length of a block.

Signed-off-by: Andy Gross 
Signed-off-by: Stanimir Varbanov 
---

This is reworked version with comments addressed
 - use SPI core DMA mapping code
 - implemented .can_dma callback
 - use dmaengine api's to account deferred_probe

First version can be found at [1].

[1] https://lkml.org/lkml/2014/6/26/481

regards,
Stan

 .../devicetree/bindings/spi/qcom,spi-qup.txt   |8 +
 drivers/spi/spi-qup.c  |  300 +++-
 2 files changed, 293 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt 
b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt
index e2c88df..a0357c7 100644
--- a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt
@@ -33,6 +33,11 @@ Optional properties:
nodes.  If unspecified, a single SPI device without a chip
select can be used.
 
+- dmas: Two DMA channel specifiers following the convention outlined
+in bindings/dma/dma.txt
+- dma-names:Names for the dma channels, if present. There must be at
+least one channel named "tx" for transmit and named "rx" for
+receive.
 
 SPI slave nodes must be children of the SPI master node and can contain
 properties described in Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -51,6 +56,9 @@ Example:
clocks = <&gcc GCC_BLSP2_QUP2_SPI_APPS_CLK>, <&gcc 
GCC_BLSP2_AHB_CLK>;
clock-names = "core", "iface";
 
+   dmas = <&blsp1_bam 13>, <&blsp2_bam 12>;
+   dma-names = "rx", "tx";
+
pinctrl-names = "default";
pinctrl-0 = <&spi8_default>;
 
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index e7fb5a0..386ae69 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define QUP_CONFIG 0x
 #define QUP_STATE  0x0004
@@ -116,6 +118,8 @@
 
 #define SPI_NUM_CHIPSELECTS4
 
+#define SPI_MAX_DMA_XFER   (SZ_64K - 64)
+
 /* high speed mode is when bus rate is greater then 26MHz */
 #define SPI_HS_MIN_RATE2600
 #define SPI_MAX_RATE   5000
@@ -143,6 +147,11 @@ struct spi_qup {
int tx_bytes;
int rx_bytes;
int qup_v1;
+
+   int dma_available;
+   struct dma_slave_config rx_conf;
+   struct dma_slave_config tx_conf;
+   atomic_tdma_outstanding;
 };
 
 
@@ -198,6 +207,16 @@ static int spi_qup_set_state(struct spi_qup *controller, 
u32 state)
return 0;
 }
 
+static int spi_qup_get_word_sz(struct spi_transfer *xfer)
+{
+   if (xfer->bits_per_word <= 8)
+   return 1;
+
+   if (xfer->bits_per_word <= 16)
+   return 2;
+
+   return 4;
+}
 
 static void spi_qup_fifo_read(struct spi_qup *controller,
struct spi_transfer *xfer)
@@ -266,6 +285,101 @@ static void spi_qup_fifo_write(struct spi_qup *controller,
}
 }
 
+static void spi_qup_dma_done(void *data)
+{
+   struct spi_qup *qup = data;
+
+   if (atomic_dec_and_test(&qup->dma_outstanding))
+   complete(&qup->done);
+}
+
+static int spi_qup_prep_sg(struct spi_master *master, struct spi_transfer 
*xfer,
+  enum dma_transfer_direction dir)
+{
+   struct spi_qup *qup = spi_master_get_devdata(master);
+   unsigned long flags = DMA_PREP_INTERRUPT | DMA_PREP_FENCE;
+   struct dma_async_tx_descriptor *desc;
+   struct scatterlist *sgl;
+   dma_cookie_t cookie;
+   unsigned int nents;
+   struct dma_chan *chan;
+   int ret;
+
+   if (dir == DMA_MEM_TO_DEV) {
+   chan = master->dma_tx;
+   nents = xfer->tx_sg.nents;
+   sgl = xfer->tx_sg.sgl;
+   } else {
+   chan = master->dma_rx;
+   nents = xfer->rx_sg.nents;
+   sgl = xfer->rx_sg.sgl;
+   }
+
+   desc = dmaengine_prep_slave_sg(chan, sgl, nents, dir, flags);
+   if (!desc)
+   return -EINVAL;
+
+   desc->callback = spi_qup_dma_done;
+   desc->callback_param = qup;
+
+   cookie = dmaengine_submit(desc);
+   ret = dma_submit_error(cookie);
+   if (ret)
+   return ret;
+
+   atomic_inc(&qup->dma_outstanding);
+
+ 

Re: [PATCH 06/12] ARM: DT: apq8064: add pci support in CM QS600

2015-02-24 Thread Stanimir Varbanov
On 02/23/2015 01:43 PM, Srinivas Kandagatla wrote:
> Hi Kumar,
> 
> Sorry, I should have dropped this patch.. PCIE is still not in the
> mainline.. :-)
> 

Srini,

Does it possible to reuse the driver which I'm trying to upstream at [1]
? I'm planing to send v2 soon.


[1] https://lkml.org/lkml/2014/12/12/557

-- 
regards,
Stan
--
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] dmaengine: qcom_bam_dma: Add support for BAM v1.7.0

2015-02-20 Thread Stanimir Varbanov
On 01/22/2015 09:04 AM, Archit Taneja wrote:
> Add register offset table entry for the newer (v1.7.0) version of the BAM IP
> found on MSM8916. Update the DT bindings documentation.
> 
> Signed-off-by: Archit Taneja 
> ---
>  .../devicetree/bindings/dma/qcom_bam_dma.txt   |  1 +
>  drivers/dma/qcom_bam_dma.c | 30 
> ++
>  2 files changed, 31 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt 
> b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
> index f8c3311..1c9d48e 100644
> --- a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
> +++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
> @@ -4,6 +4,7 @@ Required properties:
>  - compatible: must be one of the following:
>   * "qcom,bam-v1.4.0" for MSM8974, APQ8074 and APQ8084
>   * "qcom,bam-v1.3.0" for APQ8064, IPQ8064 and MSM8960
> + * "qcom,bam-v1.7.0" for MSM8916
>  - reg: Address range for DMA registers
>  - interrupts: Should contain the one interrupt shared by all channels
>  - #dma-cells: must be <1>, the cell in the dmas property of the client device
> diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
> index 3122a99..447ad12 100644
> --- a/drivers/dma/qcom_bam_dma.c
> +++ b/drivers/dma/qcom_bam_dma.c
> @@ -171,6 +171,35 @@ static const struct reg_offset_data bam_v1_4_reg_info[] 
> = {
>   [BAM_P_FIFO_SIZES]  = { 0x1820, 0x00, 0x1000, 0x00 },
>  };
>  
> +static const struct reg_offset_data bam_v1_7_reg_info[] = {
> + [BAM_CTRL]  = { 0x0, 0x00, 0x00, 0x00 },
> + [BAM_REVISION]  = { 0x01000, 0x00, 0x00, 0x00 },
> + [BAM_NUM_PIPES] = { 0x01008, 0x00, 0x00, 0x00 },
> + [BAM_DESC_CNT_TRSHLD]   = { 0x8, 0x00, 0x00, 0x00 },
> + [BAM_IRQ_SRCS]  = { 0x03010, 0x00, 0x00, 0x00 },
> + [BAM_IRQ_SRCS_MSK]  = { 0x03014, 0x00, 0x00, 0x00 },
> + [BAM_IRQ_SRCS_UNMASKED] = { 0x03018, 0x00, 0x00, 0x00 },
> + [BAM_IRQ_STTS]  = { 0x00014, 0x00, 0x00, 0x00 },
> + [BAM_IRQ_CLR]   = { 0x00018, 0x00, 0x00, 0x00 },
> + [BAM_IRQ_EN]= { 0x0001C, 0x00, 0x00, 0x00 },
> + [BAM_CNFG_BITS] = { 0x0007C, 0x00, 0x00, 0x00 },
> + [BAM_IRQ_SRCS_EE]   = { 0x03000, 0x00, 0x00, 0x80 },
> + [BAM_IRQ_SRCS_MSK_EE]   = { 0x03004, 0x00, 0x00, 0x80 },

huh, 0x80 should be 0x1000 ?

> + [BAM_P_CTRL]= { 0x13000, 0x1000, 0x00, 0x00 },
> + [BAM_P_RST] = { 0x13004, 0x1000, 0x00, 0x00 },
> + [BAM_P_HALT]= { 0x13008, 0x1000, 0x00, 0x00 },
> + [BAM_P_IRQ_STTS]= { 0x13010, 0x1000, 0x00, 0x00 },
> + [BAM_P_IRQ_CLR] = { 0x13014, 0x1000, 0x00, 0x00 },
> + [BAM_P_IRQ_EN]  = { 0x13018, 0x1000, 0x00, 0x00 },
> + [BAM_P_EVNT_DEST_ADDR]  = { 0x1382C, 0x00, 0x1000, 0x00 },
> + [BAM_P_EVNT_REG]= { 0x13818, 0x00, 0x1000, 0x00 },
> + [BAM_P_SW_OFSTS]= { 0x13800, 0x00, 0x1000, 0x00 },
> + [BAM_P_DATA_FIFO_ADDR]  = { 0x13824, 0x00, 0x1000, 0x00 },
> + [BAM_P_DESC_FIFO_ADDR]  = { 0x1381C, 0x00, 0x1000, 0x00 },
> + [BAM_P_EVNT_GEN_TRSHLD] = { 0x13828, 0x00, 0x1000, 0x00 },
> + [BAM_P_FIFO_SIZES]  = { 0x13820, 0x00, 0x1000, 0x00 },
> +};



-- 
regards,
Stan
--
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


[PATCH] dmaengine: qcom_bam_dma: fix wrong register offsets

2015-02-19 Thread Stanimir Varbanov
The commit fb93f520e (dmaengine: qcom_bam_dma: Generalize BAM
register offset calculations) wrongly populated base offsets
for event registers for bam v1.4.

Signed-off-by: Stanimir Varbanov 
---
 drivers/dma/qcom_bam_dma.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
index debe106..95b7668 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom_bam_dma.c
@@ -162,9 +162,9 @@ static const struct reg_offset_data bam_v1_4_reg_info[] = {
[BAM_P_IRQ_STTS]= { 0x1010, 0x1000, 0x00, 0x00 },
[BAM_P_IRQ_CLR] = { 0x1014, 0x1000, 0x00, 0x00 },
[BAM_P_IRQ_EN]  = { 0x1018, 0x1000, 0x00, 0x00 },
-   [BAM_P_EVNT_DEST_ADDR]  = { 0x102C, 0x00, 0x1000, 0x00 },
-   [BAM_P_EVNT_REG]= { 0x1018, 0x00, 0x1000, 0x00 },
-   [BAM_P_SW_OFSTS]= { 0x1000, 0x00, 0x1000, 0x00 },
+   [BAM_P_EVNT_DEST_ADDR]  = { 0x182C, 0x00, 0x1000, 0x00 },
+   [BAM_P_EVNT_REG]= { 0x1818, 0x00, 0x1000, 0x00 },
+   [BAM_P_SW_OFSTS]= { 0x1800, 0x00, 0x1000, 0x00 },
[BAM_P_DATA_FIFO_ADDR]  = { 0x1824, 0x00, 0x1000, 0x00 },
[BAM_P_DESC_FIFO_ADDR]  = { 0x181C, 0x00, 0x1000, 0x00 },
[BAM_P_EVNT_GEN_TRSHLD] = { 0x1828, 0x00, 0x1000, 0x00 },
-- 
1.7.0.4

--
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] dmaengine: qcom_bam_dma: Add support for BAM v1.7.0

2015-02-09 Thread Stanimir Varbanov



On 01/22/2015 11:48 PM, Andy Gross wrote:

On Thu, Jan 22, 2015 at 12:34:26PM +0530, Archit Taneja wrote:

Add register offset table entry for the newer (v1.7.0) version of the BAM IP
found on MSM8916. Update the DT bindings documentation.

Signed-off-by: Archit Taneja 
---


Looks good.

Reviewed-by: Andy Gross 



Reviewed-by: Stanimir Varbanov 

Vinod, is that one OK with you? If so could you merge it in your tree.

regards,
Stan
--
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] spmi: pmic_arb: enable build on arm64 platforms

2015-02-04 Thread Stanimir Varbanov
On 02/04/2015 05:14 PM, Paul Bolle wrote:
> On Wed, 2015-02-04 at 17:05 +0200, Stanimir Varbanov wrote:
>> On 02/03/2015 10:42 PM, Paul Bolle wrote:
>>> On Tue, 2015-02-03 at 15:50 +0200, Stanimir Varbanov wrote:
>>>> diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
>>>> index bf1295e..115348c 100644
>>>> --- a/drivers/spmi/Kconfig
>>>> +++ b/drivers/spmi/Kconfig
>>>> @@ -12,7 +12,7 @@ if SPMI
>>>>  
>>>>  config SPMI_MSM_PMIC_ARB
>>>>tristate "Qualcomm MSM SPMI Controller (PMIC Arbiter)"
>>>> -  depends on ARM
>>>> +  depends on ARM || ARM64
>>>>depends on IRQ_DOMAIN
>>>>depends on ARCH_QCOM || COMPILE_TEST
>>>>default ARCH_QCOM
>>>
>>> But only if COMPILE_TEST is set too, isn't it? Is that intended?
>>
>> No, the driver will be used on arm64 qcom platforms, also.
> 
> But ARCH_QCOM currently is (32 bit) arch/arm only, isn't it?

Currently yes, but we want to be prepared to support PMIC's which will
be used on arm64 platforms, although they are not upstream yet.

-- 
regards,
Stan
--
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] spmi: pmic_arb: enable build on arm64 platforms

2015-02-04 Thread Stanimir Varbanov
On 02/03/2015 10:42 PM, Paul Bolle wrote:
> On Tue, 2015-02-03 at 15:50 +0200, Stanimir Varbanov wrote:
>> This enables pmic arbiter driver to be build on arm64
>> platforms.
>>
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  drivers/spmi/Kconfig |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
>> index bf1295e..115348c 100644
>> --- a/drivers/spmi/Kconfig
>> +++ b/drivers/spmi/Kconfig
>> @@ -12,7 +12,7 @@ if SPMI
>>  
>>  config SPMI_MSM_PMIC_ARB
>>  tristate "Qualcomm MSM SPMI Controller (PMIC Arbiter)"
>> -depends on ARM
>> +depends on ARM || ARM64
>>  depends on IRQ_DOMAIN
>>  depends on ARCH_QCOM || COMPILE_TEST
>>  default ARCH_QCOM
> 
> But only if COMPILE_TEST is set too, isn't it? Is that intended?

No, the driver will be used on arm64 qcom platforms, also.

-- 
regards,
Stan
--
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 3/3] pinctrl: qcom: Add msm8916 pinctrl driver

2015-02-04 Thread Stanimir Varbanov
On 02/03/2015 06:47 PM, Andy Gross wrote:
> On Fri, Jan 30, 2015 at 12:04:01PM +0200, Stanimir Varbanov wrote:
>> From: Joonwoo Park 
>>
>> Add initial pinctrl driver to support pin configuration with
>> pinctrl framework for msm8916.
>>
>> Signed-off-by: Joonwoo Park 
>> Signed-off-by: Stanimir Varbanov 
>> Reviewed-by: Bjorn Andersson 
> 
> Looks good.
> 
> Reviewed-by: Andy Gross 
> 

Linus, do you want me to resend the patchset including this Reviewed-by tag?

-- 
regards,
Stan
--
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 V2 2/2] spmi: pmic_arb: add support for hw version 2

2015-02-04 Thread Stanimir Varbanov
Hi Lina, Gilad

On 02/03/2015 11:21 PM, Lina Iyer wrote:
> On Tue, Feb 03 2015 at 02:59 -0700, Stanimir Varbanov wrote:
>> Hi Gilad,
>>
>> Thanks for the patch.
>>
>> On 01/31/2015 02:46 AM, Gilad Avidov wrote:
>>> Qualcomm PMIC Arbiter version-2 changes from version-1 are:
>>>
>>> - Some different register offsets.
>>> - New channel register space, one per PMIC peripheral (ppid).
>>>   All tx traffic uses these channels.
>>> - New observer register space. All rx trafic uses this space.
>>> - Different command format for spmi command registers.
>>>
>>> Signed-off-by: Gilad Avidov 
>>> Acked-by: Sagar Dharia 
>>> ---
>>>  .../bindings/spmi/qcom,spmi-pmic-arb.txt   |   6 +-
>>>  drivers/spmi/spmi-pmic-arb.c   | 310
>>> +
>>>  2 files changed, 260 insertions(+), 56 deletions(-)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
>>> b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
>>> index 715d099..e16b9b5 100644
>>> --- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
>>> +++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
>>> @@ -1,6 +1,6 @@
>>>  Qualcomm SPMI Controller (PMIC Arbiter)
>>>
>>> -The SPMI PMIC Arbiter is found on the Snapdragon 800 Series.  It is
>>> an SPMI
>>> +The SPMI PMIC Arbiter is found on Snapdragon chipsets.  It is an SPMI
>>>  controller with wrapping arbitration logic to allow for multiple
>>> on-chip
>>>  devices to control a single SPMI master.
>>>
>>> @@ -19,6 +19,10 @@ Required properties:
>>>   "core" - core registers
>>>   "intr" - interrupt controller registers
>>>   "cnfg" - configuration registers
>>> +   Registers used only for V2 PMIC Arbiter:
>>> + "chnls"  - tx-channel per virtual slave registers.
>>> + "obsrvr" - rx-channel (called observer) per virtual slave
>>> registers.
>>> +
>>>  - reg : address + size pairs describing the PMIC arb register sets;
>>> order must
>>>  correspond with the order of entries in reg-names
>>>  - #address-cells : must be set to 2
>>> diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
>>> index 20559ab..818b2cf 100644
>>> --- a/drivers/spmi/spmi-pmic-arb.c
>>> +++ b/drivers/spmi/spmi-pmic-arb.c
>>> @@ -1,4 +1,4 @@
>>> -/* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
>>> +/* Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
>>
>> run checkpatch, there are tons of errors like white spaces and DOS line
>> ending.
> 
> I dont see any DOS line endings with these patches. I believe the
> checkpatch warnings also are false positives.
> 

My fault, I wrongly saved the patch using Thinderbird. But the above
obviously breaks multiline comments coding style rules.

-- 
regards,
Stan
--
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 V2 2/2] spmi: pmic_arb: add support for hw version 2

2015-02-03 Thread Stanimir Varbanov
On 02/03/2015 06:59 PM, Gilad Avidov wrote:
> Hi Stan,
> 
> Thank you for the review.
> 
> On 2/3/2015 2:59 AM, Stanimir Varbanov wrote:
>> Hi Gilad,
>>
>> Thanks for the patch.
>>
>> On 01/31/2015 02:46 AM, Gilad Avidov wrote:
>>> Qualcomm PMIC Arbiter version-2 changes from version-1 are:
>>>
>>> - Some different register offsets.
>>> - New channel register space, one per PMIC peripheral (ppid).
>>>All tx traffic uses these channels.
>>> - New observer register space. All rx trafic uses this space.
>>> - Different command format for spmi command registers.
>>>
>>> Signed-off-by: Gilad Avidov 
>>> Acked-by: Sagar Dharia 
>>> ---
>>>   .../bindings/spmi/qcom,spmi-pmic-arb.txt   |   6 +-
>>>   drivers/spmi/spmi-pmic-arb.c   | 310
>>> +
>>>   2 files changed, 260 insertions(+), 56 deletions(-)
>>>



>>>   +/* v1 offset per ee */
>>> +static u32 pmic_arb_offset_v1(struct spmi_pmic_arb_dev *pa, u8 sid,
>>> u16 addr)
>>> +{
>>> +return 0x800 + 0x80 * (pa->channel);
>> no braces here and in below ops
> 
> will remove braces above.
> 
> About below:
> Did you mean to remove braces from ops such as:
> 
> (sid << 8) | (addr >> 8)
> and
> (opc << 27) | ((sid & 0xf) << 20) | (addr << 4) | (bc & 0x7)
> 
> ?

no, that's fine.

> 
> In the latter case I think the braces improve readability.

I think so, too.

-- 
regards,
Stan
--
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


[PATCH] spmi: pmic_arb: enable build on arm64 platforms

2015-02-03 Thread Stanimir Varbanov
This enables pmic arbiter driver to be build on arm64
platforms.

Signed-off-by: Stanimir Varbanov 
---
 drivers/spmi/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
index bf1295e..115348c 100644
--- a/drivers/spmi/Kconfig
+++ b/drivers/spmi/Kconfig
@@ -12,7 +12,7 @@ if SPMI
 
 config SPMI_MSM_PMIC_ARB
tristate "Qualcomm MSM SPMI Controller (PMIC Arbiter)"
-   depends on ARM
+   depends on ARM || ARM64
depends on IRQ_DOMAIN
depends on ARCH_QCOM || COMPILE_TEST
default ARCH_QCOM
-- 
1.7.0.4

--
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 V2 2/2] spmi: pmic_arb: add support for hw version 2

2015-02-03 Thread Stanimir Varbanov
Hi Gilad,

Thanks for the patch.

On 01/31/2015 02:46 AM, Gilad Avidov wrote:
> Qualcomm PMIC Arbiter version-2 changes from version-1 are:
> 
> - Some different register offsets.
> - New channel register space, one per PMIC peripheral (ppid).
>   All tx traffic uses these channels.
> - New observer register space. All rx trafic uses this space.
> - Different command format for spmi command registers.
> 
> Signed-off-by: Gilad Avidov 
> Acked-by: Sagar Dharia 
> ---
>  .../bindings/spmi/qcom,spmi-pmic-arb.txt   |   6 +-
>  drivers/spmi/spmi-pmic-arb.c   | 310 
> +
>  2 files changed, 260 insertions(+), 56 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt 
> b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
> index 715d099..e16b9b5 100644
> --- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
> +++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
> @@ -1,6 +1,6 @@
>  Qualcomm SPMI Controller (PMIC Arbiter)
>  
> -The SPMI PMIC Arbiter is found on the Snapdragon 800 Series.  It is an SPMI
> +The SPMI PMIC Arbiter is found on Snapdragon chipsets.  It is an SPMI
>  controller with wrapping arbitration logic to allow for multiple on-chip
>  devices to control a single SPMI master.
>  
> @@ -19,6 +19,10 @@ Required properties:
>   "core" - core registers
>   "intr" - interrupt controller registers
>   "cnfg" - configuration registers
> +   Registers used only for V2 PMIC Arbiter:
> + "chnls"  - tx-channel per virtual slave registers.
> + "obsrvr" - rx-channel (called observer) per virtual slave registers.
> +
>  - reg : address + size pairs describing the PMIC arb register sets; order 
> must
>  correspond with the order of entries in reg-names
>  - #address-cells : must be set to 2
> diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
> index 20559ab..818b2cf 100644
> --- a/drivers/spmi/spmi-pmic-arb.c
> +++ b/drivers/spmi/spmi-pmic-arb.c
> @@ -1,4 +1,4 @@
> -/* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
> +/* Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.

run checkpatch, there are tons of errors like white spaces and DOS line
ending.

>   *
>   * 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
> @@ -25,22 +25,18 @@
>  
>  /* PMIC Arbiter configuration registers */
>  #define PMIC_ARB_VERSION 0x
> +#define PMIC_ARB_VERSION_V2_MIN  (0x2001)
>  #define PMIC_ARB_INT_EN  0x0004
>  
> -/* PMIC Arbiter channel registers */
> -#define PMIC_ARB_CMD(N)  (0x0800 + (0x80 * (N)))
> -#define PMIC_ARB_CONFIG(N)   (0x0804 + (0x80 * (N)))
> -#define PMIC_ARB_STATUS(N)   (0x0808 + (0x80 * (N)))
> -#define PMIC_ARB_WDATA0(N)   (0x0810 + (0x80 * (N)))
> -#define PMIC_ARB_WDATA1(N)   (0x0814 + (0x80 * (N)))
> -#define PMIC_ARB_RDATA0(N)   (0x0818 + (0x80 * (N)))
> -#define PMIC_ARB_RDATA1(N)   (0x081C + (0x80 * (N)))
> -
> -/* Interrupt Controller */
> -#define SPMI_PIC_OWNER_ACC_STATUS(M, N)  (0x + ((32 * (M)) + (4 * 
> (N
> -#define SPMI_PIC_ACC_ENABLE(N)   (0x0200 + (4 * (N)))
> -#define SPMI_PIC_IRQ_STATUS(N)   (0x0600 + (4 * (N)))
> -#define SPMI_PIC_IRQ_CLEAR(N)(0x0A00 + (4 * (N)))
> +/* PMIC Arbiter channel registers offsets */
> +#define PMIC_ARB_CMD (0x00)

no need braces here and below

> +#define PMIC_ARB_CONFIG  (0x04)
> +#define PMIC_ARB_STATUS  (0x08)
> +#define PMIC_ARB_WDATA0  (0x10)
> +#define PMIC_ARB_WDATA1  (0x14)
> +#define PMIC_ARB_RDATA0  (0x18)
> +#define PMIC_ARB_RDATA1  (0x1C)
> +#define PMIC_ARB_REG_CHNL(N) (0x800 + 0x4 * (N))
>  
>  /* Mapping Table */
>  #define SPMI_MAPPING_TABLE_REG(N)(0x0B00 + (4 * (N)))
> @@ -52,6 +48,7 @@
>  
>  #define SPMI_MAPPING_TABLE_LEN   255
>  #define SPMI_MAPPING_TABLE_TREE_DEPTH16  /* Maximum of 16-bits */
> +#define PPID_TO_CHAN_TABLE_SZBIT(12) /* PPID is 12bit chan 
> is 1byte*/
>  
>  /* Ownership Table */
>  #define SPMI_OWNERSHIP_TABLE_REG(N)  (0x0700 + (4 * (N)))
> @@ -88,6 +85,7 @@ enum pmic_arb_cmd_op_code {
>  
>  /* Maximum number of support PMIC peripherals */
>  #define PMIC_ARB_MAX_PERIPHS 256
> +#define PMIC_ARB_MAX_CHNL128
>  #define PMIC_ARB_PERIPH_ID_VALID (1 << 15)
>  #define PMIC_ARB_TIMEOUT_US  100
>  #define PMIC_ARB_MAX_TRANS_BYTES (8)
> @@ -98,14 +96,17 @@ enum pmic_arb_cmd_op_code {
>  /* interrupt enable bit */
>  #define SPMI_PIC_ACC_ENABLE_BIT  BIT(0)
>  
> +struct pmic_arb_ver_ops;
> +
>  /**
>   * spmi_pmic_arb_dev - SPMI P

Re: [PATCH V2 1/2] spmi: remove wakeup command before slave probe

2015-02-03 Thread Stanimir Varbanov
On 01/31/2015 02:46 AM, Gilad Avidov wrote:
> According to spmi spec a slave powers up into startup state and then
> transitions into active state. Thus, the wakeup command is not required
> before calling the slave's probe. The wakeup command is only needed for
> slaves that are in sleep state after receiving the sleep command.
> 
> This is a bug since spmi master controllers, such as spmi-pmic-arb,
> which have no support for wakeup command return an error on that
> command and thus fail before reaching a slave driver probe.
> 
> Cc: ga...@codeaurora.org
> Acked-by: Sagar Dharia 
> Signed-off-by: Gilad Avidov 
> ---
>  drivers/spmi/spmi.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/spmi/spmi.c b/drivers/spmi/spmi.c
> index 1d92f51..9ff7454 100644
> --- a/drivers/spmi/spmi.c
> +++ b/drivers/spmi/spmi.c
> @@ -1,4 +1,4 @@
> -/* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
> +/* Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.

run chackpatch please.



-- 
regards,
Stan
--
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 v4] thermal: Add QPNP PMIC temperature alarm driver

2015-02-02 Thread Stanimir Varbanov
On 02/02/2015 05:19 PM, Ivan T. Ivanov wrote:
> Add support for the temperature alarm peripheral found inside
> Qualcomm plug-and-play (QPNP) PMIC chips. The temperature alarm
> peripheral outputs a pulse on an interrupt line whenever the
> thermal over temperature stage value changes.
> 
> Register a thermal sensor. The temperature reported by this thermal
> sensor device should reflect the actual PMIC die temperature if an
> ADC is present on the given PMIC. If no ADC is present, then the
> reported temperature should be estimated from the over temperature
> stage value.
> 
> Cc: David Collins 
> Signed-off-by: Ivan T. Ivanov 
> ---
> 



> +
> + ret = qpnp_tm_init(chip);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "init failed\n");
> + goto fail;
> + }
> +
> + chip->tz_dev = thermal_zone_of_sensor_register(&pdev->dev, 0, chip,
> + &qpnp_tm_sensor_ops);
> + if (IS_ERR(chip->tz_dev)) {
> + dev_err(&pdev->dev, "failed to register sensor\n");
> + ret = PTR_ERR(chip->tz_dev);
> + goto fail;
> + }
> +
> + ret = devm_request_threaded_irq(&pdev->dev, irq, NULL, qpnp_tm_isr,
> + IRQF_ONESHOT, node->name, chip);
> + if (ret < 0)
> + goto unreg;
> +
> + return 0;
> +
> +unreg:
> + thermal_zone_of_sensor_unregister(&pdev->dev, chip->tz_dev);

Any problem to request_irq before thermal_zone_of_sensor_register? It
will avoid having thermal sensor unregister call.

> +fail:
> + if (!IS_ERR(chip->adc))
> + iio_channel_release(chip->adc);
> +
> + return ret;
> +}



-- 
regards,
Stan
--
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


[PATCH 2/3] pinctrl: qcom: enable generic pinconf

2015-01-30 Thread Stanimir Varbanov
This makes the pinctrl driver to use the generic pinconf
interface. Mainly it gives us a way to use debugfs to dump
group configurations.

Signed-off-by: Stanimir Varbanov 
---
 drivers/pinctrl/qcom/pinctrl-msm.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 49d3f4f..b66cd58 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -197,7 +197,6 @@ static int msm_config_reg(struct msm_pinctrl *pctrl,
*mask = 1;
break;
default:
-   dev_err(pctrl->dev, "Invalid config param %04x\n", param);
return -ENOTSUPP;
}
 
@@ -262,8 +261,6 @@ static int msm_config_group_get(struct pinctrl_dev *pctldev,
arg = !!(val & BIT(g->in_bit));
break;
default:
-   dev_err(pctrl->dev, "Unsupported config parameter: %x\n",
-   param);
return -EINVAL;
}
 
@@ -357,6 +354,7 @@ static int msm_config_group_set(struct pinctrl_dev *pctldev,
 }
 
 static const struct pinconf_ops msm_pinconf_ops = {
+   .is_generic = true,
.pin_config_group_get   = msm_config_group_get,
.pin_config_group_set   = msm_config_group_set,
 };
-- 
1.7.0.4

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


[PATCH 3/3] pinctrl: qcom: handle input-enable pinconf property

2015-01-30 Thread Stanimir Varbanov
This enables support of 'input-enable' pinconf generic property in
the pinctrl driver.

Signed-off-by: Stanimir Varbanov 
---
 drivers/pinctrl/qcom/pinctrl-msm.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
index b66cd58..55a64ea 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -193,6 +193,7 @@ static int msm_config_reg(struct msm_pinctrl *pctrl,
*mask = 7;
break;
case PIN_CONFIG_OUTPUT:
+   case PIN_CONFIG_INPUT_ENABLE:
*bit = g->oe_bit;
*mask = 1;
break;
@@ -260,6 +261,12 @@ static int msm_config_group_get(struct pinctrl_dev 
*pctldev,
val = readl(pctrl->regs + g->io_reg);
arg = !!(val & BIT(g->in_bit));
break;
+   case PIN_CONFIG_INPUT_ENABLE:
+   /* Pin is output */
+   if (arg)
+   return -EINVAL;
+   arg = 1;
+   break;
default:
return -EINVAL;
}
@@ -330,6 +337,10 @@ static int msm_config_group_set(struct pinctrl_dev 
*pctldev,
/* enable output */
arg = 1;
break;
+   case PIN_CONFIG_INPUT_ENABLE:
+   /* disable output */
+   arg = 0;
+   break;
default:
dev_err(pctrl->dev, "Unsupported config parameter: 
%x\n",
param);
-- 
1.7.0.4

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


[PATCH 1/3] pinctrl: qcom: delete pin_config_get/set pinconf operations

2015-01-30 Thread Stanimir Varbanov
The .pin_config_get/set operation are not supported in qcom pinctrl
driver. As the pinconf core is smart enough it doesn't complain
about that.

Signed-off-by: Stanimir Varbanov 
---
 drivers/pinctrl/qcom/pinctrl-msm.c |   17 -
 1 files changed, 0 insertions(+), 17 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
index e730935..49d3f4f 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -204,21 +204,6 @@ static int msm_config_reg(struct msm_pinctrl *pctrl,
return 0;
 }
 
-static int msm_config_get(struct pinctrl_dev *pctldev,
- unsigned int pin,
- unsigned long *config)
-{
-   dev_err(pctldev->dev, "pin_config_set op not supported\n");
-   return -ENOTSUPP;
-}
-
-static int msm_config_set(struct pinctrl_dev *pctldev, unsigned int pin,
-   unsigned long *configs, unsigned num_configs)
-{
-   dev_err(pctldev->dev, "pin_config_set op not supported\n");
-   return -ENOTSUPP;
-}
-
 #define MSM_NO_PULL0
 #define MSM_PULL_DOWN  1
 #define MSM_KEEPER 2
@@ -372,8 +357,6 @@ static int msm_config_group_set(struct pinctrl_dev *pctldev,
 }
 
 static const struct pinconf_ops msm_pinconf_ops = {
-   .pin_config_get = msm_config_get,
-   .pin_config_set = msm_config_set,
.pin_config_group_get   = msm_config_group_get,
.pin_config_group_set   = msm_config_group_set,
 };
-- 
1.7.0.4

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


[PATCH 0/3] pinctrl: qcom: enable generic pinconf and input-enable

2015-01-30 Thread Stanimir Varbanov
Here is splitted version of the previous patch at [1].

The major change is in 3/3 where now we check oe_bit in control register
instead of in_bit in io register.

regards
Stan

[1] https://lkml.org/lkml/2015/1/26/514

Stanimir Varbanov (3):
  pinctrl: qcom: delete pin_config_get/set pinconf operations
  pinctrl: qcom: enable generic pinconf
  pinctrl: qcom: handle input-enable pinconf property

 drivers/pinctrl/qcom/pinctrl-msm.c |   32 
 1 files changed, 12 insertions(+), 20 deletions(-)

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


[PATCH v3 3/3] pinctrl: qcom: Add msm8916 pinctrl driver

2015-01-30 Thread Stanimir Varbanov
From: Joonwoo Park 

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

Signed-off-by: Joonwoo Park 
Signed-off-by: Stanimir Varbanov 
Reviewed-by: Bjorn Andersson 
---
 drivers/pinctrl/qcom/Kconfig   |8 +
 drivers/pinctrl/qcom/Makefile  |1 +
 drivers/pinctrl/qcom/pinctrl-msm8916.c | 1005 
 3 files changed, 1014 insertions(+), 0 deletions(-)
 create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8916.c

diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 3cd243c..ea575f6 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -47,6 +47,14 @@ config PINCTRL_MSM8X74
  This is the pinctrl, pinmux, pinconf and gpiolib driver for the
  Qualcomm TLMM block found in the Qualcomm 8974 platform.
 
+config PINCTRL_MSM8916
+   tristate "Qualcomm 8916 pin controller driver"
+   depends on GPIOLIB && OF
+   select PINCTRL_MSM
+   help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm TLMM block found on the Qualcomm 8916 platform.
+
 config PINCTRL_QCOM_SPMI_PMIC
tristate "Qualcomm SPMI PMIC pin controller driver"
depends on GPIOLIB && OF && SPMI
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index bfd79af..6895870 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -5,5 +5,6 @@ obj-$(CONFIG_PINCTRL_APQ8084)   += pinctrl-apq8084.o
 obj-$(CONFIG_PINCTRL_IPQ8064)  += pinctrl-ipq8064.o
 obj-$(CONFIG_PINCTRL_MSM8960)  += pinctrl-msm8960.o
 obj-$(CONFIG_PINCTRL_MSM8X74)  += pinctrl-msm8x74.o
+obj-$(CONFIG_PINCTRL_MSM8916)  += pinctrl-msm8916.o
 obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-gpio.o
 obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-mpp.o
diff --git a/drivers/pinctrl/qcom/pinctrl-msm8916.c 
b/drivers/pinctrl/qcom/pinctrl-msm8916.c
new file mode 100644
index 000..20ebf24
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-msm8916.c
@@ -0,0 +1,1005 @@
+/*
+ * Copyright (c) 2015, 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 "pinctrl-msm.h"
+
+static const struct pinctrl_pin_desc msm8916_pins[] = {
+   PINCTRL_PIN(0, "GPIO_0"),
+   PINCTRL_PIN(1, "GPIO_1"),
+   PINCTRL_PIN(2, "GPIO_2"),
+   PINCTRL_PIN(3, "GPIO_3"),
+   PINCTRL_PIN(4, "GPIO_4"),
+   PINCTRL_PIN(5, "GPIO_5"),
+   PINCTRL_PIN(6, "GPIO_6"),
+   PINCTRL_PIN(7, "GPIO_7"),
+   PINCTRL_PIN(8, "GPIO_8"),
+   PINCTRL_PIN(9, "GPIO_9"),
+   PINCTRL_PIN(10, "GPIO_10"),
+   PINCTRL_PIN(11, "GPIO_11"),
+   PINCTRL_PIN(12, "GPIO_12"),
+   PINCTRL_PIN(13, "GPIO_13"),
+   PINCTRL_PIN(14, "GPIO_14"),
+   PINCTRL_PIN(15, "GPIO_15"),
+   PINCTRL_PIN(16, "GPIO_16"),
+   PINCTRL_PIN(17, "GPIO_17"),
+   PINCTRL_PIN(18, "GPIO_18"),
+   PINCTRL_PIN(19, "GPIO_19"),
+   PINCTRL_PIN(20, "GPIO_20"),
+   PINCTRL_PIN(21, "GPIO_21"),
+   PINCTRL_PIN(22, "GPIO_22"),
+   PINCTRL_PIN(23, "GPIO_23"),
+   PINCTRL_PIN(24, "GPIO_24"),
+   PINCTRL_PIN(25, "GPIO_25"),
+   PINCTRL_PIN(26, "GPIO_26"),
+   PINCTRL_PIN(27, "GPIO_27"),
+   PINCTRL_PIN(28, "GPIO_28"),
+   PINCTRL_PIN(29, "GPIO_29"),
+   PINCTRL_PIN(30, "GPIO_30"),
+   PINCTRL_PIN(31, "GPIO_31"),
+   PINCTRL_PIN(32, "GPIO_32"),
+   PINCTRL_PIN(33, "GPIO_33"),
+   PINCTRL_PIN(34, "GPIO_34"),
+   PINCTRL_PIN(35, "GPIO_35"),
+   PINCTRL_PIN(36, "GPIO_36"),
+   PINCTRL_PIN(37, "GPIO_37"),
+   PINCTRL_PIN(38, "GPIO_38"),
+   PINCTRL_PIN(39, "GPIO_39"),
+   PINCTRL_PIN(40, "GPIO_40"),
+   PINCTRL_PIN(41, "GPIO_41"),
+   PINCTRL_PIN(42, "GPIO_42"),
+   PINCTRL_PIN(43, "GPIO_43"),
+   PINCTRL_PIN(44, "GPIO_44"),
+   PINCTRL_PIN(45, "GPIO_45"),
+   PINCTRL_PIN(46, "GPIO_46"),
+   PINCTRL_PIN(47, "GPIO_47&

[PATCH v3 2/3] DT: pinctrl: Document Qualcomm MSM8916 pinctrl binding

2015-01-30 Thread Stanimir Varbanov
Adds devicetree binding documentation.

Signed-off-by: Stanimir Varbanov 
Reviewed-by: Bjorn Andersson 
---
 .../bindings/pinctrl/qcom,msm8916-pinctrl.txt  |  186 
 1 files changed, 186 insertions(+), 0 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt
new file mode 100644
index 000..498caff
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt
@@ -0,0 +1,186 @@
+Qualcomm MSM8916 TLMM block
+
+This binding describes the Top Level Mode Multiplexer block found in the
+MSM8916 platform.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,msm8916-pinctrl"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: the base address and size of the TLMM register space.
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: should specify the TLMM summary IRQ.
+
+- interrupt-controller:
+   Usage: required
+   Value type: 
+   Definition: identifies this node as an interrupt controller
+
+- #interrupt-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 2. Specifying the pin number and flags, as defined
+   in 
+
+- gpio-controller:
+   Usage: required
+   Value type: 
+   Definition: identifies this node as a gpio controller
+
+- #gpio-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 2. Specifying the pin number and flags, as defined
+   in 
+
+Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
+a general description of GPIO and interrupt bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+The pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, drive strength, etc.
+
+
+PIN CONFIGURATION NODES:
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function.
+
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pin configuration subnode:
+
+- pins:
+   Usage: required
+   Value type: 
+   Definition: List of gpio pins affected by the properties specified in
+   this subnode.  Valid pins are:
+   gpio0-gpio121,
+   sdc1_clk,
+   sdc1_cmd,
+   sdc1_data
+   sdc2_clk,
+   sdc2_cmd,
+   sdc2_data,
+   qdsd_cmd,
+   qdsd_data0,
+   qdsd_data1,
+   qdsd_data2,
+   qdsd_data3
+
+- function:
+   Usage: required
+   Value type: 
+   Definition: Specify the alternative function to be configured for the
+   specified pins. Functions are only valid for gpio pins.
+   Valid values are:
+   adsp_ext, alsp_int, atest_bbrx0, atest_bbrx1, atest_char, atest_char0,
+   atest_char1, atest_char2, atest_char3, atest_combodac, atest_gpsadc0,
+   atest_gpsadc1, atest_tsens, atest_wlan0, atest_wlan1, backlight_en,
+   bimc_dte0,bimc_dte1, blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4,
+   blsp_i2c5, blsp_i2c6, blsp_spi1, blsp_spi1_cs1, blsp_spi1_cs2,
+   blsp_spi1_cs3, blsp_spi2, blsp_spi2_cs1, blsp_spi2_cs2, blsp_spi2_cs3,
+   blsp_spi3, blsp_spi3_cs1, blsp_spi3_cs2, blsp_spi3_cs3, blsp_spi4,
+   blsp_spi5, blsp_spi6, blsp_uart1, blsp_uart2, blsp_uim1, blsp_uim2,
+   cam1_rst, cam1_standby, cam_mclk0, cam_mclk1, cci_async, cci_i2c,
+   cci_timer0, cci_timer1, cci_timer2, cdc_pdm0, codec_mad, dbg_out,
+   display_5v, dmic0_clk, dmic0_data, dsi_rst, ebi0_wrcdc, euro_us,
+   ext_lpass, flash_strobe, gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a,
+   gcc_gp2_clk_b, gcc_gp3_clk_a, gcc_gp3_clk_b, gpio, gsm0_tx0, gsm0_tx1,
+   gsm1_tx0, gsm1_tx1, gyro_accl, kpsns0, kpsns1, kpsns2, ldo_en,
+   ldo_update, mag_int, mdp_vsync, modem_tsync, m_voc

[PATCH v3 0/3] pinctrl: Qualcomm msm8916 pinctrl driver

2015-01-30 Thread Stanimir Varbanov
Changes since v2:
 - addressed all Andy's comments
 
---

Changes since v1:
 - correct the subject and description in 1/3
 - not break the fields in msm8916_groups[] array in 3/3
 - added Reviewed-by tags on all three patches

---

This series adds a pinctrl driver for Snapdragon 410 (msm8916) SoC. The first
patch increase the register address variable size, next adds a binding document
and the last patch adds the pinctrl driver

Comments are welcome!

regards,
Stan

Joonwoo Park (2):
  pinctrl: qcom: increase variable size for register offsets
  pinctrl: qcom: Add msm8916 pinctrl driver

Stanimir Varbanov (1):
  DT: pinctrl: Document Qualcomm MSM8916 pinctrl binding

 .../bindings/pinctrl/qcom,msm8916-pinctrl.txt  |  186 
 drivers/pinctrl/qcom/Kconfig   |8 +
 drivers/pinctrl/qcom/Makefile  |1 +
 drivers/pinctrl/qcom/pinctrl-msm.h |   10 +-
 drivers/pinctrl/qcom/pinctrl-msm8916.c | 1005 
 5 files changed, 1205 insertions(+), 5 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt
 create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8916.c

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


[PATCH v3 1/3] pinctrl: qcom: increase variable size for register offsets

2015-01-30 Thread Stanimir Varbanov
From: Joonwoo Park 

On newer TLMM hardware blocks the registers are spread and
we need an offsets upper than 16 bits to address them. Increase
the register offset variables to 32 bits size.

Signed-off-by: Joonwoo Park 
Signed-off-by: Stanimir Varbanov 
Reviewed-by: Bjorn Andersson 
---
 drivers/pinctrl/qcom/pinctrl-msm.h |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.h 
b/drivers/pinctrl/qcom/pinctrl-msm.h
index b952c4b..54fdd04 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.h
+++ b/drivers/pinctrl/qcom/pinctrl-msm.h
@@ -70,11 +70,11 @@ struct msm_pingroup {
unsigned *funcs;
unsigned nfuncs;
 
-   s16 ctl_reg;
-   s16 io_reg;
-   s16 intr_cfg_reg;
-   s16 intr_status_reg;
-   s16 intr_target_reg;
+   u32 ctl_reg;
+   u32 io_reg;
+   u32 intr_cfg_reg;
+   u32 intr_status_reg;
+   u32 intr_target_reg;
 
unsigned mux_bit:5;
 
-- 
1.7.0.4

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


  1   2   3   >