Commit 12864ff8 (ACPI / LPSS: Avoid PM quirks on suspend and resume
from hibernation) bypasses lpss quirks for S3 and S4, by setting a flag
for S3/S4 in acpi_lpss_suspend(), and check that flag in
acpi_lpss_resume().

But this overlooks the boot case where acpi_lpss_resume() may get called
without a corresponding acpi_lpss_suspend() having been called.

Thus force setting the flag during boot.

Fixes: 12864ff8 (ACPI / LPSS: Avoid PM quirks on suspend and resume from hibernation)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200989Reported-and-tested-by: NWilliam Lieurance <william.lieurance@namikoda.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Cc: 4.15+ <stable@vger.kernel.org> # 4.15+: 12864ff8 (ACPI / LPSS: Avoid ...)
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit a09c5913 (ACPI / LPSS: Avoid PM quirks on suspend and
resume from S3) modified the ACPI driver for Intel SoCs (LPSS) to
avoid applying PM quirks on suspend and resume from S3 to address
system-wide suspend and resume problems on some systems, but it is
reported that the same issue also affects hibernation, so extend
the approach used by that commit to cover hibernation as well.

Fixes: a09c5913 (ACPI / LPSS: Avoid PM quirks on suspend and resume from S3)
Link: https://bugs.launchpad.net/bugs/1774950Reported-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

It is reported that commit a192aa92 (ACPI / LPSS: Consolidate
runtime PM and system sleep handling) introduced a system suspend
regression on some machines, but the only functional change made by
it was to cause the PM quirks in the LPSS to also be used during
system suspend and resume.  While that should always work for
suspend-to-idle, it turns out to be problematic for S3
(suspend-to-RAM).

To address that issue restore the previous S3 suspend and resume
behavior of the LPSS to avoid applying PM quirks then.

Fixes: a192aa92 (ACPI / LPSS: Consolidate runtime PM and system sleep handling)
Link: https://bugs.launchpad.net/bugs/1774950Reported-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: 4.15+ <stable@vger.kernel.org> # 4.15+

The LPSS PWM device on on Bay Trail and Cherry Trail devices has a set
of private registers at offset 0x800, the current lpss_device_desc for
them already sets the LPSS_SAVE_CTX flag to have these saved/restored
over device-suspend, but the current lpss_device_desc was not setting
the prv_offset field, leading to the regular device registers getting
saved/restored instead.

This is causing the PWM controller to no longer work, resulting in a black
screen,  after a suspend/resume on systems where the firmware clears the
APB clock and reset bits at offset 0x804.

This commit fixes this by properly setting prv_offset to 0x800 for
the PWM devices.

Cc: stable@vger.kernel.org
Fixes: e1c74817 ("ACPI / LPSS: Add Intel BayTrail ACPI mode PWM")
Fixes: 1bfbd8eb ("ACPI / LPSS: Add ACPI IDs for Intel Braswell")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NRafael J . Wysocki <rjw@rjwysocki.net>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

The Point of View mobii wintab p800w Bay Trail tablet comes with a Crystal
Cove PMIC, yet uses the LPSS PWM for backlight control, rather then the
Crystal Cove's PWM, so we need to call pwm_add_table() to add a
pwm_backlight mapping for the LPSS pwm despite there being an INT33FD
ACPI device present.

On all Bay Trail devices the _HRV object of the INT33FD ACPI device
will normally return 2, to indicate the Bay Trail variant of the CRC
PMIC is present, except on this tablet where _HRV is 0xffff. I guess this
is a hack to make the windows Crystal Cove PWM driver not bind.

Out of the 44 DSTDs with an INT33FD device in there which I have (from
different model devices) only the pov mobii wintab p800w uses 0xffff for
the HRV.

The byt_pwm_setup code calls acpi_dev_present to check for the presence
of a INT33FD ACPI device which indicates that a CRC PMIC is present and
if the INT33FD ACPI device is present then byt_pwm_setup will not add
a pwm_backlight mapping for the LPSS pwm, so that the CRC PWM will get
used instead.

acpi_dev_present has a hrv parameter, this commit make us pass 2 instead
of -1, so that things still match on normal tablets, but on this special
case with its _HRV of 0xffff, the check will now fail so that the
pwm_backlight mapping for the LPSS pwm gets added fixing backlight
brightness control on this device.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

acpi_lpss_create_device() skips handling LPSS devices which do not have
a mmio resources in their resource list (typically these devices are
disabled by the firmware). But since the LPSS code does not bind to the
device, acpi_bus_attach() ends up still creating a platform device for
it and the regular platform_driver for the ACPI HID still tries to bind
to it.

This happens e.g. on some boards which do not use the pwm-controller
and have an empty or invalid resource-table for it. Currently this causes
these error messages to get logged:

[    3.281966] pwm-lpss 80862288:00: invalid resource
[    3.287098] pwm-lpss: probe of 80862288:00 failed with error -22

This commit stops the undesirable creation of a platform_device for
disabled LPSS devices by setting pnp.type.platform_id to 0. Note that
acpi_scan_attach_handler() also sets pnp.type.platform_id to 0 when there
is a matching handler for the device and that handler has no attach
callback, so we simply behave as a handler without an attach function
in this case.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some Cherry Trail boards have a dependency between the SDHCI host
controller used for SD cards and an external PMIC accessed via I2C. Add a
device link between the SDHCI host controller (consumer) and the I2C
adapter (supplier).

This patch depends on a fix to devices links, namely commit 0ff26c66
("driver core: Fix device link deferred probe"). And also either,
commit 126dbc6b ("PM: i2c-designware-platdrv: Clean up PM handling in
probe"), or patch "PM / runtime: Fix handling of suppliers with disabled
runtime PM".
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The pointer clk is being initialized to ERR_PTR(-ENODEV) however
this value is never read before it is set to clk_data->clk. Thus
the initialization is redundant and can be mored.

Cleans up clang warning:
Value stored to 'clk' during its initialization is never read
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.

[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]

Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().

Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.

In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.

On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move the LPSS-specific code from acpi_lpss_runtime_suspend()
and acpi_lpss_runtime_resume() into separate functions,
acpi_lpss_suspend() and acpi_lpss_resume(), respectively, and
make acpi_lpss_suspend_late() and acpi_lpss_resume_early() use
them too in order to unify the runtime PM and system sleep
handling in the LPSS driver.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>

On top of a previous change getting rid of the PM QoS flag
PM_QOS_FLAG_REMOTE_WAKEUP, combine two ACPI device suspend routines,
acpi_dev_runtime_suspend() and acpi_dev_suspend_late(), into one,
acpi_dev_suspend(), to eliminate some code duplication.

It also avoids enabling wakeup for devices handled by the ACPI
LPSS middle layer on driver removal.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>

Commit 58a1fbbb (PM / PCI / ACPI: Kick devices that might have
been reset by firmware), made PCI's and ACPI's ->complete() callbacks
to be assigned to a new API called pm_complete_with_resume_check(),
which was introduced in the same change.

Later it turned out that using pm_complete_with_resume_check() wasn't
good enough for PCI, as it needed additional PCI specific checks,
before deciding whether runtime resuming the device is needed when
running the ->complete() callback.

This leaves ACPI as the only user of pm_complete_with_resume_check().
Therefore let's restore ACPI's acpi_subsys_complete(), which was
dropped in commit 58a1fbbb (PM / PCI / ACPI: Kick devices that
might have been reset by firmware).

This enables us to remove the pm_complete_with_resume_check() API in
a following change, but it also enables ACPI to add more ACPI
specific checks in acpi_subsys_complete() if that turns out to be
necessary.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Notice that acpi_dev_runtime_resume() and acpi_dev_resume_early() are
actually literally identical after some more-or-less recent changes,
so rename acpi_dev_runtime_resume() to acpi_dev_resume(), use it
everywhere instead of acpi_dev_resume_early() and drop the latter.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>

The keyboard and touchpad on MacBook's from 2015 onwards are connected
via an SPI bus. On MacBook8's (2015) the ACPI device for the SPI master
for this bus has _CID "INT33C1", and hence the acpi-lpss handler here is
triggered for it. However, the DSDT lists no memory resources for this
device, resulting in an error being returned by the attach callback and
therefore the SPI master device being ignored. This prevents us from
being able to register the keyboard and touchpad driver.

Furthermore, the controller (a Wildcat Point-LP controller) does not
appear to need the functionality provided by the apci-lpss handler.
Therefore we now just skip the handler if no memory resources are found
and let the ACPI scan complete successfully for this device.

All of this is not an issue on later MacBook(Pro)'s because their ACPI
SPI devices don't have any _CID and therefore no attempt is made to attach
this handler.

Returning an error was introduced in commit d3e13ff3 - this restores
the original behaviour.

Link: https://github.com/cb22/macbook12-spi-driverSigned-off-by: NRonald Tschalär <ronald@innovation.ch>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

At least on the UP board SBC both PWMs are enabled leading to us
trying to add the same pwm_lookup twice, which leads to the following:

[    0.902224] list_add double add: new=ffffffffb8efd400,
               prev=ffffffffb8efd400, next=ffffffffb8eeede0.
[    0.912466] ------------[ cut here ]------------
[    0.917624] kernel BUG at lib/list_debug.c:31!
[    0.922588] invalid opcode: 0000 [#1] SMP
...
[    1.027450] Call Trace:
[    1.030185]  pwm_add_table+0x4c/0x90
[    1.034181]  bsw_pwm_setup+0x1a/0x20
[    1.038175]  acpi_lpss_create_device+0xfe/0x420
...

This commit fixes this by only calling pwm_add_table() for the first
PWM controller (which is the one used for the backlight).

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1458599
Fixes: bf7696a1 (acpi: lpss: call pwm_add_table() for BSW...)
Fixes: 04434ab5 (ACPI / LPSS: Call pwm_add_table() for Bay Trail...)
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: 4.11+ <stable@vger.kernel.org> # 4.11+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work with const
attribute_group. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On Bay Trail systems with a Crystal Cove PMIC the Crystal Cove's PWM is
used to control the backlight brightness. On systems without one, the
Crystal Cove SoC's PWM is used and we need to call pwm_add_table() so
that the i915 driver can find the pwm for controlling the backlight.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On x86 we do not have devicetree to link the PWM controller and
the display controller together. So someone needs to call
pwm_add_table() to create the link, so that the i915 driver's
pwm_get(dev, "pwm_backlight") call returns the lpss' pwm0.

The PWM subsystem does not want to have pwm_add_table() calls
directly in PWM drivers (this leads to probe ordering issues),
so lets do it here since the acpi-lpss code is always builtin.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

The pmc_atom driver does not contain any architecture specific
code. It only enables the SoC Power Management Controller driver
for BayTrail and CherryTrail platforms.

Move the pmc_atom driver from arch/x86/platform/atom to
drivers/platform/x86. Also clean-up and reorder include files by
alphabetical order in pmc_atom.h
Signed-off-by: NIrina Tirdea <irina.tirdea@intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Right now the DMA support of hard LLP (*) is fused. Enable it via specific
message sent to SoC at run time.

(*) Hard LLP stands for the multi-block transfer feature of DMA controller
supported by hardware.
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We have a couple of drivers, acpi_apd.c and acpi_lpss.c,
that need to pass extra build-in properties to the devices
they create. Previously the drivers added those properties
to the struct device which is member of the struct
acpi_device, but that does not work. Those properties need
to be assigned to the struct device of the platform device
instead in order for them to become available to the
drivers.

To fix this, this patch changes acpi_create_platform_device
function to take struct property_entry pointer as parameter.

Fixes: 20a875e2 (serial: 8250_dw: Add quirk for APM X-Gene SoC)
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Tested-by: NYazen Ghannam <yazen.ghannam@amd.com>
Tested-by: NJérôme de Bretagne <jerome.debretagne@gmail.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The UART driver, dw8250.c, needs some details regarding the
Designware UART. For ACPI enumerated devices the values are
hard-coded, but since the driver also reads the values from
device properties, providing them with build-in properties.
This allows us to later remove the hard-coded values from
the driver.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Another straightforward replacement of magic numbers.
Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: jacob.jun.pan@intel.com
Cc: linux-acpi@vger.kernel.org
Link: http://lkml.kernel.org/r/20160603001946.264CE704@viggo.jf.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

The commit 989561de ("PM / Domains: add setter for dev.pm_domain") changed
acpi_lpss.c module to use PM domain setter, though it missed one assignment.
Add it here.

Fixes: 989561de (PM / Domains: add setter for dev.pm_domain)
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Adds a function that sets the pointer to dev_pm_domain in struct device
and that warns if the device has already finished probing. The reason
why we want to enforce that is because in the general case that can
cause problems and also that we can simplify code quite a bit if we can
always assume that.

This patch also changes all current code that directly sets the
dev.pm_domain pointer.
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The LPSS DMA device has neither _PS0 nor _PS3 method. Fix the wording in
the comment line.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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.htmlSigned-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This is an amendment to previously pushed commit 01ac170b (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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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

This reverts commit 01ac170b.

Fixes: 3df2da96 (Revert "ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is a concern that if the platform firmware was involved in
the system resume that's being completed,  some devices might have
been reset by it and if those devices had the power.direct_complete
flag set during the preceding suspend transition, they may stay
in a reset-power-on state indefinitely (until they are runtime-resumed
and then suspended again).  That may not be a big deal from the
individual device's perspective, but if the system is an SoC, it may
be prevented from entering deep SoC-wide low-power states on idle
because of that.

The devices that are most likely to be affected by this issue are
PCI devices and ACPI-enumerated devices using the general ACPI PM
domain, so to prevent it from happening for those devices, force a
runtime resume for them if they have their power.direct_complete
flags set and the platform firmware was involved in the resume
transition currently in progress.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

LPSS devices in Braswell does not need the default 10ms
d3_delay imposed by PCI specification. Removing this
unnecessary delay significantly reduces the resume time
approximately upto 200ms on this platform.
Signed-off-by: NSrinidhi Kasagar <srinidhi.kasagar@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Clock provider drivers generally shouldn't include clk.h because
it's the consumer API. Remove the includes here because these are
a provider drivers.

Cc: Ken Xue <Ken.Xue@amd.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Fix a return value (which should be a negative error code) and a
memory leak (the list allocated by acpi_dev_get_resources() needs
to be freed on ioremap() errors too) in acpi_lpss_create_device()
introduced by commit 4483d59e 'ACPI / LPSS: check the result
of ioremap()'.

Fixes: 4483d59e 'ACPI / LPSS: check the result of ioremap()'
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: 4.0+ <stable@vger.kernel.org> # 4.0+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The device descriptors are never written to -- even pointed to as
'const' from struct lpss_private_data. Make them r/o for real.
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 7d78cbef (serial: 8250_dw: add ability to handle
the peripheral clock) introduces handling for a second clk
to 8250_dw.c which is the driver also for LPSS UART. The
second clk forces us to provide identifier (con_id) for the
clkdev we create.

This fixes an issue where 8250_dw.c is getting the same
handler for both clocks.

Fixes: 7d78cbef (serial: 8250_dw: add ability to handle the peripheral clock)
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On some Braswell systems BIOS leaves resets for SPI host controllers
active. This prevents the SPI driver from transferring messages on wire.

Fix this in similar way that we do for I2C already by deasserting resets
for the SPI host controllers.
Reported-by: NYang A Fang <yang.a.fang@intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On Baytrail and Braswell the BIOS might leave the I2C host controllers
enabled, probably because it uses them for its own purposes. This is fine
in normal cases because the I2C driver will disable the hardware when it
is probed anyway.

However, in case of suspend to disk it is different story. If the driver
happens to be compiled as a module the boot kernel never loads the driver
thus leaving host controllers enabled upon loading the hibernation image.

The I2C host controller interrupt mask register has default value of 0x8ff,
in other words it has most of the interrupts unmasked. When combined with
the fact that the host controller is enabled, the driver immediately starts
getting interrupts even before its resume hook is called (once IO-APIC is
resumed). Since the driver is not prepared for this it will crash the
kernel due to NULL pointer derefence because dev->msgs is NULL.

Unfortunately we were not able to get full backtrace to from the console
which could be reproduced here.

In order to fix this even when the driver is compiled as module, we disable
the I2C host controllers in byt_i2c_setup() before devices are created.
Reported-by: NYu Chen <yu.c.chen@intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Revert commit b893e80e ("ACPI / LPSS: Remove non-existing clock control
from Intel Lynxpoint I2C") because it causes touchpad to not load on Dell
XPS13.

Regression is a clear indication that not only some early prototype version
of Lynxpoint I2C but also newer versions can be doing clock gating even
documentation does not state it.

Therefore it is best to revert since this clock gating haven't caused known
issues on those Lynxpoint version which don't do clock gating.
Reported-by-and-tested-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>