lp:~vicamo/+git/ubuntu-kernel

Author: You-Sheng Yang
Author Date: 2019-11-13 09:22:06 UTC

Bug 1852386: Add new CNL PCH ID seen on a CML platform

Author: You-Sheng Yang
Author Date: 2019-11-13 09:22:06 UTC

Bug 1852386: Add new CNL PCH ID seen on a CML platform

Author: You-Sheng Yang
Author Date: 2019-11-13 09:22:06 UTC

Bug 1852386: Add new CNL PCH ID seen on a CML platform

Author: Imre Deak
Author Date: 2019-11-12 10:46:08 UTC

drm/i915: Fix detection for a CMP-V PCH

According to internal documents I found for CMP PCHs the PCI ID 0xA3C1
belongs to a CMP-V chipset. Based on the same docs the programming of
the PCH is compatible with that of KBP. Fix up my previous wrong
assumption accordingly using the SPT programming which in turn is the
basis for KBP.

The original bug reporter verified that this is the correct PCH
identification (the only way we'll program valid DDC pin-pair values to
the GMBUS register) and the Windows team uses the same identification
(that is using the KBP programming model for this PCH).

I filed the necessary Bspec update requests (BSpec/33734).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051
Fixes: 37c92dc303dd ("drm/i915: Add new CNL PCH ID seen on a CML platform")
Reported-and-tested-by: Cyrus <cyrus.lien@canonical.com>
Cc: Cyrus <cyrus.lien@canonical.com>
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

Author: Kai-Heng Feng
Author Date: 2019-11-12 12:59:37 UTC

UBUNTU: SAUCE: x86/intel: Disable HPET on Intel Coffe Lake H platforms

BugLink: https://bugs.launchpad.net/bugs/1852216

Like CFL and ICL, we need to disable HPET on CFL-H.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>

Author: Kai-Heng Feng
Author Date: 2019-11-12 12:59:37 UTC

UBUNTU: SAUCE: x86/intel: Disable HPET on Intel Coffe Lake H platforms

BugLink: https://bugs.launchpad.net/bugs/1852216

Like CFL and ICL, we need to disable HPET on CFL-H.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>

Author: Kai-Heng Feng
Author Date: 2019-11-12 12:59:37 UTC

UBUNTU: SAUCE: x86/intel: Disable HPET on Intel Coffe Lake H platforms

BugLink: https://bugs.launchpad.net/bugs/1852216

Like CFL and ICL, we need to disable HPET on CFL-H.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-11-12 09:36:09 UTC

Bug 1849278: drm/i915: Fix detection for a CMP-V PCH

Author: Imre Deak
Author Date: 2019-11-12 09:26:55 UTC

drm/i915: Fix detection for a CMP-V PCH

Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: You-Sheng Yang <vicamo@gmail.com>

Author: Imre Deak
Author Date: 2019-10-21 11:36:36 UTC

UBUNTU: SAUCE: drm/i915: Add new CNL PCH ID seen on a CML platform

BugLink: http://bugs.launchpad.net/bugs/1849278

On a CML platform a PCH with 0xA3C1 PCI ID, the driver doesn't detect
the PCH type correctly. We don't have the specification of the PCH PCI
ids, so let's assume this is a CNP PCH which has the closest PCI ID.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-11-11 13:36:53 UTC

Bug 1850768: Revert "UBUNTU: SAUCE: drm/i915: Add new CNL PCH ID seen on a CML platform"

Author: Ville Syrjälä
Author Date: 2019-01-08 17:28:26 UTC

drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well

Fill out the AVI infoframe quantization range bits using
drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well.

This changes the behaviour slightly as
drm_hdmi_avi_infoframe_quant_range() will set a non-zero Q bit
even when QS==0 iff the Q bit matched the default quantization
range for the given mode. This matches the recommendation in
HDMI 2.0 and is allowed even before that.

v2: Pimp commit msg (DK)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190108172828.15184-2-ville.syrjala@linux.intel.com
(cherry picked from commit c3735f5c1f9b01e08d0371fe635762f4a7db5d1c)
Signed-off-by: You-Sheng Yang <vicamo@gmail.com>

Author: AceLan Kao
Author Date: 2019-11-07 06:36:44 UTC

UBUNTU: SAUCE: platform/x86: dell-uart-backlight: add quirk for old platforms

BugLink: https://bugs.launchpad.net/bugs/1813877

Old platforms do not support DELL_UART_GET_SCALAR command and the
behavior of DELL_UART_GET_FIRMWARE_VER command is different as the new
firmware, so the new way to check if the backlight is controlled by
scalar IC doesn't work on old platforms. We now add them into a list and
use the old way to do the check.

Signed-off-by: AceLan Kao <acelan.kao@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-11-07 02:25:17 UTC

Bug 1851216: x86/timer: Skip PIT initialization on modern chipsets

Author: You-Sheng Yang
Author Date: 2019-11-07 02:25:17 UTC

Bug 1851216: x86/timer: Skip PIT initialization on modern chipsets

Author: You-Sheng Yang
Author Date: 2019-11-07 02:25:17 UTC

Bug 1851216: x86/timer: Skip PIT initialization on modern chipsets

Author: You-Sheng Yang
Author Date: 2019-11-07 02:25:17 UTC

Bug 1851216: x86/timer: Skip PIT initialization on modern chipsets

Author: You-Sheng Yang
Author Date: 2019-11-05 07:46:17 UTC

Bug 1840239: Disable HPET

Author: You-Sheng Yang
Author Date: 2019-11-05 05:23:13 UTC

Bug 1840239: Disable HPET

Author: Kai-Heng Feng
Author Date: 2019-10-30 14:01:49 UTC

UBUNTU: SAUCE: x86/intel: Disable HPET on Intel Ice Lake platforms

BugLink: https://bugs.launchpad.net/bugs/1840239

Ice Lake platform have similar behavior as Coffee Lake, have skewed HPET
timer once the SoCs entered PC10 so let's disable HPET on Ice Lake.
as result.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
(cherry picked from commit 2638cd5fdb725f11efe4c2023e7524eac4c0c8b1)

Author: You-Sheng Yang
Author Date: 2019-11-04 08:46:32 UTC

Bug 1840239: x86/intel: Disable HPET on Intel Coffe Lake platforms

Bump version

Author: You-Sheng Yang
Author Date: 2019-11-01 09:04:09 UTC

HID: i2c-hid: drop unused struct i2c_hid::sleep_delay

Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-10-30 02:59:23 UTC

Bug-1849453: force alias 8086:06f9 to spt_info

Author: You-Sheng Yang
Author Date: 2019-10-30 02:59:23 UTC

Bug-1849453: force alias 8086:06f9 to spt_uart_info

Author: You-Sheng Yang
Author Date: 2019-10-30 02:59:23 UTC

Bug-1849453: force alias 8086:06f9 to cnl_i2c_info

Author: You-Sheng Yang
Author Date: 2019-10-23 09:23:49 UTC

Bug 1849278: bump version for release

Author: You-Sheng Yang
Author Date: 2019-10-04 13:54:50 UTC

Bug 1846016: iwlwifi: fw: don't send GEO_TX_POWER_LIMIT command to FW version 36, 29

Author: You-Sheng Yang
Author Date: 2019-10-17 08:20:13 UTC

Bug 1813901: x86/intel: Disable HPET on Intel Coffe Lake platforms

Author: You-Sheng Yang
Author Date: 2019-10-17 08:25:43 UTC

Bug 1813901: x86/intel: Disable HPET on Intel Coffe Lake platforms

Author: You-Sheng Yang
Author Date: 2019-10-03 06:34:11 UTC

Revert "HID: i2c-hid: Add a small delay after sleep command for Raydium touchpanel"

Now that a 60ms delay is added after every successful SET_POWER command,
this is no longer necessary.

This reverts commit 00b790ea545b6ef30221adef6e9c3707e03b82b5.

References: https://bugzilla.kernel.org/show_bug.cgi?id=204991
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-10-04 07:08:42 UTC

Bug 1841723: HID: i2c-hid: add 60ms SET_POWER delay for Goodix touchpad

Author: You-Sheng Yang
Author Date: 2019-10-04 07:08:42 UTC

Bug 1841723: HID: i2c-hid: add 60ms SET_POWER delay for Goodix touchpad

Author: You-Sheng Yang
Author Date: 2019-10-03 06:34:11 UTC

Revert "HID: i2c-hid: Add a small delay after sleep command for Raydium touchpanel"

Now that a 60ms delay is added after every successful SET_POWER command,
this is no longer necessary.

This reverts commit 00b790ea545b6ef30221adef6e9c3707e03b82b5.

References: https://bugzilla.kernel.org/show_bug.cgi?id=204991
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-10-03 07:20:40 UTC

Bug 1838951: dell-laptop: add more DMI whitelist

Author: You-Sheng Yang
Author Date: 2019-10-03 07:20:40 UTC

Bug 1838951: dell-laptop: add more DMI whitelist

Author: You-Sheng Yang
Author Date: 2019-09-25 06:56:05 UTC

Bug 1841723: HID: i2c-hid: add 60ms SET_POWER delay for Goodix touchpad

Author: You-Sheng Yang
Author Date: 2019-09-26 11:18:56 UTC

Bug 1844680: thunderbolt for ICL

Author: AceLan Kao
Author Date: 2019-09-26 08:32:49 UTC

mfd: intel-lpss: add quirk for Dell XPS 13 7390 2-in-1

The memory region intel-lpss-pci uses has been declared as
write-combining
[ 0.001728] 5 base 4000000000 mask 6000000000 write-combining
This leads to the system hangs druing booting up.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=203485
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-09-26 07:15:42 UTC

Bug 1844680: thunderbolt on ICL

Author: You-Sheng Yang
Author Date: 2019-09-03 10:02:14 UTC

HID: i2c-hid: add 60ms SET_POWER delay for Goodix touchpad

Goodix touchpad 27C6:01F0 fails to switch to PTP mode when resumed from
suspend. The traffic after resumed looks like:

  [ 275.312190] i2c_hid i2c-DELL096E:00: i2c_hid_set_power
  [ 275.312191] i2c_hid i2c-DELL096E:00: __i2c_hid_command: cmd=05 00 01 08
  [ 283.926905] i2c_hid i2c-DELL096E:00: i2c_hid_set_power
  [ 283.926910] i2c_hid i2c-DELL096E:00: __i2c_hid_command: cmd=05 00 00 08
  [ 283.927146] i2c_hid i2c-DELL096E:00: i2c_hid_set_or_send_report
  [ 283.927149] i2c_hid i2c-DELL096E:00: __i2c_hid_command: cmd=05 00 37 03 06 00 05 00 07 00 00
  [ 283.927872] i2c_hid i2c-DELL096E:00: i2c_hid_set_or_send_report
  [ 283.927874] i2c_hid i2c-DELL096E:00: __i2c_hid_command: cmd=05 00 33 03 06 00 05 00 03 03 00
  [ 283.929148] i2c_hid i2c-DELL096E:00: i2c_hid_set_or_send_report
  [ 283.929151] i2c_hid i2c-DELL096E:00: __i2c_hid_command: cmd=05 00 35 03 06 00 05 00 05 03 00
  [ 289.262675] i2c_hid i2c-DELL096E:00: input: 0b 00 01 00 00 00 00 00 00 00 00
  [ 289.270314] i2c_hid i2c-DELL096E:00: input: 0b 00 01 00 fe 00 00 00 00 00 00
  [ 289.276806] i2c_hid i2c-DELL096E:00: input: 0b 00 01 00 fd 00 00 00 00 00 00
  ...

The time delay between i2c_hid_set_power and i2c_hid_set_or_send_report
is less than vendor recommended 60ms, so it failed to complete its power
state transition, ignored i2c_hid_set_or_send_report and is still
operating in legacy mouse mode, and therefore it gives unsupported input
reports.

This change updates the quirk for the device to specifies a 60ms
post-setpower-delay-ms.

References: https://bugzilla.kernel.org/show_bug.cgi?id=204991
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-09-25 06:56:05 UTC

Bug 1841723: HID: i2c-hid: add 60ms SET_POWER delay for Goodix touchpad

Author: You-Sheng Yang
Author Date: 2019-09-24 09:41:28 UTC

Bug 1844247: Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature"

Author: Sara Sharon
Author Date: 2019-02-07 11:17:37 UTC

iwlwifi: mvm: support HE context cmd API change

Support API change to pass all mbssid parameters to the firmware.

Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
(backported from commit d14ae796f8498933fb4437efe83f7b3423b1793f)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-09-23 10:09:19 UTC

Bug 1843019: WIP

Author: Shaul Triebitz
Author Date: 2019-01-01 08:11:14 UTC

iwlwifi: dbg: temporarily skip periphery dump for AX210 devices

Many periphery addresses have changed in AX210 devices.
Until sorting out which peripheries should be dumped, skip
that step for now.

Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
(cherry picked from commit d4f4793c2d57d3c1f56a79175233e80f896b1853)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-09-17 17:35:41 UTC

debian: bump version

Author: You-Sheng Yang
Author Date: 2019-09-02 09:45:32 UTC

Bug-1841723: disable reset_resume

Author: Luca Coelho
Author Date: 2019-08-19 08:59:23 UTC

iwlwifi: pcie: handle switching killer Qu B0 NICs to C0

We need to use a different firmware for C0 versions of killer Qu NICs.
Add structures for them and handle them in the if block that detects
C0 revisions.

Additionally, instead of having an inclusive check for QnJ devices,
make the selection exclusive, so that switching to QnJ is the
exception, not the default. This prevents us from having to add all
the non-QnJ cards to an exclusion list. To do so, only go into the
QnJ block if the device has an RF ID type HR and HW revision QnJ.

Cc: stable@vger.kernel.org # 5.2
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
(backported from commit 9ca397b3a7c33fe84e8059562052d56f90717897
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: Luca Coelho
Author Date: 2019-07-08 15:55:34 UTC

iwlwifi: pcie: add support for qu c-step devices

Add support for C-step devices. Currently we don't have a nice way of
matching the step and choosing the proper configuration, so we need to
switch the config structs one by one.

Cc: stable@vger.kernel.org
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit a7d544d63120061f89459585f06ca44d30842a22)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: Luca Coelho
Author Date: 2019-08-19 08:59:23 UTC

iwlwifi: pcie: handle switching killer Qu B0 NICs to C0

We need to use a different firmware for C0 versions of killer Qu NICs.
Add structures for them and handle them in the if block that detects
C0 revisions.

Additionally, instead of having an inclusive check for QnJ devices,
make the selection exclusive, so that switching to QnJ is the
exception, not the default. This prevents us from having to add all
the non-QnJ cards to an exclusion list. To do so, only go into the
QnJ block if the device has an RF ID type HR and HW revision QnJ.

Cc: stable@vger.kernel.org # 5.2
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
(cherry picked from commit 9ca397b3a7c33fe84e8059562052d56f90717897)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-08-26 04:02:12 UTC

UBUNTU: SAUCE: drm/i915/fbc: disable framebuffer compression on IceLake

This is the same thing to commit
edf87a92e112ede83916155a156e41787ea11186 but found on IceLake platforms
as well.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111484
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-08-26 04:02:12 UTC

UBUNTU: SAUCE: drm/i915/fbc: disable framebuffer compression on IceLake

This is the same thing to commit
edf87a92e112ede83916155a156e41787ea11186 but found on IceLake platforms
as well.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111484
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-08-26 04:02:12 UTC

UBUNTU: SAUCE: drm/i915/fbc: disable framebuffer compression on IceLake

This is the same thing to commit
edf87a92e112ede83916155a156e41787ea11186 but found on IceLake platforms
as well.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111484
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-08-26 04:02:12 UTC

UBUNTU: SAUCE: drm/i915/fbc: disable framebuffer compression on IceLake

This is the same thing to commit
edf87a92e112ede83916155a156e41787ea11186 but found on IceLake platforms
as well.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111484
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-08-26 04:02:12 UTC

UBUNTU: SAUCE: drm/i915/fbc: disable framebuffer compression on IceLake

This is the same thing to commit
edf87a92e112ede83916155a156e41787ea11186 but found on IceLake platforms
as well.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111484
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-08-26 04:02:12 UTC

drm/i915/fbc: disable framebuffer compression on IceLake

This is the same thing to commit
edf87a92e112ede83916155a156e41787ea11186 but found on IceLake platforms
as well.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111484
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-08-23 09:51:44 UTC

changes from matt's killer.patch

Author: You-Sheng Yang
Author Date: 2019-08-19 07:20:59 UTC

debian: bump version

Author: You-Sheng Yang
Author Date: 2019-08-15 08:14:30 UTC

drm/i915/fbc: disable framebuffer compression on IceLake

This is a follow-up to commit 396dd8143bdd94bd1c358a228a631c8c895a1126
as the same sympton can also be found on IceLake platforms we're working
on.

BugLink: https://bugs.launchpad.net/bugs/1840236
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-08-14 07:45:12 UTC

debian: bump version

Author: You-Sheng Yang
Author Date: 2019-08-14 07:45:12 UTC

debian: bump version

Author: You-Sheng Yang
Author Date: 2019-08-14 07:45:12 UTC

debian: bump version

Author: You-Sheng Yang
Author Date: 2019-07-30 05:52:04 UTC

bug-1817019: add debug messages

Author: José Roberto de Souza
Author Date: 2019-07-12 00:53:43 UTC

drm/i915: Enable hotplug retry

BugLink: http://bugs.launchpad.net/bugs/1835001

Right now we are aware of two cases that needs another hotplug retry:
- Unpowered type-c dongles
- HDMI slow unplug

Both have a complete explanation in the code to schedule another run
of the hotplug handler.

It could have more checks to just trigger the retry in those two
specific cases but why would sink signal a long pulse if there is
no change? Also the drawback of running the hotplug handler again
is really low and that could fix another cases that we are not
aware.

Also retrying for old DP ports(non-DDI) to make it consistent and not
cause CI failures if those systems are connected to chamelium boards
that will be used to simulate the issues reported in here.

v2: Also retrying for old DP ports(non-DDI)(Imre)

v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep
it consistent(Rodrigo)

Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190712005343.24571-2-jose.souza@intel.com
(backported from commit bb80c9255770fa1ed54e889a6bee628bdd0f6762
git://anongit.freedesktop.org/drm-intel)
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
(cherry picked from commit 755a3b0ec1f61481949b04151b09fabc3f96c320)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: José Roberto de Souza
Author Date: 2019-07-12 00:53:43 UTC

drm/i915: Enable hotplug retry

BugLink: http://bugs.launchpad.net/bugs/1835001

Right now we are aware of two cases that needs another hotplug retry:
- Unpowered type-c dongles
- HDMI slow unplug

Both have a complete explanation in the code to schedule another run
of the hotplug handler.

It could have more checks to just trigger the retry in those two
specific cases but why would sink signal a long pulse if there is
no change? Also the drawback of running the hotplug handler again
is really low and that could fix another cases that we are not
aware.

Also retrying for old DP ports(non-DDI) to make it consistent and not
cause CI failures if those systems are connected to chamelium boards
that will be used to simulate the issues reported in here.

v2: Also retrying for old DP ports(non-DDI)(Imre)

v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep
it consistent(Rodrigo)

Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190712005343.24571-2-jose.souza@intel.com
(backported from commit bb80c9255770fa1ed54e889a6bee628bdd0f6762
git://anongit.freedesktop.org/drm-intel)
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
(cherry picked from commit 755a3b0ec1f61481949b04151b09fabc3f96c320)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: José Roberto de Souza
Author Date: 2019-07-12 00:53:43 UTC

drm/i915: Enable hotplug retry

BugLink: http://bugs.launchpad.net/bugs/1835001

Right now we are aware of two cases that needs another hotplug retry:
- Unpowered type-c dongles
- HDMI slow unplug

Both have a complete explanation in the code to schedule another run
of the hotplug handler.

It could have more checks to just trigger the retry in those two
specific cases but why would sink signal a long pulse if there is
no change? Also the drawback of running the hotplug handler again
is really low and that could fix another cases that we are not
aware.

Also retrying for old DP ports(non-DDI) to make it consistent and not
cause CI failures if those systems are connected to chamelium boards
that will be used to simulate the issues reported in here.

v2: Also retrying for old DP ports(non-DDI)(Imre)

v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep
it consistent(Rodrigo)

Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190712005343.24571-2-jose.souza@intel.com
(backported from commit bb80c9255770fa1ed54e889a6bee628bdd0f6762
git://anongit.freedesktop.org/drm-intel)
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
(cherry picked from commit 755a3b0ec1f61481949b04151b09fabc3f96c320)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: José Roberto de Souza
Author Date: 2019-07-12 00:53:43 UTC

drm/i915: Enable hotplug retry

BugLink: http://bugs.launchpad.net/bugs/1835001

Right now we are aware of two cases that needs another hotplug retry:
- Unpowered type-c dongles
- HDMI slow unplug

Both have a complete explanation in the code to schedule another run
of the hotplug handler.

It could have more checks to just trigger the retry in those two
specific cases but why would sink signal a long pulse if there is
no change? Also the drawback of running the hotplug handler again
is really low and that could fix another cases that we are not
aware.

Also retrying for old DP ports(non-DDI) to make it consistent and not
cause CI failures if those systems are connected to chamelium boards
that will be used to simulate the issues reported in here.

v2: Also retrying for old DP ports(non-DDI)(Imre)

v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep
it consistent(Rodrigo)

Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190712005343.24571-2-jose.souza@intel.com
(backported from commit bb80c9255770fa1ed54e889a6bee628bdd0f6762
git://anongit.freedesktop.org/drm-intel)
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
(cherry picked from commit 755a3b0ec1f61481949b04151b09fabc3f96c320)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: José Roberto de Souza
Author Date: 2019-07-12 00:53:43 UTC

drm/i915: Enable hotplug retry

BugLink: http://bugs.launchpad.net/bugs/1835001

Right now we are aware of two cases that needs another hotplug retry:
- Unpowered type-c dongles
- HDMI slow unplug

Both have a complete explanation in the code to schedule another run
of the hotplug handler.

It could have more checks to just trigger the retry in those two
specific cases but why would sink signal a long pulse if there is
no change? Also the drawback of running the hotplug handler again
is really low and that could fix another cases that we are not
aware.

Also retrying for old DP ports(non-DDI) to make it consistent and not
cause CI failures if those systems are connected to chamelium boards
that will be used to simulate the issues reported in here.

v2: Also retrying for old DP ports(non-DDI)(Imre)

v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep
it consistent(Rodrigo)

Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190712005343.24571-2-jose.souza@intel.com
(backported from commit bb80c9255770fa1ed54e889a6bee628bdd0f6762
git://anongit.freedesktop.org/drm-intel)
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
(cherry picked from commit 755a3b0ec1f61481949b04151b09fabc3f96c320)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-07-16 08:31:13 UTC

bug 1833208: bump version

Author: You-Sheng Yang
Author Date: 2019-07-10 08:27:58 UTC

bug 1835684: print mei_me D0i3 support status

Author: Luca Coelho
Author Date: 2019-07-08 10:22:17 UTC

[BUGFIX] iwlwifi: pcie: add support for qu c-step devices

Add support for C-step devices. Currently we don't have a nice way of
matching the step and choosing the proper configuration, so we need to
switch the config structs one by one.

type=bugfix
fixes=unknown
ticket=jira:WIFI-28439

Change-Id: I1cc154698d48417da174ed8636792b40159e603a
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-on: https://git-amr-3.devtools.intel.com/gerrit/228329
automatic-review: ec ger unix iil jenkins <EC.GER.UNIX.IIL.JENKINS@INTEL.COM>
Tested-by: ec ger unix iil jenkins <EC.GER.UNIX.IIL.JENKINS@INTEL.COM>
x-iwlwifi-stack-dev: 7773a7575ddbc894dc5c7cc804211cc8fb8c905b
(backported from commit a337b99b77170ee97fee11c98f8448e3ebf445e9)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-07-03 10:46:29 UTC

temp

Author: Luca Coelho
Author Date: 2019-05-17 12:07:42 UTC

[BUGFIX] iwlwifi: mvm: don't use iwl_geo_tx_power_profiles_cmd_v1

We don't need to allocate a new structure and copy the data from the
new one into it, because they are the same, except that the new
version has one more element at the end. We can simply send the same
structure but pass the size of the old one when we send the command.

This avoid extra stack allocations and a memcpy in the code. The
memcpy() was causing a static analyzer warning because it was not
using the size of the destination.

type=bugfix
ticket=none
fixes=I52d2afa9f243765b63da3279496c524c77b26e20

Change-Id: Iaaeba37a842ba6abc9e53c7f018f5362964a6daf
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-on: https://git-amr-3.devtools.intel.com/gerrit/222716
Tested-by: ec ger unix iil jenkins <EC.GER.UNIX.IIL.JENKINS@INTEL.COM>
x-iwlwifi-stack-dev: 023605ffda133e4cea2fe29c2ec7dbcbe48988c4
(backported from commit 33693c2f3ae9eafcfd69d2c2977dcc8cbaf199fc)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-06-24 11:00:45 UTC

update debian/changelog

Author: You-Sheng Yang
Author Date: 2019-06-24 11:00:45 UTC

update debian/changelog

Author: Luca Coelho
Author Date: 2019-06-19 12:08:30 UTC

[BUGFIX] iwlwifi: don't use qnj config for quz hr

BugLink: https://bugs.launchpad.net/bugs/1833065

We were mistakenly changing the cfg from iwl_ax201_cfg_quz_hr to
iwl22000_2ax_cfg_qnj_hr_b0, but that's incorrect. Add a check not to
do so.

type=bugfix
fixes=I23f132db4d7820fdee9c489c784bc32960146c1a
ticket=jira:WIFI-27408

Change-Id: I104beb970abeb5b5f9fab00fbc79f69f6b25224a
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-on: https://git-amr-3.devtools.intel.com/gerrit/226474
Tested-by: ec ger unix iil jenkins <EC.GER.UNIX.IIL.JENKINS@INTEL.COM>
Reviewed-by: Shaish, Dor <dor.shaish@intel.com>
Reviewed-by: Golant, Michael <michael.golant@intel.com>
Tested-by: Golant, Michael <michael.golant@intel.com>
(cherry picked from commit da5980193d0ec6468ee51119bd52b8ed637f09ed)
Reviewed-on: https://git-amr-3.devtools.intel.com/gerrit/226520
x-iwlwifi-stack-dev: 31c386578add6a8936dfa53792b57bdb5cc43a2d
(backported from commit d99b9d3ceacc714068384fd2a198b827fe2c96e6 from backport-iwlwifi)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-06-24 11:00:45 UTC

temp

Author: Ihab Zhaika
Author Date: 2019-06-14 08:48:51 UTC

iwlwifi: change 0x02F0 fw from qu to quz

BugLink: https://bugs.launchpad.net/bugs/1833065

change the fw of 0x02F0 platform from qu to quz

Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
(backported from commit 62d28a2a053b19f7b8560e1d872bd3b321148fe9 from backport-iwlwifi)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: Ihab Zhaika
Author Date: 2019-06-14 08:48:51 UTC

iwlwifi: change 0x02F0 fw from qu to quz

change the fw of 0x02F0 platform from qu to quz

Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

Author: You-Sheng Yang
Author Date: 2019-06-11 10:24:03 UTC

Bug 1826521: assume HID_QUIRK_NO_INIT_REPORTS

Author: You-Sheng Yang
Author Date: 2019-06-11 10:24:03 UTC

Bug 1826521: assume HID_QUIRK_NO_INIT_REPORTS

Author: You-Sheng Yang
Author Date: 2019-06-12 06:12:54 UTC

Bug 1829125: cooper: disable drm mode adjustion

Author: You-Sheng Yang
Author Date: 2019-06-05 09:59:27 UTC

bug 1826521: more trace

Author: You-Sheng Yang
Author Date: 2019-06-10 06:38:34 UTC

Bug 1826521: ignore DW_IC_INTR_TX_ABRT

Author: You-Sheng Yang
Author Date: 2019-06-10 06:38:34 UTC

Bug 1826521: ignore DW_IC_INTR_TX_ABRT

Author: You-Sheng Yang
Author Date: 2019-06-10 02:57:02 UTC

Bug 1826521: disable I2C designware support completely

Author: You-Sheng Yang
Author Date: 2019-06-05 09:59:27 UTC

bug 1826521: build i2c-designware as module

Author: Rajat Jain
Author Date: 2019-01-28 23:08:09 UTC

Bluetooth: btusb: btusb_intel_cmd_timeout: use sleeping functions

The btusb_intel_cmd_timeout() is called from workqueue contexts,
so use the helper functions that can sleep.

Signed-off-by: Rajat Jain <rajatja@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
(cherry picked from commit 2de66bb87351086ce9bef37c1b98d9bae93eddcd)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-05-17 03:45:04 UTC

btintel: display hw version info

Author: Harry Pan
Author Date: 2019-05-16 09:06:51 UTC

clocksource: Untrust the clocksource watchdog when its interval is too small

This patch performs a sanity check on the deviation of the clocksource watchdog,
target to reduce false alarm that incorrectly marks current clocksource unstable
when there comes discrepancy.

Say if there is a discrepancy between the current clocksource and watchdog,
validate the watchdog deviation first, if its interval is too small against
the expected timer interval, we shall trust the current clocksource.

It is identified on some Coffee Lake platform w/ PC10 allowed, when the CPU
entered and exited from PC10 (the residency counter is increased), the HPET
generates timestamp delay, this causes discrepancy making kernel incorrectly
untrust the current clocksource (TSC in this case) and re-select the next
clocksource which is the problematic HPET, this eventually causes a user
sensible wall clock delay.

The HPET timestamp delay shall be tackled in firmware domain in order to
properly handle the timer offload between XTAL and RTC when it enters PC10,
while this patch is a mitigation to reduce the false alarm of clocksource
unstable regardless what clocksources are paired.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=203183
Signed-off-by: Harry Pan <harry.pan@intel.com>

Author: You-Sheng Yang
Author Date: 2019-05-13 09:20:24 UTC

bug 1826521: test i2c-designware params from Windows

Author: You-Sheng Yang
Author Date: 2019-05-13 09:20:24 UTC

bug 1826521: test i2c-designware params from Windows

Author: Christian König
Author Date: 2019-04-23 09:50:40 UTC

PCI: Restore resized BAR state on resume

BugLink: https://bugs.launchpad.net/bugs/1825958

Resize BARs after resume to the expected size again.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199959
Fixes: d6895ad39f3b ("drm/amdgpu: resize VRAM BAR for CPU access v6")
Fixes: 276b738deb5b ("PCI: Add resizable BAR infrastructure")
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v4.15+
(cherry picked from commit d3252ace0bc652a1a244455556b6a549f969bf99)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>
Acked-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>

Author: Christian König
Author Date: 2019-04-23 09:50:40 UTC

PCI: Restore resized BAR state on resume

BugLink: https://bugs.launchpad.net/bugs/1825958

Resize BARs after resume to the expected size again.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199959
Fixes: d6895ad39f3b ("drm/amdgpu: resize VRAM BAR for CPU access v6")
Fixes: 276b738deb5b ("PCI: Add resizable BAR infrastructure")
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v4.15+
(cherry picked from commit d3252ace0bc652a1a244455556b6a549f969bf99)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>
Acked-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>

Author: Christian König
Author Date: 2019-04-23 09:50:40 UTC

PCI: Restore resized BAR state on resume

BugLink: https://bugs.launchpad.net/bugs/1825958

Resize BARs after resume to the expected size again.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199959
Fixes: d6895ad39f3b ("drm/amdgpu: resize VRAM BAR for CPU access v6")
Fixes: 276b738deb5b ("PCI: Add resizable BAR infrastructure")
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v4.15+
(cherry picked from commit d3252ace0bc652a1a244455556b6a549f969bf99)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>
Acked-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-04-29 10:10:21 UTC

Bug 1826521: enable I2C core/bus debug

Author: Timo Aaltonen
Author Date: 2019-03-14 12:05:23 UTC

UBUNTU: iwlwifi: Fix build after rebase.

Ignore: yes
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>

Author: You-Sheng Yang
Author Date: 2019-04-29 05:21:58 UTC

fix module check

Author: Christian König
Author Date: 2018-06-30 00:54:55 UTC

PCI: Restore resized BAR state on resume

Resize BARs after resume to the expected size again.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199959
Fixes: d6895ad39f3b ("drm/amdgpu: resize VRAM BAR for CPU access v6")
Fixes: 276b738deb5b ("PCI: Add resizable BAR infrastructure")
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v4.15+
(cherry picked from commit d3252ace0bc652a1a244455556b6a549f969bf99)
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>

Author: Rafael J. Wysocki
Author Date: 2019-04-18 14:11:37 UTC

x86: tsc: Rework time_cpufreq_notifier()

There are problems with running time_cpufreq_notifier() on SMP
systems.

First off, the rdtsc() called from there runs on the CPU executing
that code and not necessarily on the CPU whose sched_clock() rate is
updated which is questionable at best.

Second, in the cases when the frequencies of all CPUs in an SMP
system are always in sync, it is not sufficient to update just
one of them or the set associated with a given cpufreq policy on
frequency changes - all CPUs in the system should be updated and
that would require more than a simple transition notifier.

Note, however, that the underlying issue (the TSC rate depending on
the CPU frequency) has not been present in hardware shipping for the
last few years and in quite a few relevant cases (acpi-cpufreq in
particular) running time_cpufreq_notifier() will cause the TSC to
be marked as unstable anyway.

For this reason, make time_cpufreq_notifier() simply mark the TSC
as unstable and give up when run on SMP and only try to carry out
any adjustments otherwise.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>