[PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Andy Shevchenko]

The Intel BayTrail based machines have different configuration of the Low Power
Sub System (LPSS) IP. The LPSS contains few host controllers, such as I2C, SPI,
I2C and common DMA IP to serve DMA transfers. Unfortunately the DMA IP has no
power control accessible for software / OS. It goes automatically down whenever
last device goes to sleep and turned on when one of them is turned on. When
user tries to access the powered off DMA device the system hangs.

This patch series addressing the issue. Rafael suggested to create a 'proxy'
device which makes DMA to be powered on on the certain points of time.

Vinod, we would like to push this via Rafael's tree, so, please Ack or NAck the
patch 4/4.

Scott, do you have a chance to test this patch series against last linux-pm
tree on HP laptops? I would appreciate your Tested-by tag.

Andy Shevchenko (4):
  ACPI / LPSS: add all LPSS devices to the specific power domain
  ACPI / LPSS: allow to use specific PM domain during ->probe()
  ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA
  dmaengine: dw: enable runtime PM

 drivers/acpi/acpi_lpss.c | 94 +++++++++++++++++++++++++++++++++---------------
 drivers/dma/dw/core.c    | 11 ++++++
 2 files changed, 76 insertions(+), 29 deletions(-)

-- 
2.1.1

[PATCH v1 1/4] ACPI / LPSS: add all LPSS devices to the specific power domain

[Andy Shevchenko]

Currently the LPSS devices are located in the different power domains depends
on LPSS_SAVE_CTX flag. We would like to use the specific power domain for all
LPSS devices.

The LPSS DMA controller has no knobs to control its power state. The specific
power domain implementation will handle this case. The patch does a preparation
for that.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/acpi/acpi_lpss.c | 53 ++++++++++++++++++++++++++++++++----------------
 1 file changed, 35 insertions(+), 18 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 93d1606..f6b71af 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -499,14 +499,15 @@ static void acpi_lpss_set_ltr(struct device *dev, s32 val)
 /**
  * acpi_lpss_save_ctx() - Save the private registers of LPSS device
  * @dev: LPSS device
+ * @pdata: pointer to the private data of the LPSS device
  *
  * Most LPSS devices have private registers which may loose their context when
  * the device is powered down. acpi_lpss_save_ctx() saves those registers into
  * prv_reg_ctx array.
  */
-static void acpi_lpss_save_ctx(struct device *dev)
+static void acpi_lpss_save_ctx(struct device *dev,
+			       struct lpss_private_data *pdata)
 {
-	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
 	unsigned int i;
 
 	for (i = 0; i < LPSS_PRV_REG_COUNT; i++) {
@@ -521,12 +522,13 @@ static void acpi_lpss_save_ctx(struct device *dev)
 /**
  * acpi_lpss_restore_ctx() - Restore the private registers of LPSS device
  * @dev: LPSS device
+ * @pdata: pointer to the private data of the LPSS device
  *
  * Restores the registers that were previously stored with acpi_lpss_save_ctx().
  */
-static void acpi_lpss_restore_ctx(struct device *dev)
+static void acpi_lpss_restore_ctx(struct device *dev,
+				  struct lpss_private_data *pdata)
 {
-	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
 	unsigned int i;
 
 	/*
@@ -549,23 +551,31 @@ static void acpi_lpss_restore_ctx(struct device *dev)
 #ifdef CONFIG_PM_SLEEP
 static int acpi_lpss_suspend_late(struct device *dev)
 {
-	int ret = pm_generic_suspend_late(dev);
+	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
+	int ret;
 
+	ret = pm_generic_suspend_late(dev);
 	if (ret)
 		return ret;
 
-	acpi_lpss_save_ctx(dev);
+	if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
+		acpi_lpss_save_ctx(dev, pdata);
+
 	return acpi_dev_suspend_late(dev);
 }
 
 static int acpi_lpss_resume_early(struct device *dev)
 {
-	int ret = acpi_dev_resume_early(dev);
+	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
+	int ret;
 
+	ret = acpi_dev_resume_early(dev);
 	if (ret)
 		return ret;
 
-	acpi_lpss_restore_ctx(dev);
+	if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
+		acpi_lpss_restore_ctx(dev, pdata);
+
 	return pm_generic_resume_early(dev);
 }
 #endif /* CONFIG_PM_SLEEP */
@@ -573,23 +583,31 @@ static int acpi_lpss_resume_early(struct device *dev)
 #ifdef CONFIG_PM_RUNTIME
 static int acpi_lpss_runtime_suspend(struct device *dev)
 {
-	int ret = pm_generic_runtime_suspend(dev);
+	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
+	int ret;
 
+	ret = pm_generic_runtime_suspend(dev);
 	if (ret)
 		return ret;
 
-	acpi_lpss_save_ctx(dev);
+	if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
+		acpi_lpss_save_ctx(dev, pdata);
+
 	return acpi_dev_runtime_suspend(dev);
 }
 
 static int acpi_lpss_runtime_resume(struct device *dev)
 {
-	int ret = acpi_dev_runtime_resume(dev);
+	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
+	int ret;
 
+	ret = acpi_dev_runtime_resume(dev);
 	if (ret)
 		return ret;
 
-	acpi_lpss_restore_ctx(dev);
+	if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
+		acpi_lpss_restore_ctx(dev, pdata);
+
 	return pm_generic_runtime_resume(dev);
 }
 #endif /* CONFIG_PM_RUNTIME */
@@ -631,22 +649,21 @@ static int acpi_lpss_platform_notify(struct notifier_block *nb,
 		return 0;
 
 	pdata = acpi_driver_data(adev);
-	if (!pdata || !pdata->mmio_base)
+	if (!pdata)
 		return 0;
 
-	if (pdata->mmio_size < pdata->dev_desc->prv_offset + LPSS_LTR_SIZE) {
+	if (pdata->mmio_base &&
+	    pdata->mmio_size < pdata->dev_desc->prv_offset + LPSS_LTR_SIZE) {
 		dev_err(&pdev->dev, "MMIO size insufficient to access LTR\n");
 		return 0;
 	}
 
 	switch (action) {
 	case BUS_NOTIFY_BOUND_DRIVER:
-		if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
-			pdev->dev.pm_domain = &acpi_lpss_pm_domain;
+		pdev->dev.pm_domain = &acpi_lpss_pm_domain;
 		break;
 	case BUS_NOTIFY_UNBOUND_DRIVER:
-		if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
-			pdev->dev.pm_domain = NULL;
+		pdev->dev.pm_domain = NULL;
 		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdata->dev_desc->flags & LPSS_LTR)
-- 
2.1.1

[PATCH v1 2/4] ACPI / LPSS: allow to use specific PM domain during ->probe()

[Andy Shevchenko]

The LPSS DMA controller would like to use the specific PM domain callbacks
during early stage, namely in ->probe(). This patch moves the specific PM
domain assignment early to be accessible during a whole life time of the device
in the system.

Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/acpi/acpi_lpss.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index f6b71af..4804ae3 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -659,19 +659,17 @@ static int acpi_lpss_platform_notify(struct notifier_block *nb,
 	}
 
 	switch (action) {
-	case BUS_NOTIFY_BOUND_DRIVER:
-		pdev->dev.pm_domain = &acpi_lpss_pm_domain;
-		break;
-	case BUS_NOTIFY_UNBOUND_DRIVER:
-		pdev->dev.pm_domain = NULL;
-		break;
 	case BUS_NOTIFY_ADD_DEVICE:
+		pdev->dev.pm_domain = &acpi_lpss_pm_domain;
 		if (pdata->dev_desc->flags & LPSS_LTR)
 			return sysfs_create_group(&pdev->dev.kobj,
 						  &lpss_attr_group);
+		break;
 	case BUS_NOTIFY_DEL_DEVICE:
 		if (pdata->dev_desc->flags & LPSS_LTR)
 			sysfs_remove_group(&pdev->dev.kobj, &lpss_attr_group);
+		pdev->dev.pm_domain = NULL;
+		break;
 	default:
 		break;
 	}
-- 
2.1.1

[PATCH v1 3/4] ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA

[Andy Shevchenko]

The LPSS DMA controller does not have _PS0 and _PS3 methods. Moreover it can be
powered off automatically whenever the last LPSS device goes down. In case of
no power any access to the DMA controller will hang the system. The behaviour
is reproduced on some HP laptops based on Intel Bay Trail [1] as well as on
Asus T100 transformer.

This patch introduces a so called 'proxy' device that has the knobs to handle a
power of the LPSS island. When the system needs to program the DMA controller
it calls to the ACPI LPSS power domain callbacks that wake or suspend the
'proxy' device.

[1] http://www.spinics.net/lists/dmaengine/msg01514.html

Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/acpi/acpi_lpss.c | 35 ++++++++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 4804ae3..d1dd0ad 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -1,7 +1,7 @@
 /*
  * ACPI support for Intel Lynxpoint LPSS.
  *
- * Copyright (C) 2013, Intel Corporation
+ * Copyright (C) 2013, 2014, Intel Corporation
  * Authors: Mika Westerberg <mika.westerberg@linux.intel.com>
  *          Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  *
@@ -60,6 +60,8 @@ ACPI_MODULE_NAME("acpi_lpss");
 #define LPSS_CLK_DIVIDER		BIT(2)
 #define LPSS_LTR			BIT(3)
 #define LPSS_SAVE_CTX			BIT(4)
+#define LPSS_DEV_PROXY			BIT(5)
+#define LPSS_PROXY_REQ			BIT(6)
 
 struct lpss_private_data;
 
@@ -70,8 +72,10 @@ struct lpss_device_desc {
 	void (*setup)(struct lpss_private_data *pdata);
 };
 
+static struct device *proxy_device;
+
 static struct lpss_device_desc lpss_dma_desc = {
-	.flags = LPSS_CLK,
+	.flags = LPSS_CLK | LPSS_PROXY_REQ,
 };
 
 struct lpss_private_data {
@@ -146,22 +150,24 @@ static struct lpss_device_desc byt_pwm_dev_desc = {
 };
 
 static struct lpss_device_desc byt_uart_dev_desc = {
-	.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX,
+	.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX |
+		 LPSS_DEV_PROXY,
 	.prv_offset = 0x800,
 	.setup = lpss_uart_setup,
 };
 
 static struct lpss_device_desc byt_spi_dev_desc = {
-	.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX,
+	.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX |
+		 LPSS_DEV_PROXY,
 	.prv_offset = 0x400,
 };
 
 static struct lpss_device_desc byt_sdio_dev_desc = {
-	.flags = LPSS_CLK,
+	.flags = LPSS_CLK | LPSS_DEV_PROXY,
 };
 
 static struct lpss_device_desc byt_i2c_dev_desc = {
-	.flags = LPSS_CLK | LPSS_SAVE_CTX,
+	.flags = LPSS_CLK | LPSS_SAVE_CTX | LPSS_DEV_PROXY,
 	.prv_offset = 0x800,
 	.setup = byt_i2c_setup,
 };
@@ -368,6 +374,8 @@ static int acpi_lpss_create_device(struct acpi_device *adev,
 	adev->driver_data = pdata;
 	pdev = acpi_create_platform_device(adev);
 	if (!IS_ERR_OR_NULL(pdev)) {
+		if (!proxy_device && dev_desc->flags & LPSS_DEV_PROXY)
+			proxy_device = &pdev->dev;
 		return 1;
 	}
 
@@ -593,7 +601,14 @@ static int acpi_lpss_runtime_suspend(struct device *dev)
 	if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
 		acpi_lpss_save_ctx(dev, pdata);
 
-	return acpi_dev_runtime_suspend(dev);
+	ret = acpi_dev_runtime_suspend(dev);
+	if (ret)
+		return ret;
+
+	if (pdata->dev_desc->flags & LPSS_PROXY_REQ && proxy_device)
+		return pm_runtime_put_sync_suspend(proxy_device);
+
+	return 0;
 }
 
 static int acpi_lpss_runtime_resume(struct device *dev)
@@ -601,6 +616,12 @@ static int acpi_lpss_runtime_resume(struct device *dev)
 	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
 	int ret;
 
+	if (pdata->dev_desc->flags & LPSS_PROXY_REQ && proxy_device) {
+		ret = pm_runtime_get_sync(proxy_device);
+		if (ret)
+			return ret;
+	}
+
 	ret = acpi_dev_runtime_resume(dev);
 	if (ret)
 		return ret;
-- 
2.1.1

[PATCH v1 4/4] dmaengine: dw: enable runtime PM

[Andy Shevchenko]

On runtime PM aware platforms the DMA have to manage its own power state. This
patch enables runtime PM support and applies necessary calls wherever it's
needed.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/dma/dw/core.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 2447221..3804785 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -22,6 +22,7 @@
 #include <linux/mm.h>
 #include <linux/module.h>
 #include <linux/slab.h>
+#include <linux/pm_runtime.h>
 
 #include "../dmaengine.h"
 #include "internal.h"
@@ -1504,6 +1505,9 @@ int dw_dma_probe(struct dw_dma_chip *chip, struct dw_dma_platform_data *pdata)
 	dw->regs = chip->regs;
 	chip->dw = dw;
 
+	pm_runtime_enable(chip->dev);
+	pm_runtime_get_sync(chip->dev);
+
 	dw_params = dma_read_byaddr(chip->regs, DW_PARAMS);
 	autocfg = dw_params >> DW_PARAMS_EN & 0x1;
 
@@ -1667,11 +1671,14 @@ int dw_dma_probe(struct dw_dma_chip *chip, struct dw_dma_platform_data *pdata)
 	dev_info(chip->dev, "DesignWare DMA Controller, %d channels\n",
 		 nr_channels);
 
+	pm_runtime_put_sync_suspend(chip->dev);
+
 	return 0;
 
 err_dma_register:
 	free_irq(chip->irq, dw);
 err_pdata:
+	pm_runtime_put_sync_suspend(chip->dev);
 	return err;
 }
 EXPORT_SYMBOL_GPL(dw_dma_probe);
@@ -1681,6 +1688,8 @@ int dw_dma_remove(struct dw_dma_chip *chip)
 	struct dw_dma		*dw = chip->dw;
 	struct dw_dma_chan	*dwc, *_dwc;
 
+	pm_runtime_get_sync(chip->dev);
+
 	dw_dma_off(dw);
 	dma_async_device_unregister(&dw->dma);
 
@@ -1693,6 +1702,8 @@ int dw_dma_remove(struct dw_dma_chip *chip)
 		channel_clear_bit(dw, CH_EN, dwc->mask);
 	}
 
+	pm_runtime_put_sync_suspend(chip->dev);
+	pm_runtime_disable(chip->dev);
 	return 0;
 }
 EXPORT_SYMBOL_GPL(dw_dma_remove);
-- 
2.1.1

Re: [PATCH v1 4/4] dmaengine: dw: enable runtime PM

[Vinod Koul]

On Wed, Nov 05, 2014 at 06:34:48PM +0200, Andy Shevchenko wrote:
> On runtime PM aware platforms the DMA have to manage its own power state. This
> patch enables runtime PM support and applies necessary calls wherever it's
> needed.
Acked-by: Vinod Koul <vinod.koul@intel.com>

-- 
~Vinod

Re: [PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Scott Ashcroft]

On Wed, 2014-11-05 at 18:34 +0200, Andy Shevchenko wrote:
> Scott, do you have a chance to test this patch series against last linux-pm
> tree on HP laptops? I would appreciate your Tested-by tag.

OK. I'm building the linux-pm tree now to prove it still fails.
I'll then apply the patches and re-test.

Cheers,
Scott

Re: [PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Scott Ashcroft]

> Scott, do you have a chance to test this patch series against last linux-pm
> tree on HP laptops? I would appreciate your Tested-by tag.

This allows the laptop to power down but it appears to not dismount the file systems cleanly.
Running 'init 0' looks like it is doing a shutdown but the last thing it logs is something to do with ntp rather than the normal flushing disks etc.

I'll try and get some logs. Are there any debug options I should turn on?

Cheers,
Scott

Re: [PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Rafael J. Wysocki]

On Wednesday, November 05, 2014 06:34:44 PM Andy Shevchenko wrote:
> The Intel BayTrail based machines have different configuration of the Low Power
> Sub System (LPSS) IP. The LPSS contains few host controllers, such as I2C, SPI,
> I2C and common DMA IP to serve DMA transfers. Unfortunately the DMA IP has no
> power control accessible for software / OS. It goes automatically down whenever
> last device goes to sleep and turned on when one of them is turned on. When
> user tries to access the powered off DMA device the system hangs.
> 
> This patch series addressing the issue. Rafael suggested to create a 'proxy'
> device which makes DMA to be powered on on the certain points of time.
> 
> Vinod, we would like to push this via Rafael's tree, so, please Ack or NAck the
> patch 4/4.
> 
> Scott, do you have a chance to test this patch series against last linux-pm
> tree on HP laptops? I would appreciate your Tested-by tag.
> 
> Andy Shevchenko (4):
>   ACPI / LPSS: add all LPSS devices to the specific power domain
>   ACPI / LPSS: allow to use specific PM domain during ->probe()
>   ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA
>   dmaengine: dw: enable runtime PM

I'm essentially fine with this series, but I'm not sure what the status of
the Scott's testing is.  Can you please tell me and Scott what in particular
you wanted him to test?

Rafael

Re: [PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Scott Ashcroft]

> I'm essentially fine with this series, but I'm not sure what the status of
> the Scott's testing is.  Can you please tell me and Scott what in particular
> you wanted him to test?


Initial testing has not gone well.
The laptop does power down but it appears not to dismount the file systems cleanly.
Running 'init 0' looks like it is doing a shutdown but the last thing it logs 
is something to do with ntp rather than the normal flushing disks etc.
It looks like things are powered down too soon.

I'll try and get some logs, tonight
Are there any debug options I should turn on?

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

Re: [PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Andy Shevchenko]

On Fri, 2014-11-07 at 08:46 +0000, Scott Ashcroft wrote:
> 
> > I'm essentially fine with this series, but I'm not sure what the status of
> > the Scott's testing is.  Can you please tell me and Scott what in particular
> > you wanted him to test?
> 
> 
> Initial testing has not gone well.
> The laptop does power down but it appears not to dismount the file systems cleanly.
> Running 'init 0' looks like it is doing a shutdown but the last thing it logs 
> is something to do with ntp rather than the normal flushing disks etc.
> It looks like things are powered down too soon.

I hope this is not related to mine patch series.
If you have time you may try to use last v3.18-rcX and apply patches on
top of that and re-test.

> 
> I'll try and get some logs, tonight
> Are there any debug options I should turn on?

Hm… Now I have nothing come to my mind. Maybe Rafael could suggest
something.


-- 
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy

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

Re: [PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Andy Shevchenko]

On Fri, 2014-11-07 at 01:37 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 05, 2014 06:34:44 PM Andy Shevchenko wrote:
> > The Intel BayTrail based machines have different configuration of the Low Power
> > Sub System (LPSS) IP. The LPSS contains few host controllers, such as I2C, SPI,
> > I2C and common DMA IP to serve DMA transfers. Unfortunately the DMA IP has no
> > power control accessible for software / OS. It goes automatically down whenever
> > last device goes to sleep and turned on when one of them is turned on. When
> > user tries to access the powered off DMA device the system hangs.
> > 
> > This patch series addressing the issue. Rafael suggested to create a 'proxy'
> > device which makes DMA to be powered on on the certain points of time.
> > 
> > Vinod, we would like to push this via Rafael's tree, so, please Ack or NAck the
> > patch 4/4.
> > 
> > Scott, do you have a chance to test this patch series against last linux-pm
> > tree on HP laptops? I would appreciate your Tested-by tag.
> > 
> > Andy Shevchenko (4):
> >   ACPI / LPSS: add all LPSS devices to the specific power domain
> >   ACPI / LPSS: allow to use specific PM domain during ->probe()
> >   ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA
> >   dmaengine: dw: enable runtime PM
> 
> I'm essentially fine with this series, but I'm not sure what the status of
> the Scott's testing is.  Can you please tell me and Scott what in particular
> you wanted him to test?

He complained that HP laptop didn't reboot nicely and hangs the system
until he blacklisted dw_dmac driver.

-- 
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy

Re: [PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Rafael J. Wysocki]

On 11/7/2014 2:46 PM, Andy Shevchenko wrote:
> On Fri, 2014-11-07 at 01:37 +0100, Rafael J. Wysocki wrote:
>> On Wednesday, November 05, 2014 06:34:44 PM Andy Shevchenko wrote:
>>> The Intel BayTrail based machines have different configuration of the Low Power
>>> Sub System (LPSS) IP. The LPSS contains few host controllers, such as I2C, SPI,
>>> I2C and common DMA IP to serve DMA transfers. Unfortunately the DMA IP has no
>>> power control accessible for software / OS. It goes automatically down whenever
>>> last device goes to sleep and turned on when one of them is turned on. When
>>> user tries to access the powered off DMA device the system hangs.
>>>
>>> This patch series addressing the issue. Rafael suggested to create a 'proxy'
>>> device which makes DMA to be powered on on the certain points of time.
>>>
>>> Vinod, we would like to push this via Rafael's tree, so, please Ack or NAck the
>>> patch 4/4.
>>>
>>> Scott, do you have a chance to test this patch series against last linux-pm
>>> tree on HP laptops? I would appreciate your Tested-by tag.
>>>
>>> Andy Shevchenko (4):
>>>    ACPI / LPSS: add all LPSS devices to the specific power domain
>>>    ACPI / LPSS: allow to use specific PM domain during ->probe()
>>>    ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA
>>>    dmaengine: dw: enable runtime PM
>> I'm essentially fine with this series, but I'm not sure what the status of
>> the Scott's testing is.  Can you please tell me and Scott what in particular
>> you wanted him to test?
> He complained that HP laptop didn't reboot nicely and hangs the system
> until he blacklisted dw_dmac driver.
>

The patch series fixes runtime PM, though, so how is that related to 
reboot exactly?

Rafael

Re: [PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Scott Ashcroft]

On Fri, 2014-11-07 at 17:30 +0100, Rafael J. Wysocki wrote:
> The patch series fixes runtime PM, though, so how is that related to 
> reboot exactly?

I can't reproduce the issue. I'll keep trying to see if I can figure out
what happened.

Cheers,
Scott 

Re: [PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Andy Shevchenko]

On Fri, 2014-11-07 at 17:30 +0100, Rafael J. Wysocki wrote:
> On 11/7/2014 2:46 PM, Andy Shevchenko wrote:
> > On Fri, 2014-11-07 at 01:37 +0100, Rafael J. Wysocki wrote:
> >> On Wednesday, November 05, 2014 06:34:44 PM Andy Shevchenko wrote:
> >>> The Intel BayTrail based machines have different configuration of the Low Power
> >>> Sub System (LPSS) IP. The LPSS contains few host controllers, such as I2C, SPI,
> >>> I2C and common DMA IP to serve DMA transfers. Unfortunately the DMA IP has no
> >>> power control accessible for software / OS. It goes automatically down whenever
> >>> last device goes to sleep and turned on when one of them is turned on. When
> >>> user tries to access the powered off DMA device the system hangs.
> >>>
> >>> This patch series addressing the issue. Rafael suggested to create a 'proxy'
> >>> device which makes DMA to be powered on on the certain points of time.
> >>>
> >>> Vinod, we would like to push this via Rafael's tree, so, please Ack or NAck the
> >>> patch 4/4.
> >>>
> >>> Scott, do you have a chance to test this patch series against last linux-pm
> >>> tree on HP laptops? I would appreciate your Tested-by tag.
> >>>
> >>> Andy Shevchenko (4):
> >>>    ACPI / LPSS: add all LPSS devices to the specific power domain
> >>>    ACPI / LPSS: allow to use specific PM domain during ->probe()
> >>>    ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA
> >>>    dmaengine: dw: enable runtime PM
> >> I'm essentially fine with this series, but I'm not sure what the status of
> >> the Scott's testing is.  Can you please tell me and Scott what in particular
> >> you wanted him to test?
> > He complained that HP laptop didn't reboot nicely and hangs the system
> > until he blacklisted dw_dmac driver.
> >
> 
> The patch series fixes runtime PM, though, so how is that related to 
> reboot exactly?

When he rebooted machine the dw_dmac driver was trying to access the HW
when LPSS is off (this is my understanding of the issue), thus, it was
stuck as long as he had dw_dmac loaded.

> 
> Rafael
> 


-- 
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy

Re: [PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Scott Ashcroft]

On Wed, 2014-11-05 at 18:34 +0200, Andy Shevchenko wrote:
> Scott, do you have a chance to test this patch series against last linux-pm
> tree on HP laptops? I would appreciate your Tested-by tag.

Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com>

It has now survived 20 reboots with no problems.

Cheers,
Scott

Re: [PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Andy Shevchenko]

On Sat, 2014-11-08 at 10:51 +0000, Scott Ashcroft wrote:
> On Wed, 2014-11-05 at 18:34 +0200, Andy Shevchenko wrote:
> > Scott, do you have a chance to test this patch series against last linux-pm
> > tree on HP laptops? I would appreciate your Tested-by tag.
> 
> Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com>

Thank you!

> It has now survived 20 reboots with no problems.



-- 
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy

Re: [PATCH v1 0/4] ACPI / LPSS: fix system hangup on BYT

[Rafael J. Wysocki]

On Wednesday, November 05, 2014 06:34:44 PM Andy Shevchenko wrote:
> The Intel BayTrail based machines have different configuration of the Low Power
> Sub System (LPSS) IP. The LPSS contains few host controllers, such as I2C, SPI,
> I2C and common DMA IP to serve DMA transfers. Unfortunately the DMA IP has no
> power control accessible for software / OS. It goes automatically down whenever
> last device goes to sleep and turned on when one of them is turned on. When
> user tries to access the powered off DMA device the system hangs.
> 
> This patch series addressing the issue. Rafael suggested to create a 'proxy'
> device which makes DMA to be powered on on the certain points of time.
> 
> Vinod, we would like to push this via Rafael's tree, so, please Ack or NAck the
> patch 4/4.
> 
> Scott, do you have a chance to test this patch series against last linux-pm
> tree on HP laptops? I would appreciate your Tested-by tag.
> 
> Andy Shevchenko (4):
>   ACPI / LPSS: add all LPSS devices to the specific power domain
>   ACPI / LPSS: allow to use specific PM domain during ->probe()
>   ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA
>   dmaengine: dw: enable runtime PM
> 
>  drivers/acpi/acpi_lpss.c | 94 +++++++++++++++++++++++++++++++++---------------
>  drivers/dma/dw/core.c    | 11 ++++++
>  2 files changed, 76 insertions(+), 29 deletions(-)

I've queued up the series for 3.19, thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.