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

Re: [PATCH V7 2/3] dma: add Qualcomm Technologies HIDMA management driver

2015-12-08 Thread Sinan Kaya 
On 12/5/2015 2:58 AM, Vinod Koul wrote:
> On Tue, Dec 01, 2015 at 11:57:34PM -0500, Sinan Kaya wrote:
>> On 11/30/2015 10:17 PM, Vinod Koul wrote:
>>> On Mon, Nov 30, 2015 at 09:42:01AM -0500, Sinan Kaya wrote:
>>>
>> +static int hidma_mgmt_probe(struct platform_device *pdev)
>> +{
>> +struct hidma_mgmt_dev *mgmtdev;
>> +struct resource *res;
>> +void __iomem *virtaddr;
>> +int irq;
>> +int rc;
>> +u32 val;
>> +
>> +pm_runtime_set_autosuspend_delay(>dev, 
>> AUTOSUSPEND_TIMEOUT);
>> +pm_runtime_use_autosuspend(>dev);
>> +pm_runtime_set_active(>dev);
>> +pm_runtime_enable(>dev);
>
> at this time pm core will treat device as fully enabled and pm methods can
> be invoked, but you are not ready yet right. Typically these are done at 
> the
> end of the probe unless you have a reason... 

 I need it here because the clocks are declared as ACPI power resources.
 The kernel is turning off all power resources during initialization. In
 order for this code to touch the hardware, I need to call enable so that
 clocks are enabled once again.
>>>
>>> The question is are you ready in your driver routines to be invoked by pm
>>> core?
>>>
>>
>> I don't have any support for suspend and resume PM APIs. The only PM
>> interface I support is PM runtime. PM can turn on/off the clocks based
>> on the reference counts it maintains after get/set APIs. Since PM is
>> turning off the clocks during power up before my driver load, I do need
>> to grab this lock to re-enable it during HW initialization. Then, let PM
>> turn off the clocks again after the AUTOSUSPEND_TIMEOUT when I'm done.
>>
>> Is there any other interaction with the PM that I'm not aware of?
> 
> No this is fine. The the runtime_resume will be onvoked and it will request
> resources are those set before you enable the device?
> 

Yes, the only resource that this device needs for power management is
the ACPI power resources. The device does not support suspend/resume via
traditional _PS0 and _PS3 calls. ACPI power resources are initialized
during power up while ACPI is being enumerated.

The probing of the HIDMA driver happens much afterwards.


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

Re: [PATCH V7 3/3] dma: add Qualcomm Technologies HIDMA channel driver

2015-12-08 Thread Sinan Kaya 
On 12/5/2015 3:00 AM, Vinod Koul wrote:
> On Wed, Dec 02, 2015 at 02:04:05PM -0500, Sinan Kaya wrote:
> You are missing the point. Channel can be paused, yes but the descriptor
> is in queue and is not paused. The descriptor running is paused, yes.
> There is subtle difference between these
>>> I'll follow your recommendation. PAUSE for the currently active
>>> descriptor and DMA_IN_PROGRESS for the rest.
>>>
>>
>> I'm now confused.
>>
>> I looked at several DMA driver implementations.
>>
>> 1. They call dma_cookie_status function to see if the job is done.
>> 2. If done, they return right ahead.
>> 3. Otherwise, dma_cookie_status returns DMA_IN_PROGRESS.
>> 4. Next the code checks if the channel is paused and return value is
>> DMA_IN_PROGRESS. The code changes return code to DMA_PAUSED.
>>
>> Whereas, I was returning paused first before even checking if the
>> descriptor is done. Are you OK with the sequence 1..4 above?
> 
> Yes am okay with this with slight change in 4.
> 
> You should set to PAUSED only for current descriptor and not for the ones in
> queue
> 
OK, I'll work on it.

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

Re: [PATCH RFC 21/27] drivers: cpu-pd: Parse topology to setup CPU PM domains

2015-12-08 Thread Lina Iyer 

On Mon, Dec 07 2015 at 07:53 -0700, Lorenzo Pieralisi wrote:

Hi Lina,

On Tue, Nov 17, 2015 at 03:37:45PM -0700, Lina Iyer wrote:

Architectures that support CPU domain control in the firmware specify
the domain heirarchy as part of the topology nodes. Parse and initialize
domains from the topology node for such architectures.

Cc: Rob Herring 
Cc: Stephen Boyd 
Cc: Kevin Hilman 
Cc: Ulf Hansson 
Cc: Lorenzo Pieralisi 
Signed-off-by: Lina Iyer 
---
 drivers/base/power/cpu-pd.c | 76 +
 include/linux/cpu-pd.h  |  1 +
 2 files changed, 77 insertions(+)

diff --git a/drivers/base/power/cpu-pd.c b/drivers/base/power/cpu-pd.c
index e331ae6..2872c18 100644
--- a/drivers/base/power/cpu-pd.c
+++ b/drivers/base/power/cpu-pd.c
@@ -429,3 +429,79 @@ int of_attach_cpu_pm_domain(struct device_node *dn)
return 0;
 }
 EXPORT_SYMBOL(of_attach_cpu_pm_domain);
+
+static int of_parse_cpu_pd(struct device_node *cluster,
+   const struct cpu_pd_ops *ops)
+{
+   struct device_node *domain_node;
+   struct generic_pm_domain *genpd;
+   char name[10];
+   struct device_node *c;
+   int i, ret;
+
+   for (i = 0; ; i++) {
+   snprintf(name, sizeof(name), "cluster%d", i);
+   c = of_get_child_by_name(cluster, name);
+   if (!c)
+   break;
+
+   domain_node = of_parse_phandle(c, "cluster", 0);
+   if (!domain_node)
+   return -1;
+
+   /* Initialize CPU PM domain domain at this level */
+   genpd = of_init_cpu_pm_domain(domain_node, ops);
+   if (IS_ERR(genpd))
+   return -1;
+
+   /* Initialize and attach child domains */
+   ret = of_parse_cpu_pd(c, ops);
+
+   /*
+* Attach the domain to its parent after reading
+* the children, so the mask of CPUs in this domain
+* are setup correctly.
+*/
+   if (!ret)
+   of_attach_cpu_pm_domain(domain_node);
+
+   of_node_put(c);
+   if (ret != 0)
+   return ret;
+   }
+
+   return 0;
+}
+
+/**
+ * of_setup_cpu_domain_topology() - Setup the CPU domains from the CPU
+ * topology node in DT.
+ *
+ * @ops: The PM domain suspend/resume ops for all the domains in the topology
+ */
+int of_setup_cpu_domain_topology(const struct cpu_pd_ops *ops)
+{
+   struct device_node *cn, *map;
+   int ret = 0;
+
+   cn = of_find_node_by_path("/cpus");
+   if (!cn) {
+   pr_err("No CPU information found in DT\n");
+   return 0;
+   }
+
+   map = of_get_child_by_name(cn, "cpu-map");
+   if (!map)
+   goto out;


I commented on this before, is this reliance on cpu-map necessary ?
Could not you just rely on the "power-domains" phandle in the cpu
nodes to build the cpumask for a specific power domain ? I think
you should try to decouple the concept of power domain from the cpu-map
cluster and I think this would also simplify your code in the process.


Sorry, I missed seeing your comment on this earlier.

Hmm, it can be done, but I felt out of place to define just power
domains that have no devices in Linux, since they are handled in PSCI,
but also have no relation to PSCI. Hence, I felt cpu-map to be a good
place for the cluster domain. But I am not strongly inclined. I can
remove them from the cpu-map and keep them as separate nodes. However,
it would be nice to have a way to say these nodes are PSCI controlled.

Thanks,
Lina


So to sum it up, I'd suggest you build the power domain cpumask by
enumerating the cpus pointing at a specific power-domain node.




+
+   ret = of_parse_cpu_pd(map, ops);
+   if (ret != 0)
+   goto out_map;
+
+out_map:
+   of_node_put(map);
+out:
+   of_node_put(cn);
+   return ret;
+}
+EXPORT_SYMBOL(of_setup_cpu_domain_topology);
diff --git a/include/linux/cpu-pd.h b/include/linux/cpu-pd.h
index 489ee2f..e8290db 100644
--- a/include/linux/cpu-pd.h
+++ b/include/linux/cpu-pd.h
@@ -32,4 +32,5 @@ struct cpu_pm_domain {
 struct generic_pm_domain *of_init_cpu_pm_domain(struct device_node *dn,
const struct cpu_pd_ops *ops);
 int of_attach_cpu_pm_domain(struct device_node *dn);
+int of_setup_cpu_domain_topology(const struct cpu_pd_ops *ops);
 #endif /* __CPU_PD_H__ */
--
2.1.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 1/3] dt-binding: power: Add otg regulator binding

2015-12-08 Thread Tim Bird 
Add a binding for the regulator which controls the OTG chargepath switch.
The OTG switch gets its power from pm8941_5vs1, and that should be
expressed as a usb-otg-in-supply property in the DT node for the
charger driver.  The regulator name is "otg".

Signed-off-by: Tim Bird 
---
Changes since v1
 - switch supply name to have dashes instead of underscores
 - remove superfluous DT explanations in the otg node description
---
 .../devicetree/bindings/power_supply/qcom_smbb.txt| 19 +++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt 
b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
index 65b88fa..28b6da7 100644
--- a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
+++ b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
@@ -105,6 +105,22 @@ PROPERTIES
regulation must be done externally to fully comply with
the JEITA safety guidelines if this flag is set.
 
+- usb-otg-in-supply:
+  Usage: optional
+  Value type: 
+  Description: Reference to the regulator supplying power to the USB_OTG_IN
+   pin.
+
+child nodes:
+- otg:
+  Usage: optional
+  Description: This node defines a regulator used to control the direction
+   of VBUS voltage - specifically: whether to supply voltage
+   to VBUS for host mode operation of the OTG port, or allow
+   input voltage from external VBUS for charging.  In the
+   hardware, the supply for this regulator comes from
+   usb-otg-in-supply.
+
 EXAMPLE
 charger@1000 {
compatible = "qcom,pm8941-charger";
@@ -128,4 +144,7 @@ charger@1000 {
 
qcom,fast-charge-current-limit = <100>;
qcom,dc-charge-current-limit = <100>;
+   usb-otg-in-supply = <_5vs1>;
+
+   otg {};
 };
-- 
2.4.2

--
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: [RFC][PATCH] misc: Introduce reboot_reason driver

2015-12-08 Thread John Stultz 
On Tue, Dec 8, 2015 at 2:07 PM, Bjorn Andersson
 wrote:
> On Tue 08 Dec 13:29 PST 2015, John Stultz wrote:
>
>> This patch adds a basic driver to allow for commands like
>> "reboot bootloader" and "reboot recovery" to communicate this
>> reboot-reason to the bootloader.
>>
>> This is commonly done on Android devices, in order to reboot
>> the device into fastboot or recovery mode. It also supports
>> custom OEM specific commands, via "reboot oem-".
>>
>> This driver pulls the phys memory address from DT as well as
>> the magic reason values that are written to the address for
>> each mode.
>>
>> For an example, this patch also adds the DT support for
>> the nexus7 device via its dts (which is not yet upstream).
>>
>> Thoughts and feedback would be appreciated!
>>
>
> Good to see some work on this, I want it too :)
>
> I do however think this is Qualcomm specific in its implementation, so
> adding Andy and linux-arm-msm.

Right. So this is based off of the qualcomm implementation. But I'm
hoping to reuse it for other hardware.


> [..]
>> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts 
>> b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> index 5183d18..ee5dcb7 100644
>> --- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> @@ -282,6 +282,15 @@
>>   };
>>   };
>>
>> + reboot_reason: reboot_reason@2a03f65c {
>> + compatible  = "reboot_reason";
>> + reg = <0x2A03F65C 0x4>;
>> + reason,none = <0x77665501>;
>> + reason,bootloader   = <0x77665500>;
>> + reason,recovery = <0x77665502>;
>> + reason,oem  = <0x6f656d00>;
>> + };
>> +
>
> This address refers to IMEM, which is shared with a number of other
> uses. So I think we should have a simple-mfd (and syscon) with this
> within.

Errr.. I'm going to have to read up there. I'm not super familiar with
any of those drivers, so I'll try to see how exactly they would map in
here.


> I like the fact that you don't hard code the magics in the
> implementation, as I've seen additions from multiple places - so perhaps
> it should be made even more flexible.
>
> OMAP seems to use strings here instead of magics, but the delivery
> mechanism looks to be the same. But I think of this as Qualcomm
> specific.

Yea. This is good feedback. EFI bootloaders have their own
implementations as well.  I suspect we'll need a few different driver
"types" to handle these differences, ie: value vs string.

I'll maybe extend the compatible string to make it clear that this is
a "value" style, and we can extend it with a string type later if
folks care?

>> +static int reboot_reason(struct notifier_block *nb, unsigned long action,
>> + void *data)
>> +{
>> + char *cmd = (char *)data;
>> + long reason = reasons[NONE];
>> +
>> + if (!reboot_reason_addr)
>> + return NOTIFY_DONE;
>> +
>> + if (cmd != NULL) {
>> + if (!strncmp(cmd, "bootloader", 10))
>> + reason = reasons[BOOTLOADER];
>> + else if (!strncmp(cmd, "recovery", 8))
>> + reason = reasons[RECOVERY];
>> + else if (!strncmp(cmd, "oem-", 4)) {
>> + unsigned long code;
>> +
>> + if (!kstrtoul(cmd+4, 0, ))
>> + reason = reasons[OEM] | (code & 0xff);
>> + }
>> + }
>
> In the case where we didn't find a match you should write the "normal"
> reason here, otherwise I think you will end up in recovery when recovery
> issues a reboot (in Android that is).

So, reason is initialized to NONE here. So that should handle this,
no? Or do you mean something more subtle?

>
>> +
>> + if (reason != -1)
>> + writel(reason, reboot_reason_addr);
>> + return NOTIFY_DONE;
>> +}
>> +
>> +static int reboot_reason_probe(struct platform_device *pdev)
>> +{
>> + struct resource *res;
>> + u32 val;
>> + int i;
>> +
>> + /* initialize the reasons */
>> + for (i = 0; i < MAX_REASONS; i++)
>> + reasons[i] = -1;
>> +
>> + /* Try to grab the reason io address */
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + reboot_reason_addr = devm_ioremap_resource(>dev, res);
>> + if (IS_ERR(reboot_reason_addr))
>> + return PTR_ERR(reboot_reason_addr);
>> +
>
> Please acquire this memory from a syscon (preferably the the parent
> simple-mfd).

Ok. Will look into this. Sorry for my unfamiliarity with these details.


>> + /* initialize specified reasons from DT */
>> + if (!of_property_read_u32(pdev->dev.of_node, "reason,none", ))
>> + reasons[NONE] = val;
>> + if

[PATCH v2 3/3] ARM: dts: qcom: add charger otg regulator

2015-12-08 Thread Tim Bird 
Add the otg regulator provided by the charger block.

Signed-off-by: Tim Bird 
---
 arch/arm/boot/dts/qcom-pm8941.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi 
b/arch/arm/boot/dts/qcom-pm8941.dtsi
index b0d4439..1b80100 100644
--- a/arch/arm/boot/dts/qcom-pm8941.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
@@ -45,6 +45,10 @@
  "chg-gone",
  "usb-valid",
  "dc-valid";
+
+   usb-otg-in-supply = <_5vs1>;
+
+   chg_otg: otg { };
};
 
pm8941_gpios: gpios@c000 {
-- 
2.4.2

--
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/3] power: qcom_smbb: Add otg regulator for control of vbus

2015-12-08 Thread Tim Bird 
Add a regulator to control the OTG chargepath switch.  This
is used by USB code to control VBUS direction - out for host mode
on the OTG port, and in for charging mode.

Signed-off-by: Tim Bird 
---
Changes since v1:
 - changed name of supply to remove underscores
---
 drivers/power/qcom_smbb.c | 74 +++
 1 file changed, 74 insertions(+)

diff --git a/drivers/power/qcom_smbb.c b/drivers/power/qcom_smbb.c
index 5eb1e9e..2f1394c 100644
--- a/drivers/power/qcom_smbb.c
+++ b/drivers/power/qcom_smbb.c
@@ -34,6 +34,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #define SMBB_CHG_VMAX  0x040
 #define SMBB_CHG_VSAFE 0x041
@@ -71,6 +74,8 @@
 #define BTC_CTRL_HOT_EXT_N BIT(0)
 
 #define SMBB_USB_IMAX  0x344
+#define SMBB_USB_OTG_CTL   0x348
+#define OTG_CTL_EN BIT(0)
 #define SMBB_USB_ENUM_TIMER_STOP 0x34e
 #define ENUM_TIMER_STOPBIT(0)
 #define SMBB_USB_SEC_ACCESS0x3d0
@@ -123,6 +128,9 @@ struct smbb_charger {
struct power_supply *dc_psy;
struct power_supply *bat_psy;
struct regmap *regmap;
+
+   struct regulator_desc otg_rdesc;
+   struct regulator_dev *otg_reg;
 };
 
 static int smbb_vbat_weak_fn(unsigned int index)
@@ -778,12 +786,56 @@ static const struct power_supply_desc dc_psy_desc = {
.property_is_writeable = smbb_charger_writable_property,
 };
 
+static int smbb_chg_otg_enable(struct regulator_dev *rdev)
+{
+   struct smbb_charger *chg = rdev_get_drvdata(rdev);
+   int rc;
+
+   rc = regmap_update_bits(chg->regmap, chg->addr + SMBB_USB_OTG_CTL,
+   OTG_CTL_EN, OTG_CTL_EN);
+   if (rc)
+   dev_err(chg->dev, "failed to update OTG_CTL\n");
+   return rc;
+}
+
+static int smbb_chg_otg_disable(struct regulator_dev *rdev)
+{
+   struct smbb_charger *chg = rdev_get_drvdata(rdev);
+   int rc;
+
+   rc = regmap_update_bits(chg->regmap, chg->addr + SMBB_USB_OTG_CTL,
+   OTG_CTL_EN, 0);
+   if (rc)
+   dev_err(chg->dev, "failed to update OTG_CTL\n");
+   return rc;
+}
+
+static int smbb_chg_otg_is_enabled(struct regulator_dev *rdev)
+{
+   struct smbb_charger *chg = rdev_get_drvdata(rdev);
+   unsigned int value = 0;
+   int rc;
+
+   rc = regmap_read(chg->regmap, chg->addr + SMBB_USB_OTG_CTL, );
+   if (rc)
+   dev_err(chg->dev, "failed to read OTG_CTL\n");
+
+   return !!(value & OTG_CTL_EN);
+}
+
+static struct regulator_ops smbb_chg_otg_ops = {
+   .enable = smbb_chg_otg_enable,
+   .disable = smbb_chg_otg_disable,
+   .is_enabled = smbb_chg_otg_is_enabled,
+};
+
 static int smbb_charger_probe(struct platform_device *pdev)
 {
struct power_supply_config bat_cfg = {};
struct power_supply_config usb_cfg = {};
struct power_supply_config dc_cfg = {};
struct smbb_charger *chg;
+   struct regulator_config config = { };
int rc, i;
 
chg = devm_kzalloc(>dev, sizeof(*chg), GFP_KERNEL);
@@ -884,6 +936,28 @@ static int smbb_charger_probe(struct platform_device *pdev)
}
}
 
+   /*
+* otg regulator is used to control VBUS voltage direction
+* when USB switches between host and gadget mode
+*/
+   chg->otg_rdesc.id = -1;
+   chg->otg_rdesc.name = "otg";
+   chg->otg_rdesc.ops = _chg_otg_ops;
+   chg->otg_rdesc.owner = THIS_MODULE;
+   chg->otg_rdesc.type = REGULATOR_VOLTAGE;
+   chg->otg_rdesc.supply_name = "usb-otg-in";
+   chg->otg_rdesc.fixed_uV = 500;
+   chg->otg_rdesc.n_voltages = 1;
+   chg->otg_rdesc.of_match = "otg";
+
+   config.dev = >dev;
+   config.driver_data = chg;
+
+   chg->otg_reg = devm_regulator_register(>dev, >otg_rdesc,
+  );
+   if (IS_ERR(chg->otg_reg))
+   return PTR_ERR(chg->otg_reg);
+
chg->jeita_ext_temp = of_property_read_bool(pdev->dev.of_node,
"qcom,jeita-extended-temp-range");
 
-- 
2.4.2

--
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] ARM: defconfig: qcom: Enable SSBI drivers

2015-12-08 Thread Andy Gross 
On Tue, Dec 08, 2015 at 04:54:29PM -0600, Andy Gross wrote:
> On Mon, Nov 30, 2015 at 05:08:57PM -0800, Stephen Boyd wrote:
> > Enable some ssbi drivers present on msm8660, msm8960 and apq8064
> > devices so that we fully exercise the devices present in the dts
> > files.
> > 
> > Signed-off-by: Stephen Boyd 
> 
> Acked-by: Andy Gross 

Arnd, Olof, Kevin,

Can you guys pick this up.  This patch is based off the earlier qcom_defconfig
that was merged through the arm-soc directly.

Thanks.

--
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] ARM: defconfig: qcom: Enable SSBI drivers

2015-12-08 Thread Andy Gross 
On Mon, Nov 30, 2015 at 05:08:57PM -0800, Stephen Boyd wrote:
> Enable some ssbi drivers present on msm8660, msm8960 and apq8064
> devices so that we fully exercise the devices present in the dts
> files.
> 
> Signed-off-by: Stephen Boyd 

Acked-by: Andy Gross 

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

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

2015-12-08 Thread Pratyush Anand 
On Tue, Dec 8, 2015 at 2:31 PM, Stanimir Varbanov
 wrote:
>
> 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();
> >  }
> >


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.

~Pratyush
--
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 1/3] dt-binding: power: Add otg regulator binding

2015-12-08 Thread Rob Herring 
On Tue, Dec 08, 2015 at 04:40:16PM -0800, Tim Bird wrote:
> Add a binding for the regulator which controls the OTG chargepath switch.
> The OTG switch gets its power from pm8941_5vs1, and that should be
> expressed as a usb-otg-in-supply property in the DT node for the
> charger driver.  The regulator name is "otg".
> 
> Signed-off-by: Tim Bird 
> ---
> Changes since v1
>  - switch supply name to have dashes instead of underscores
>  - remove superfluous DT explanations in the otg node description
> ---
>  .../devicetree/bindings/power_supply/qcom_smbb.txt| 19 
> +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt 
> b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
> index 65b88fa..28b6da7 100644
> --- a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
> +++ b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
> @@ -105,6 +105,22 @@ PROPERTIES
> regulation must be done externally to fully comply with
> the JEITA safety guidelines if this flag is set.
>  
> +- usb-otg-in-supply:
> +  Usage: optional
> +  Value type: 
> +  Description: Reference to the regulator supplying power to the USB_OTG_IN
> +   pin.
> +
> +child nodes:
> +- otg:
> +  Usage: optional
> +  Description: This node defines a regulator used to control the direction
> +   of VBUS voltage - specifically: whether to supply voltage
> +   to VBUS for host mode operation of the OTG port, or allow
> +   input voltage from external VBUS for charging.  In the
> +   hardware, the supply for this regulator comes from
> +   usb-otg-in-supply.

Doesn't this regulator need to have a name defined?

Disabling this regulator (along with other setup) will enable charging?

Rob
--
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: [RFC][PATCH] misc: Introduce reboot_reason driver

2015-12-08 Thread Bjorn Andersson 
On Tue 08 Dec 13:29 PST 2015, John Stultz wrote:

> This patch adds a basic driver to allow for commands like
> "reboot bootloader" and "reboot recovery" to communicate this
> reboot-reason to the bootloader.
> 
> This is commonly done on Android devices, in order to reboot
> the device into fastboot or recovery mode. It also supports
> custom OEM specific commands, via "reboot oem-".
> 
> This driver pulls the phys memory address from DT as well as
> the magic reason values that are written to the address for
> each mode.
> 
> For an example, this patch also adds the DT support for
> the nexus7 device via its dts (which is not yet upstream).
> 
> Thoughts and feedback would be appreciated!
> 

Good to see some work on this, I want it too :)

I do however think this is Qualcomm specific in its implementation, so
adding Andy and linux-arm-msm.

[..]
> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts 
> b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> index 5183d18..ee5dcb7 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> @@ -282,6 +282,15 @@
>   };
>   };
>  
> + reboot_reason: reboot_reason@2a03f65c {
> + compatible  = "reboot_reason";
> + reg = <0x2A03F65C 0x4>;
> + reason,none = <0x77665501>;
> + reason,bootloader   = <0x77665500>;
> + reason,recovery = <0x77665502>;
> + reason,oem  = <0x6f656d00>;
> + };
> +

This address refers to IMEM, which is shared with a number of other
uses. So I think we should have a simple-mfd (and syscon) with this
within.


I like the fact that you don't hard code the magics in the
implementation, as I've seen additions from multiple places - so perhaps
it should be made even more flexible.

OMAP seems to use strings here instead of magics, but the delivery
mechanism looks to be the same. But I think of this as Qualcomm
specific.

>   gpio-keys {
>   compatible = "gpio-keys";
>   power {
[..]
> diff --git a/drivers/misc/reboot_reason.c b/drivers/misc/reboot_reason.c
[..]
> +
> +static int reboot_reason(struct notifier_block *nb, unsigned long action,
> + void *data)
> +{
> + char *cmd = (char *)data;
> + long reason = reasons[NONE];
> +
> + if (!reboot_reason_addr)
> + return NOTIFY_DONE;
> +
> + if (cmd != NULL) {
> + if (!strncmp(cmd, "bootloader", 10))
> + reason = reasons[BOOTLOADER];
> + else if (!strncmp(cmd, "recovery", 8))
> + reason = reasons[RECOVERY];
> + else if (!strncmp(cmd, "oem-", 4)) {
> + unsigned long code;
> +
> + if (!kstrtoul(cmd+4, 0, ))
> + reason = reasons[OEM] | (code & 0xff);
> + }
> + }

In the case where we didn't find a match you should write the "normal"
reason here, otherwise I think you will end up in recovery when recovery
issues a reboot (in Android that is).

> +
> + if (reason != -1)
> + writel(reason, reboot_reason_addr);
> + return NOTIFY_DONE;
> +}
> +
> +static int reboot_reason_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + u32 val;
> + int i;
> +
> + /* initialize the reasons */
> + for (i = 0; i < MAX_REASONS; i++)
> + reasons[i] = -1;
> +
> + /* Try to grab the reason io address */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + reboot_reason_addr = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(reboot_reason_addr))
> + return PTR_ERR(reboot_reason_addr);
> +

Please acquire this memory from a syscon (preferably the the parent
simple-mfd).

> + /* initialize specified reasons from DT */
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,none", ))
> + reasons[NONE] = val;
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,bootloader", ))
> + reasons[BOOTLOADER] = val;
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,recovery", ))
> + reasons[RECOVERY] = val;
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,oem", ))
> + reasons[OEM] = val;

I would like for this to be less hard coded.

> +
> + /* Install the notifier */
> + restart_nb.notifier_call = reboot_reason;
> + restart_nb.priority = 256;
> + if (register_restart_handler(_nb)) {
> + dev_err(>dev,
> + "failed to setup restart handler.\n");
> + }
> + return 0;
> +}
> +

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to