[PATCH v3 0/9] ACPI / LPSS: fix system hangup on BYT/BSW/CHT

[PATCH v3 0/9] ACPI / LPSS: fix system hangup on BYT/BSW/CHT

[Andy Shevchenko]

Here is a v3 of the next generation (previous one is [1]) of the long standing
power issue fix regarding to LPSS on Intel Baytrail and Braswell SoCs, in
particularly ASuS T100TA. There are few bugs already opened on kernel.org's and
RedHat's bugzilla sites.

The series depends on the patch submitted earlier [2].

The patch 1 brings a new notification to handle the case when ->probe() of the
driver fails. It allows to avoid a potential problems. I've noticed couple of
drivers that are using that in assumption that ->probe() never fails.

The patches 2 & 4 are needed to fix an I2C issue which Jarkko is currently
investigating.

It seems the best way to push it through linux-pm tree. Thus, it would be good
to get ACKs from the rest of maintainers.

Rafael, it would be nice to have an immutable branch or tag for this sice I
have more patches coming for dw_dmac driver which are based on top of this
series.

The patches have been tested on ASuS T100TA, Intel Cherrytrail, and Intel
Braswell SoCs.

[1] http://www.spinics.net/lists/linux-acpi/msg53963.html
[2] http://www.spinics.net/lists/kernel/msg2119229.html

Changelog v3:
- patch 2 is split to pure revert with Fixes tag for stable and new change in
  patch 3
- add patch 4 to resolve an issue when I2C can't be probed and SDHCI leaves
  devices in D0
- address comments from Rafael
- quirk functions moved under CONFIG_PM

Andy Shevchenko (9):
  device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification
  Revert "ACPI / LPSS: allow to use specific PM domain during ->probe()"
  ACPI / LPSS: allow to use specific PM domain during ->probe()
  ACPI / LPSS: power on when probe() and otherwise when remove()
  ACPI / LPSS: do delay for all LPSS devices when D3->D0
  ACPI / LPSS: override power state for LPSS DMA device
  dmaengine: dw: platform: power on device on shutdown
  dmaengine: dw: return immediately from IRQ when DMA isn't in use
  Revert "dmaengine: dw: platform: provide platform data for Intel"

 arch/x86/Kconfig                |   3 +-
 arch/x86/include/asm/iosf_mbi.h |   2 +
 drivers/acpi/acpi_lpss.c        | 213 +++++++++++++++++++++++++++++++++++++---
 drivers/base/dd.c               |  10 +-
 drivers/dma/dw/core.c           |   9 +-
 drivers/dma/dw/platform.c       |  29 +++---
 include/linux/device.h          |   1 +
 7 files changed, 231 insertions(+), 36 deletions(-)

-- 
2.6.2

[PATCH v3 1/9] device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

[Andy Shevchenko]

The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any cleanup in case of
a probe failure. In the result there might be problems, such as some resources
that had been allocated will continue to be allocated and therefore lead to a
resource leak.

Introduce a new notification to inform the subscriber that ->probe() failed. Do
the same in case of failed device_bind_driver() call.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/base/dd.c      | 10 ++++++++--
 include/linux/device.h |  1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 8d4eb4d..7399be7 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -299,6 +299,9 @@ int device_bind_driver(struct device *dev)
 	ret = driver_sysfs_add(dev);
 	if (!ret)
 		driver_bound(dev);
+	else if (dev->bus)
+		blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
+					     BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(device_bind_driver);
@@ -332,7 +335,7 @@ static int really_probe(struct device *dev, struct device_driver *drv)
 	/* If using pinctrl, bind pins now before probing */
 	ret = pinctrl_bind_pins(dev);
 	if (ret)
-		goto probe_failed;
+		goto pinctrl_bind_failed;
 
 	if (driver_sysfs_add(dev)) {
 		printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
@@ -376,6 +379,10 @@ static int really_probe(struct device *dev, struct device_driver *drv)
 	goto done;
 
 probe_failed:
+	if (dev->bus)
+		blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
+					     BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
+pinctrl_bind_failed:
 	devres_release_all(dev);
 	driver_sysfs_remove(dev);
 	dev->driver = NULL;
@@ -749,7 +756,6 @@ static void __device_release_driver(struct device *dev)
 			blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
 						     BUS_NOTIFY_UNBOUND_DRIVER,
 						     dev);
-
 	}
 }
 
diff --git a/include/linux/device.h b/include/linux/device.h
index b8f411b..f627ba2 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -191,6 +191,7 @@ extern int bus_unregister_notifier(struct bus_type *bus,
 						      unbound */
 #define BUS_NOTIFY_UNBOUND_DRIVER	0x00000007 /* driver is unbound
 						      from the device */
+#define BUS_NOTIFY_DRIVER_NOT_BOUND	0x00000008 /* driver fails to be bound */
 
 extern struct kset *bus_get_kset(struct bus_type *bus);
 extern struct klist *bus_get_device_klist(struct bus_type *bus);
-- 
2.6.2

Re: [PATCH v3 1/9] device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

[Greg Kroah-Hartman]

On Fri, Dec 04, 2015 at 11:49:17PM +0200, Andy Shevchenko wrote:
> The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any cleanup in case of
> a probe failure. In the result there might be problems, such as some resources
> that had been allocated will continue to be allocated and therefore lead to a
> resource leak.
> 
> Introduce a new notification to inform the subscriber that ->probe() failed. Do
> the same in case of failed device_bind_driver() call.

Ugh, I hate all these notifiers, but this one does make sense...

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH v3 1/9] device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

[Andy Shevchenko]

On Sat, Dec 5, 2015 at 6:14 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Fri, Dec 04, 2015 at 11:49:17PM +0200, Andy Shevchenko wrote:
>> The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any cleanup in case of
>> a probe failure. In the result there might be problems, such as some resources
>> that had been allocated will continue to be allocated and therefore lead to a
>> resource leak.
>>
>> Introduce a new notification to inform the subscriber that ->probe() failed. Do
>> the same in case of failed device_bind_driver() call.
>
> Ugh, I hate all these notifiers, but this one does make sense...

Yeah, I'm not a fan of them either.

> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

You meant Acked-by, didn't you?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 1/9] device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

[Greg Kroah-Hartman]

On Sat, Dec 05, 2015 at 06:24:05PM +0200, Andy Shevchenko wrote:
> On Sat, Dec 5, 2015 at 6:14 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Fri, Dec 04, 2015 at 11:49:17PM +0200, Andy Shevchenko wrote:
> >> The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any cleanup in case of
> >> a probe failure. In the result there might be problems, such as some resources
> >> that had been allocated will continue to be allocated and therefore lead to a
> >> resource leak.
> >>
> >> Introduce a new notification to inform the subscriber that ->probe() failed. Do
> >> the same in case of failed device_bind_driver() call.
> >
> > Ugh, I hate all these notifiers, but this one does make sense...
> 
> Yeah, I'm not a fan of them either.
> 
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> You meant Acked-by, didn't you?

Either works :)

Re: [PATCH v3 1/9] device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

[Rafael J. Wysocki]

On Saturday, December 05, 2015 08:36:22 AM Greg Kroah-Hartman wrote:
> On Sat, Dec 05, 2015 at 06:24:05PM +0200, Andy Shevchenko wrote:
> > On Sat, Dec 5, 2015 at 6:14 PM, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > On Fri, Dec 04, 2015 at 11:49:17PM +0200, Andy Shevchenko wrote:
> > >> The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any cleanup in case of
> > >> a probe failure. In the result there might be problems, such as some resources
> > >> that had been allocated will continue to be allocated and therefore lead to a
> > >> resource leak.
> > >>
> > >> Introduce a new notification to inform the subscriber that ->probe() failed. Do
> > >> the same in case of failed device_bind_driver() call.
> > >
> > > Ugh, I hate all these notifiers, but this one does make sense...
> > 
> > Yeah, I'm not a fan of them either.
> > 
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > You meant Acked-by, didn't you?
> 
> Either works :)

Thanks!

Andy, what about if I put patches [1-6/9] into my queue for v4.5 now and
the remaining ones will wait for Vinod to comment?

Thanks,
Rafael

Re: [PATCH v3 1/9] device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

[Andy Shevchenko]

On Mon, 2015-12-07 at 02:31 +0100, Rafael J. Wysocki wrote:
> On Saturday, December 05, 2015 08:36:22 AM Greg Kroah-Hartman wrote:
> > On Sat, Dec 05, 2015 at 06:24:05PM +0200, Andy Shevchenko wrote:
> > > On Sat, Dec 5, 2015 at 6:14 PM, Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > > On Fri, Dec 04, 2015 at 11:49:17PM +0200, Andy Shevchenko
> > > > wrote:
> > > > > The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any
> > > > > cleanup in case of
> > > > > a probe failure. In the result there might be problems, such
> > > > > as some resources
> > > > > that had been allocated will continue to be allocated and
> > > > > therefore lead to a
> > > > > resource leak.
> > > > > 
> > > > > Introduce a new notification to inform the subscriber that
> > > > > ->probe() failed. Do
> > > > > the same in case of failed device_bind_driver() call.
> > > > 
> > > > Ugh, I hate all these notifiers, but this one does make
> > > > sense...
> > > 
> > > Yeah, I'm not a fan of them either.
> > > 
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > 
> > > You meant Acked-by, didn't you?
> > 
> > Either works :)
> 
> Thanks!
> 
> Andy, what about if I put patches [1-6/9] into my queue for v4.5 now
> and
> the remaining ones will wait for Vinod to comment?

Yes, it's possible, but please don't forget the patch from http://www.s
pinics.net/lists/kernel/msg2119229.html. There also formally Acks from
Thomas and Ong, Boon Leong.

> 
> Thanks,
> Rafael
> 

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

Re: [PATCH v3 1/9] device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

[Rafael J. Wysocki]

On Monday, December 07, 2015 12:57:33 PM Andy Shevchenko wrote:
> On Mon, 2015-12-07 at 02:31 +0100, Rafael J. Wysocki wrote:
> > On Saturday, December 05, 2015 08:36:22 AM Greg Kroah-Hartman wrote:
> > > On Sat, Dec 05, 2015 at 06:24:05PM +0200, Andy Shevchenko wrote:
> > > > On Sat, Dec 5, 2015 at 6:14 PM, Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > > On Fri, Dec 04, 2015 at 11:49:17PM +0200, Andy Shevchenko
> > > > > wrote:
> > > > > > The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any
> > > > > > cleanup in case of
> > > > > > a probe failure. In the result there might be problems, such
> > > > > > as some resources
> > > > > > that had been allocated will continue to be allocated and
> > > > > > therefore lead to a
> > > > > > resource leak.
> > > > > > 
> > > > > > Introduce a new notification to inform the subscriber that
> > > > > > ->probe() failed. Do
> > > > > > the same in case of failed device_bind_driver() call.
> > > > > 
> > > > > Ugh, I hate all these notifiers, but this one does make
> > > > > sense...
> > > > 
> > > > Yeah, I'm not a fan of them either.
> > > > 
> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > 
> > > > You meant Acked-by, didn't you?
> > > 
> > > Either works :)
> > 
> > Thanks!
> > 
> > Andy, what about if I put patches [1-6/9] into my queue for v4.5 now
> > and
> > the remaining ones will wait for Vinod to comment?
> 
> Yes, it's possible, but please don't forget the patch from http://www.s
> pinics.net/lists/kernel/msg2119229.html. There also formally Acks from
> Thomas and Ong, Boon Leong.

Well, if Thomas prefers to take this one into tip, I guess the series should
go along with it or wait for when that one is merged.

Thanks,
Rafael

Re: [PATCH v3 1/9] device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

[Thomas Gleixner]

On Mon, 7 Dec 2015, Rafael J. Wysocki wrote:
> On Monday, December 07, 2015 12:57:33 PM Andy Shevchenko wrote:
> > > Andy, what about if I put patches [1-6/9] into my queue for v4.5 now
> > > and
> > > the remaining ones will wait for Vinod to comment?
> > 
> > Yes, it's possible, but please don't forget the patch from http://www.s
> > pinics.net/lists/kernel/msg2119229.html. There also formally Acks from
> > Thomas and Ong, Boon Leong.
> 
> Well, if Thomas prefers to take this one into tip, I guess the series should
> go along with it or wait for when that one is merged.

Works either way. I have no changes pending against that iosf_mbi stuff.

Thanks,

	tglx

Re: [PATCH v3 1/9] device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

[Rafael J. Wysocki]

On Tuesday, December 08, 2015 02:32:00 PM Thomas Gleixner wrote:
> On Mon, 7 Dec 2015, Rafael J. Wysocki wrote:
> > On Monday, December 07, 2015 12:57:33 PM Andy Shevchenko wrote:
> > > > Andy, what about if I put patches [1-6/9] into my queue for v4.5 now
> > > > and
> > > > the remaining ones will wait for Vinod to comment?
> > > 
> > > Yes, it's possible, but please don't forget the patch from http://www.s
> > > pinics.net/lists/kernel/msg2119229.html. There also formally Acks from
> > > Thomas and Ong, Boon Leong.
> > 
> > Well, if Thomas prefers to take this one into tip, I guess the series should
> > go along with it or wait for when that one is merged.
> 
> Works either way. I have no changes pending against that iosf_mbi stuff.

Cool.  I'll take that patch and the series then.

Thanks,
Rafael

Re: [PATCH v3 1/9] device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

[Andy Shevchenko]

On Tue, Dec 8, 2015 at 4:05 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, December 08, 2015 02:32:00 PM Thomas Gleixner wrote:
>> On Mon, 7 Dec 2015, Rafael J. Wysocki wrote:
>> > On Monday, December 07, 2015 12:57:33 PM Andy Shevchenko wrote:
>> > > > Andy, what about if I put patches [1-6/9] into my queue for v4.5 now
>> > > > and
>> > > > the remaining ones will wait for Vinod to comment?
>> > >
>> > > Yes, it's possible, but please don't forget the patch from http://www.s
>> > > pinics.net/lists/kernel/msg2119229.html. There also formally Acks from
>> > > Thomas and Ong, Boon Leong.
>> >
>> > Well, if Thomas prefers to take this one into tip, I guess the series should
>> > go along with it or wait for when that one is merged.
>>
>> Works either way. I have no changes pending against that iosf_mbi stuff.
>

Thanks, Thomas!

> Cool.  I'll take that patch and the series then.

Please, also put patch 5 before patch 4. It will go smoothly, or I can
send an updated version.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 1/9] device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

[Rafael J. Wysocki]

On Tuesday, December 08, 2015 03:50:06 PM Andy Shevchenko wrote:
> On Tue, Dec 8, 2015 at 4:05 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Tuesday, December 08, 2015 02:32:00 PM Thomas Gleixner wrote:
> >> On Mon, 7 Dec 2015, Rafael J. Wysocki wrote:
> >> > On Monday, December 07, 2015 12:57:33 PM Andy Shevchenko wrote:
> >> > > > Andy, what about if I put patches [1-6/9] into my queue for v4.5 now
> >> > > > and
> >> > > > the remaining ones will wait for Vinod to comment?
> >> > >
> >> > > Yes, it's possible, but please don't forget the patch from http://www.s
> >> > > pinics.net/lists/kernel/msg2119229.html. There also formally Acks from
> >> > > Thomas and Ong, Boon Leong.
> >> >
> >> > Well, if Thomas prefers to take this one into tip, I guess the series should
> >> > go along with it or wait for when that one is merged.
> >>
> >> Works either way. I have no changes pending against that iosf_mbi stuff.
> >
> 
> Thanks, Thomas!
> 
> > Cool.  I'll take that patch and the series then.
> 
> Please, also put patch 5 before patch 4. It will go smoothly,

It didn't, but that's not a big deal.

> or I can send an updated version.

No need.

I've put the entire series (including the three last patches with Vinod's ACKs)
into my bleeding-edge branch, please check it in there and let me know if
anything is not right.

Thanks,
Rafael

Re: [PATCH v3 1/9] device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

[Andy Shevchenko]

On Wed, Dec 9, 2015 at 3:20 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> I've put the entire series (including the three last patches with Vinod's ACKs)
> into my bleeding-edge branch, please check it in there and let me know if
> anything is not right.

I just have checked, everything looks good.
Thank you, Rafael!

-- 
With Best Regards,
Andy Shevchenko

[PATCH v3 2/9] Revert "ACPI / LPSS: allow to use specific PM domain during ->probe()"

[Andy Shevchenko]

The specific power domain can't be used in a way provided by the commit
01ac170ba29a, i.e. pointer to platform device is a subject to change during
unbound / bind cycle.

This reverts commit 01ac170ba29a9903ee590e1ef2d8e6b27b49a16c.

Fixes: 3df2da968744 (Revert "ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/acpi/acpi_lpss.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index f9e0d09..da0e276 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -705,8 +705,13 @@ static int acpi_lpss_platform_notify(struct notifier_block *nb,
 	}
 
 	switch (action) {
-	case BUS_NOTIFY_ADD_DEVICE:
+	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:
 		if (pdata->dev_desc->flags & LPSS_LTR)
 			return sysfs_create_group(&pdev->dev.kobj,
 						  &lpss_attr_group);
@@ -714,7 +719,6 @@ static int acpi_lpss_platform_notify(struct notifier_block *nb,
 	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.6.2

[PATCH v3 3/9] ACPI / LPSS: allow to use specific PM domain during ->probe()

[Andy Shevchenko]

This is an amendment to previously pushed commit 01ac170ba29a (ACPI / LPSS:
allow to use specific PM domain during ->probe()). We can't assign anything to
the platform device on ADD_DEVICE stage since it might be changed during
unbound / bind cycle.

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

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index da0e276..6263939 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -705,9 +705,10 @@ static int acpi_lpss_platform_notify(struct notifier_block *nb,
 	}
 
 	switch (action) {
-	case BUS_NOTIFY_BOUND_DRIVER:
+	case BUS_NOTIFY_BIND_DRIVER:
 		pdev->dev.pm_domain = &acpi_lpss_pm_domain;
 		break;
+	case BUS_NOTIFY_DRIVER_NOT_BOUND:
 	case BUS_NOTIFY_UNBOUND_DRIVER:
 		pdev->dev.pm_domain = NULL;
 		break;
-- 
2.6.2

[PATCH v3 4/9] ACPI / LPSS: power on when probe() and otherwise when remove()

[Andy Shevchenko]

When LPSS drivers are compiled as a module, which is usually the case, the
second probe of that driver may fail because the driver is written in an
assumption that device is powered on. That is not the case for all drivers.
Moreover we would like not drain power in vain.

Implement ->activate() and ->dismiss() callbacks in the ACPI LPSS custom power
domain.

-------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --------

Case 1: The I2C probe() repeat.

/sys/bus/platform/devices/808622C1:00 \_SB_.PCI0.I2C1 [D3hot]
/sys/bus/platform/devices/808622C1:01 \_SB_.PCI0.I2C2 [D3hot]
/sys/bus/platform/devices/808622C1:02 \_SB_.PCI0.I2C3 [D3hot]
/sys/bus/platform/devices/808622C1:03 \_SB_.PCI0.I2C4 [D3hot]
/sys/bus/platform/devices/808622C1:05 \_SB_.PCI0.I2C6 [D3hot]
/sys/bus/platform/devices/808622C1:06 \_SB_.PCI0.I2C7 [D3hot]

% modprobe i2c-designware-platform
    i2c_designware 808622C1:00: Unknown Synopsys component type: 0xffffffff
    i2c_designware 808622C1:01: Unknown Synopsys component type: 0xffffffff
    i2c_designware 808622C1:02: Unknown Synopsys component type: 0xffffffff
    i2c_designware 808622C1:03: Unknown Synopsys component type: 0xffffffff
    i2c_designware 808622C1:05: Unknown Synopsys component type: 0xffffffff
    i2c_designware 808622C1:06: Unknown Synopsys component type: 0xffffffff

Case 2: The power drain in case of SDHCI.

/sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D3hot]
/sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D3hot]

% modprobe -r sdhci-acpi
    mmc0: card 0001 removed

/sys/bus/platform/devices/80860F14:00 \_SB_.PCI0.SDHA [D0]
/sys/bus/platform/devices/80860F14:01 \_SB_.PCI0.SDHC [D0]

-------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --------

Patch fixes above problems.

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

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 6263939..c5f12f3 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -596,6 +596,34 @@ static void acpi_lpss_restore_ctx(struct device *dev,
 	}
 }
 
+static int acpi_lpss_activate(struct device *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_d3_to_d0_delay(pdata);
+
+	/*
+	 * This is called only on ->probe() stage where a device is either in
+	 * known state defined by BIOS or most likely powered off. Due to this
+	 * we have to deassert reset line to be sure that ->probe() will
+	 * recognize the device.
+	 */
+	if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
+		lpss_deassert_reset(pdata);
+
+	return 0;
+}
+
+static void acpi_lpss_dismiss(struct device *dev)
+{
+	acpi_dev_runtime_suspend(dev);
+}
+
 #ifdef CONFIG_PM_SLEEP
 static int acpi_lpss_suspend_late(struct device *dev)
 {
@@ -660,6 +688,10 @@ static int acpi_lpss_runtime_resume(struct device *dev)
 #endif /* CONFIG_PM */
 
 static struct dev_pm_domain acpi_lpss_pm_domain = {
+#ifdef CONFIG_PM
+	.activate = acpi_lpss_activate,
+	.dismiss = acpi_lpss_dismiss,
+#endif
 	.ops = {
 #ifdef CONFIG_PM
 #ifdef CONFIG_PM_SLEEP
-- 
2.6.2

[PATCH v3 5/9] ACPI / LPSS: do delay for all LPSS devices when D3->D0

[Andy Shevchenko]

The LPSS DMA device has no context to save, though it requires the same delay
like the rest of LPSS devices when power state is changed from D3 to D0.

Do delay for the DMA device as well.

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

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index c5f12f3..a10c2d6 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -574,6 +574,17 @@ static void acpi_lpss_restore_ctx(struct device *dev,
 {
 	unsigned int i;
 
+	for (i = 0; i < LPSS_PRV_REG_COUNT; i++) {
+		unsigned long offset = i * sizeof(u32);
+
+		__lpss_reg_write(pdata->prv_reg_ctx[i], pdata, offset);
+		dev_dbg(dev, "restoring 0x%08x to LPSS reg at offset 0x%02lx\n",
+			pdata->prv_reg_ctx[i], offset);
+	}
+}
+
+static void acpi_lpss_d3_to_d0_delay(struct lpss_private_data *pdata)
+{
 	/*
 	 * The following delay is needed or the subsequent write operations may
 	 * fail. The LPSS devices are actually PCI devices and the PCI spec
@@ -586,14 +597,6 @@ static void acpi_lpss_restore_ctx(struct device *dev,
 		delay = 0;
 
 	msleep(delay);
-
-	for (i = 0; i < LPSS_PRV_REG_COUNT; i++) {
-		unsigned long offset = i * sizeof(u32);
-
-		__lpss_reg_write(pdata->prv_reg_ctx[i], pdata, offset);
-		dev_dbg(dev, "restoring 0x%08x to LPSS reg at offset 0x%02lx\n",
-			pdata->prv_reg_ctx[i], offset);
-	}
 }
 
 static int acpi_lpss_activate(struct device *dev)
@@ -649,6 +652,8 @@ static int acpi_lpss_resume_early(struct device *dev)
 	if (ret)
 		return ret;
 
+	acpi_lpss_d3_to_d0_delay(pdata);
+
 	if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
 		acpi_lpss_restore_ctx(dev, pdata);
 
@@ -680,6 +685,8 @@ static int acpi_lpss_runtime_resume(struct device *dev)
 	if (ret)
 		return ret;
 
+	acpi_lpss_d3_to_d0_delay(pdata);
+
 	if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
 		acpi_lpss_restore_ctx(dev, pdata);
 
-- 
2.6.2

[PATCH v3 6/9] ACPI / LPSS: override power state for LPSS DMA device

[Andy Shevchenko]

This is a third approach to workaround long standing issue with LPSS on
BayTrail. First one [1] was reverted since it didn't resolve the issue
comprehensively. Second one [2] was rejected by internal review.

The LPSS DMA controller does not have neither _PS0 nor _PS3 method. 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 BayTrail [3,4] as
well as on ASuS T100TA transformer.

Power on the LPSS island through the registers accessible in a specific way.

[1] http://www.spinics.net/lists/linux-acpi/msg53963.html
[2] https://bugzilla.redhat.com/attachment.cgi?id=1066779&action=diff
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1184273
[4] http://www.spinics.net/lists/dmaengine/msg01514.html

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 arch/x86/Kconfig                |   3 +-
 arch/x86/include/asm/iosf_mbi.h |   2 +
 drivers/acpi/acpi_lpss.c        | 153 ++++++++++++++++++++++++++++++++++++++--
 3 files changed, 150 insertions(+), 8 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 324ac56..7fab0b9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -535,9 +535,10 @@ config X86_INTEL_QUARK
 
 config X86_INTEL_LPSS
 	bool "Intel Low Power Subsystem Support"
-	depends on ACPI
+	depends on X86 && ACPI
 	select COMMON_CLK
 	select PINCTRL
+	select IOSF_MBI
 	---help---
 	  Select to build support for Intel Low Power Subsystem such as
 	  found on Intel Lynxpoint PCH. Selecting this option enables
diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
index cdc5f63..b41ee16 100644
--- a/arch/x86/include/asm/iosf_mbi.h
+++ b/arch/x86/include/asm/iosf_mbi.h
@@ -19,6 +19,8 @@
 /* IOSF SB read/write opcodes */
 #define MBI_MMIO_READ		0x00
 #define MBI_MMIO_WRITE		0x01
+#define MBI_CFG_READ		0x04
+#define MBI_CFG_WRITE		0x05
 #define MBI_CR_READ		0x06
 #define MBI_CR_WRITE		0x07
 #define MBI_REG_READ		0x10
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index a10c2d6..630fb62 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -15,11 +15,16 @@
 #include <linux/clk-provider.h>
 #include <linux/err.h>
 #include <linux/io.h>
+#include <linux/mutex.h>
 #include <linux/platform_device.h>
 #include <linux/platform_data/clk-lpss.h>
 #include <linux/pm_runtime.h>
 #include <linux/delay.h>
 
+#include <asm/cpu_device_id.h>
+#include <asm/iosf_mbi.h>
+#include <asm/pmc_atom.h>
+
 #include "internal.h"
 
 ACPI_MODULE_NAME("acpi_lpss");
@@ -71,7 +76,7 @@ struct lpss_device_desc {
 	void (*setup)(struct lpss_private_data *pdata);
 };
 
-static struct lpss_device_desc lpss_dma_desc = {
+static const struct lpss_device_desc lpss_dma_desc = {
 	.flags = LPSS_CLK,
 };
 
@@ -84,6 +89,23 @@ struct lpss_private_data {
 	u32 prv_reg_ctx[LPSS_PRV_REG_COUNT];
 };
 
+/* LPSS run time quirks */
+static unsigned int lpss_quirks;
+
+/*
+ * LPSS_QUIRK_ALWAYS_POWER_ON: override power state for LPSS DMA device.
+ *
+ * The LPSS DMA controller does not have neither _PS0 nor _PS3 method. 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 BayTrail as
+ * well as on ASuS T100TA transformer.
+ *
+ * This quirk overrides power state of entire LPSS island to keep DMA powered
+ * on whenever we have at least one other device in use.
+ */
+#define LPSS_QUIRK_ALWAYS_POWER_ON	BIT(0)
+
 /* UART Component Parameter Register */
 #define LPSS_UART_CPR			0xF4
 #define LPSS_UART_CPR_AFCE		BIT(4)
@@ -196,13 +218,21 @@ static const struct lpss_device_desc bsw_i2c_dev_desc = {
 	.setup = byt_i2c_setup,
 };
 
-static struct lpss_device_desc bsw_spi_dev_desc = {
+static const struct lpss_device_desc bsw_spi_dev_desc = {
 	.flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX
 			| LPSS_NO_D3_DELAY,
 	.prv_offset = 0x400,
 	.setup = lpss_deassert_reset,
 };
 
+#define ICPU(model)	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
+
+static const struct x86_cpu_id lpss_cpu_ids[] = {
+	ICPU(0x37),	/* Valleyview, Bay Trail */
+	ICPU(0x4c),	/* Braswell, Cherry Trail */
+	{}
+};
+
 #else
 
 #define LPSS_ADDR(desc) (0UL)
@@ -661,6 +691,89 @@ static int acpi_lpss_resume_early(struct device *dev)
 }
 #endif /* CONFIG_PM_SLEEP */
 
+/* IOSF SB for LPSS island */
+#define LPSS_IOSF_UNIT_LPIOEP		0xA0
+#define LPSS_IOSF_UNIT_LPIO1		0xAB
+#define LPSS_IOSF_UNIT_LPIO2		0xAC
+
+#define LPSS_IOSF_PMCSR			0x84
+#define LPSS_PMCSR_D0			0
+#define LPSS_PMCSR_D3hot		3
+#define LPSS_PMCSR_Dx_MASK		GENMASK(1, 0)
+
+#define LPSS_IOSF_GPIODEF0		0x154
+#define LPSS_GPIODEF0_DMA1_D3		BIT(2)
+#define LPSS_GPIODEF0_DMA2_D3		BIT(3)
+#define LPSS_GPIODEF0_DMA_D3_MASK	GENMASK(3, 2)
+
+static DEFINE_MUTEX(lpss_iosf_mutex);
+
+static void lpss_iosf_enter_d3_state(void)
+{
+	u32 value1 = 0;
+	u32 mask1 = LPSS_GPIODEF0_DMA_D3_MASK;
+	u32 value2 = LPSS_PMCSR_D3hot;
+	u32 mask2 = LPSS_PMCSR_Dx_MASK;
+	/*
+	 * PMC provides an information about actual status of the LPSS devices.
+	 * Here we read the values related to LPSS power island, i.e. LPSS
+	 * devices, excluding both LPSS DMA controllers, along with SCC domain.
+	 */
+	u32 func_dis, d3_sts_0, pmc_status, pmc_mask = 0xfe000ffe;
+	int ret;
+
+	ret = pmc_atom_read(PMC_FUNC_DIS, &func_dis);
+	if (ret)
+		return;
+
+	mutex_lock(&lpss_iosf_mutex);
+
+	ret = pmc_atom_read(PMC_D3_STS_0, &d3_sts_0);
+	if (ret)
+		goto exit;
+
+	/*
+	 * Get the status of entire LPSS power island per device basis.
+	 * Shutdown both LPSS DMA controllers if and only if all other devices
+	 * are already in D3hot.
+	 */
+	pmc_status = (~(d3_sts_0 | func_dis)) & pmc_mask;
+	if (pmc_status)
+		goto exit;
+
+	iosf_mbi_modify(LPSS_IOSF_UNIT_LPIO1, MBI_CFG_WRITE,
+			LPSS_IOSF_PMCSR, value2, mask2);
+
+	iosf_mbi_modify(LPSS_IOSF_UNIT_LPIO2, MBI_CFG_WRITE,
+			LPSS_IOSF_PMCSR, value2, mask2);
+
+	iosf_mbi_modify(LPSS_IOSF_UNIT_LPIOEP, MBI_CR_WRITE,
+			LPSS_IOSF_GPIODEF0, value1, mask1);
+exit:
+	mutex_unlock(&lpss_iosf_mutex);
+}
+
+static void lpss_iosf_exit_d3_state(void)
+{
+	u32 value1 = LPSS_GPIODEF0_DMA1_D3 | LPSS_GPIODEF0_DMA2_D3;
+	u32 mask1 = LPSS_GPIODEF0_DMA_D3_MASK;
+	u32 value2 = LPSS_PMCSR_D0;
+	u32 mask2 = LPSS_PMCSR_Dx_MASK;
+
+	mutex_lock(&lpss_iosf_mutex);
+
+	iosf_mbi_modify(LPSS_IOSF_UNIT_LPIOEP, MBI_CR_WRITE,
+			LPSS_IOSF_GPIODEF0, value1, mask1);
+
+	iosf_mbi_modify(LPSS_IOSF_UNIT_LPIO2, MBI_CFG_WRITE,
+			LPSS_IOSF_PMCSR, value2, mask2);
+
+	iosf_mbi_modify(LPSS_IOSF_UNIT_LPIO1, MBI_CFG_WRITE,
+			LPSS_IOSF_PMCSR, value2, mask2);
+
+	mutex_unlock(&lpss_iosf_mutex);
+}
+
 static int acpi_lpss_runtime_suspend(struct device *dev)
 {
 	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
@@ -673,7 +786,17 @@ 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);
+
+	/*
+	 * This call must be last in the sequence, otherwise PMC will return
+	 * wrong status for devices being about to be powered off. See
+	 * lpss_iosf_enter_d3_state() for further information.
+	 */
+	if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
+		lpss_iosf_enter_d3_state();
+
+	return ret;
 }
 
 static int acpi_lpss_runtime_resume(struct device *dev)
@@ -681,6 +804,13 @@ static int acpi_lpss_runtime_resume(struct device *dev)
 	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
 	int ret;
 
+	/*
+	 * This call is kept first to be in symmetry with
+	 * acpi_lpss_runtime_suspend() one.
+	 */
+	if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
+		lpss_iosf_exit_d3_state();
+
 	ret = acpi_dev_runtime_resume(dev);
 	if (ret)
 		return ret;
@@ -798,10 +928,19 @@ static struct acpi_scan_handler lpss_handler = {
 
 void __init acpi_lpss_init(void)
 {
-	if (!lpt_clk_init()) {
-		bus_register_notifier(&platform_bus_type, &acpi_lpss_nb);
-		acpi_scan_add_handler(&lpss_handler);
-	}
+	const struct x86_cpu_id *id;
+	int ret;
+
+	ret = lpt_clk_init();
+	if (ret)
+		return;
+
+	id = x86_match_cpu(lpss_cpu_ids);
+	if (id)
+		lpss_quirks |= LPSS_QUIRK_ALWAYS_POWER_ON;
+
+	bus_register_notifier(&platform_bus_type, &acpi_lpss_nb);
+	acpi_scan_add_handler(&lpss_handler);
 }
 
 #else
-- 
2.6.2

[PATCH v3 7/9] dmaengine: dw: platform: power on device on shutdown

[Andy Shevchenko]

We have to call dw_dma_disable() to stop any ongoing transfer. On some
platforms we can't do that since DMA device is powered off. Moreover we have no
possibility at that point to check if the platform is affected or not. That's
why we call pm_runtime_get_sync() / pm_runtime_put() unconditionally. On the
other hand we can't use pm_runtime_suspended() because runtime PM framework is
not fully used by the driver.

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

diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 68a4815..d0734e9 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -239,7 +239,19 @@ static void dw_shutdown(struct platform_device *pdev)
 {
 	struct dw_dma_chip *chip = platform_get_drvdata(pdev);
 
+	/*
+	 * We have to call dw_dma_disable() to stop any ongoing transfer. On
+	 * some platforms we can't do that since DMA device is powered off.
+	 * Moreover we have no possibility to check if the platform is affected
+	 * or not. That's why we call pm_runtime_get_sync() / pm_runtime_put()
+	 * unconditionally. On the other hand we can't use
+	 * pm_runtime_suspended() because runtime PM framework is not fully
+	 * used by the driver.
+	 */
+	pm_runtime_get_sync(chip->dev);
 	dw_dma_disable(chip);
+	pm_runtime_put_sync_suspend(chip->dev);
+
 	clk_disable_unprepare(chip->clk);
 }
 
-- 
2.6.2

Re: [PATCH v3 7/9] dmaengine: dw: platform: power on device on shutdown

[Vinod Koul]

On Fri, Dec 04, 2015 at 11:49:23PM +0200, Andy Shevchenko wrote:
> We have to call dw_dma_disable() to stop any ongoing transfer. On some
> platforms we can't do that since DMA device is powered off. Moreover we have no
> possibility at that point to check if the platform is affected or not. That's
> why we call pm_runtime_get_sync() / pm_runtime_put() unconditionally. On the
> other hand we can't use pm_runtime_suspended() because runtime PM framework is
> not fully used by the driver.
 
Acked-by: Vinod Koul <vinod.koul@intel.com>

-- 
~Vinod

[PATCH v3 8/9] dmaengine: dw: return immediately from IRQ when DMA isn't in use

[Andy Shevchenko]

There is no need to bother the hardware when all channels are idle. We have not
to get any interrupts.

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

diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 7067b6d..8b20930 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -622,12 +622,17 @@ static void dw_dma_tasklet(unsigned long data)
 static irqreturn_t dw_dma_interrupt(int irq, void *dev_id)
 {
 	struct dw_dma *dw = dev_id;
-	u32 status = dma_readl(dw, STATUS_INT);
+	u32 status;
 
+	/* Check if we have any interrupt from the DMAC which is not in use */
+	if (!dw->in_use)
+		return IRQ_NONE;
+
+	status = dma_readl(dw, STATUS_INT);
 	dev_vdbg(dw->dma.dev, "%s: status=0x%x\n", __func__, status);
 
 	/* Check if we have any interrupt from the DMAC */
-	if (!status || !dw->in_use)
+	if (!status)
 		return IRQ_NONE;
 
 	/*
-- 
2.6.2

Re: [PATCH v3 8/9] dmaengine: dw: return immediately from IRQ when DMA isn't in use

[Vinod Koul]

On Fri, Dec 04, 2015 at 11:49:24PM +0200, Andy Shevchenko wrote:
> There is no need to bother the hardware when all channels are idle. We have not
> to get any interrupts.

Acked-by: Vinod Koul <vinod.koul@intel.com>

-- 
~Vinod

[PATCH v3 9/9] Revert "dmaengine: dw: platform: provide platform data for Intel"

[Andy Shevchenko]

Since we have a work around to prevent a system hangup we don't need to provide
a platform data explicitly anymore.

This reverts commit 175267b389f781748e2bbb6c737e76b5c9bc4c88.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/dma/dw/platform.c | 17 +----------------
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index d0734e9..127093a 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -155,7 +155,6 @@ static int dw_probe(struct platform_device *pdev)
 	struct dw_dma_chip *chip;
 	struct device *dev = &pdev->dev;
 	struct resource *mem;
-	const struct acpi_device_id *id;
 	struct dw_dma_platform_data *pdata;
 	int err;
 
@@ -179,11 +178,6 @@ static int dw_probe(struct platform_device *pdev)
 	pdata = dev_get_platdata(dev);
 	if (!pdata)
 		pdata = dw_dma_parse_dt(pdev);
-	if (!pdata && has_acpi_companion(dev)) {
-		id = acpi_match_device(dev->driver->acpi_match_table, dev);
-		if (id)
-			pdata = (struct dw_dma_platform_data *)id->driver_data;
-	}
 
 	chip->dev = dev;
 
@@ -264,17 +258,8 @@ MODULE_DEVICE_TABLE(of, dw_dma_of_id_table);
 #endif
 
 #ifdef CONFIG_ACPI
-static struct dw_dma_platform_data dw_dma_acpi_pdata = {
-	.nr_channels = 8,
-	.is_private = true,
-	.chan_allocation_order = CHAN_ALLOCATION_ASCENDING,
-	.chan_priority = CHAN_PRIORITY_ASCENDING,
-	.block_size = 4095,
-	.nr_masters = 2,
-};
-
 static const struct acpi_device_id dw_dma_acpi_id_table[] = {
-	{ "INTL9C60", (kernel_ulong_t)&dw_dma_acpi_pdata },
+	{ "INTL9C60", 0 },
 	{ }
 };
 MODULE_DEVICE_TABLE(acpi, dw_dma_acpi_id_table);
-- 
2.6.2

Re: [PATCH v3 9/9] Revert "dmaengine: dw: platform: provide platform data for Intel"

[Vinod Koul]

On Fri, Dec 04, 2015 at 11:49:25PM +0200, Andy Shevchenko wrote:
> Since we have a work around to prevent a system hangup we don't need to provide
> a platform data explicitly anymore.

Acked-by: Vinod Koul <vinod.koul@intel.com>

-- 
~Vinod

Re: [PATCH v3 0/9] ACPI / LPSS: fix system hangup on BYT/BSW/CHT

[Rafael J. Wysocki]

On Friday, December 04, 2015 11:49:16 PM Andy Shevchenko wrote:
> Here is a v3 of the next generation (previous one is [1]) of the long standing
> power issue fix regarding to LPSS on Intel Baytrail and Braswell SoCs, in
> particularly ASuS T100TA. There are few bugs already opened on kernel.org's and
> RedHat's bugzilla sites.
> 
> The series depends on the patch submitted earlier [2].
> 
> The patch 1 brings a new notification to handle the case when ->probe() of the
> driver fails. It allows to avoid a potential problems. I've noticed couple of
> drivers that are using that in assumption that ->probe() never fails.
> 
> The patches 2 & 4 are needed to fix an I2C issue which Jarkko is currently
> investigating.
> 
> It seems the best way to push it through linux-pm tree. Thus, it would be good
> to get ACKs from the rest of maintainers.
> 
> Rafael, it would be nice to have an immutable branch or tag for this sice I
> have more patches coming for dw_dmac driver which are based on top of this
> series.
> 
> The patches have been tested on ASuS T100TA, Intel Cherrytrail, and Intel
> Braswell SoCs.
> 
> [1] http://www.spinics.net/lists/linux-acpi/msg53963.html
> [2] http://www.spinics.net/lists/kernel/msg2119229.html
> 
> Changelog v3:
> - patch 2 is split to pure revert with Fixes tag for stable and new change in
>   patch 3
> - add patch 4 to resolve an issue when I2C can't be probed and SDHCI leaves
>   devices in D0
> - address comments from Rafael
> - quirk functions moved under CONFIG_PM
> 
> Andy Shevchenko (9):
>   device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification
>   Revert "ACPI / LPSS: allow to use specific PM domain during ->probe()"
>   ACPI / LPSS: allow to use specific PM domain during ->probe()
>   ACPI / LPSS: power on when probe() and otherwise when remove()
>   ACPI / LPSS: do delay for all LPSS devices when D3->D0
>   ACPI / LPSS: override power state for LPSS DMA device
>   dmaengine: dw: platform: power on device on shutdown
>   dmaengine: dw: return immediately from IRQ when DMA isn't in use
>   Revert "dmaengine: dw: platform: provide platform data for Intel"
> 
>  arch/x86/Kconfig                |   3 +-
>  arch/x86/include/asm/iosf_mbi.h |   2 +
>  drivers/acpi/acpi_lpss.c        | 213 +++++++++++++++++++++++++++++++++++++---
>  drivers/base/dd.c               |  10 +-
>  drivers/dma/dw/core.c           |   9 +-
>  drivers/dma/dw/platform.c       |  29 +++---
>  include/linux/device.h          |   1 +
>  7 files changed, 231 insertions(+), 36 deletions(-)

The series generally looks good to me, but patch [1/9] needs an ACK from Greg
and the dmaengine ones need ACKs from Vinod.

Thanks,
Rafael

Re: [PATCH v3 0/9] ACPI / LPSS: fix system hangup on BYT/BSW/CHT

[Andy Shevchenko]

On Sat, Dec 5, 2015 at 1:07 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Friday, December 04, 2015 11:49:16 PM Andy Shevchenko wrote:
>> Here is a v3 of the next generation (previous one is [1]) of the long standing
>> power issue fix regarding to LPSS on Intel Baytrail and Braswell SoCs, in
>> particularly ASuS T100TA. There are few bugs already opened on kernel.org's and
>> RedHat's bugzilla sites.
>>
>> The series depends on the patch submitted earlier [2].
>>
>> The patch 1 brings a new notification to handle the case when ->probe() of the
>> driver fails. It allows to avoid a potential problems. I've noticed couple of
>> drivers that are using that in assumption that ->probe() never fails.
>>
>> The patches 2 & 4 are needed to fix an I2C issue which Jarkko is currently
>> investigating.
>>
>> It seems the best way to push it through linux-pm tree. Thus, it would be good
>> to get ACKs from the rest of maintainers.
>>
>> Rafael, it would be nice to have an immutable branch or tag for this sice I
>> have more patches coming for dw_dmac driver which are based on top of this
>> series.
>>
>> The patches have been tested on ASuS T100TA, Intel Cherrytrail, and Intel
>> Braswell SoCs.
>>
>> [1] http://www.spinics.net/lists/linux-acpi/msg53963.html
>> [2] http://www.spinics.net/lists/kernel/msg2119229.html
>>
>> Changelog v3:
>> - patch 2 is split to pure revert with Fixes tag for stable and new change in
>>   patch 3
>> - add patch 4 to resolve an issue when I2C can't be probed and SDHCI leaves
>>   devices in D0
>> - address comments from Rafael
>> - quirk functions moved under CONFIG_PM
>>
>> Andy Shevchenko (9):
>>   device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification
>>   Revert "ACPI / LPSS: allow to use specific PM domain during ->probe()"
>>   ACPI / LPSS: allow to use specific PM domain during ->probe()
>>   ACPI / LPSS: power on when probe() and otherwise when remove()
>>   ACPI / LPSS: do delay for all LPSS devices when D3->D0
>>   ACPI / LPSS: override power state for LPSS DMA device
>>   dmaengine: dw: platform: power on device on shutdown
>>   dmaengine: dw: return immediately from IRQ when DMA isn't in use
>>   Revert "dmaengine: dw: platform: provide platform data for Intel"
>>
>>  arch/x86/Kconfig                |   3 +-
>>  arch/x86/include/asm/iosf_mbi.h |   2 +
>>  drivers/acpi/acpi_lpss.c        | 213 +++++++++++++++++++++++++++++++++++++---
>>  drivers/base/dd.c               |  10 +-
>>  drivers/dma/dw/core.c           |   9 +-
>>  drivers/dma/dw/platform.c       |  29 +++---
>>  include/linux/device.h          |   1 +
>>  7 files changed, 231 insertions(+), 36 deletions(-)
>
> The series generally looks good to me, but patch [1/9] needs an ACK from Greg
> and the dmaengine ones need ACKs from Vinod.

Thank you!
Greg, Vinod, what is your opinion?

Just noticed we have to exchange patches 4 and 5 (5 should go before 4
due to bisectability).

Also I would like to ask you to comment and maybe Ack (seems we have
no powercap maintainers) the mentioned patch for dependency [2].

>> [2] http://www.spinics.net/lists/kernel/msg2119229.html

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 0/9] ACPI / LPSS: fix system hangup on BYT/BSW/CHT

[Rafael J. Wysocki]

Hi,

On Sat, Dec 5, 2015 at 12:15 AM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Sat, Dec 5, 2015 at 1:07 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> On Friday, December 04, 2015 11:49:16 PM Andy Shevchenko wrote:

[cut]

>>
>> The series generally looks good to me, but patch [1/9] needs an ACK from Greg
>> and the dmaengine ones need ACKs from Vinod.
>
> Thank you!
> Greg, Vinod, what is your opinion?
>
> Just noticed we have to exchange patches 4 and 5 (5 should go before 4
> due to bisectability).
>
> Also I would like to ask you to comment and maybe Ack (seems we have
> no powercap maintainers) the mentioned patch for dependency [2].
>
>>> [2] http://www.spinics.net/lists/kernel/msg2119229.html

I'm the top-level powercap maintainer, but the RAPL driver is
maintained by Jacob.  Please ask him for an ACK.

Thanks,
Rafael

Re: [PATCH v3 0/9] ACPI / LPSS: fix system hangup on BYT/BSW/CHT

[Jacob Pan]

On Sat, 5 Dec 2015 01:07:47 +0100
"Rafael J. Wysocki" <rafael@kernel.org> wrote:

> >>> [2] http://www.spinics.net/lists/kernel/msg2119229.html  
> 
> I'm the top-level powercap maintainer, but the RAPL driver is
> maintained by Jacob.  Please ask him for an ACK.

looks good to me. no functional change to the driver.