--- /dev/null
+From cb4b02d7cac56a69d8137d8d843507cca9182aed Mon Sep 17 00:00:00 2001
+From: Leo Liu <leo.liu@amd.com>
+Date: Tue, 31 Oct 2017 21:03:39 -0400
+Subject: drm/amdgpu: return -ENOENT from uvd 6.0 early init for harvesting
+
+From: Leo Liu <leo.liu@amd.com>
+
+commit cb4b02d7cac56a69d8137d8d843507cca9182aed upstream.
+
+Fixes init failures on polaris cards with harvested UVD.
+
+Signed-off-by: Leo Liu <leo.liu@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
+@@ -89,6 +89,10 @@ static int uvd_v6_0_early_init(void *han
+ {
+ struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
++ if (!(adev->flags & AMD_IS_APU) &&
++ (RREG32_SMC(ixCC_HARVEST_FUSES) & CC_HARVEST_FUSES__UVD_DISABLE_MASK))
++ return -ENOENT;
++
+ uvd_v6_0_set_ring_funcs(adev);
+ uvd_v6_0_set_irq_funcs(adev);
+
--- /dev/null
+From 7c838e2a9be5ab79b11c7f1520813bfdf0f45462 Mon Sep 17 00:00:00 2001
+From: Jani Nikula <jani.nikula@intel.com>
+Date: Thu, 26 Oct 2017 17:29:31 +0300
+Subject: drm/i915/edp: read edp display control registers unconditionally
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jani Nikula <jani.nikula@intel.com>
+
+commit 7c838e2a9be5ab79b11c7f1520813bfdf0f45462 upstream.
+
+Per my reading of the eDP spec, DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in
+DP_EDP_CONFIGURATION_CAP should be set if the eDP display control
+registers starting at offset DP_EDP_DPCD_REV are "enabled". Currently we
+check the bit before reading the registers, and DP_EDP_DPCD_REV is the
+only way to detect eDP revision.
+
+Turns out there are (likely buggy) displays that require eDP 1.4+
+features, such as supported link rates and link rate select, but do not
+have the bit set. Read the display control registers
+unconditionally. They are supposed to read zero anyway if they are not
+supported, so there should be no harm in this.
+
+This fixes the referenced bug by enabling the eDP version check, and
+thus reading of the supported link rates. The panel in question has 0 in
+DP_MAX_LINK_RATE which is only supported in eDP 1.4+. Without the
+supported link rates method we default to RBR which is insufficient for
+the panel native mode. As a curiosity, the panel also has a bogus value
+of 0x12 in DP_EDP_DPCD_REV, but that passes our check for >= DP_EDP_14
+(which is 0x03).
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103400
+Reported-and-tested-by: Nicolas P. <issun.artiste@gmail.com>
+Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20171026142932.17737-1-jani.nikula@intel.com
+(cherry picked from commit 0501a3b0eb01ac2209ef6fce76153e5d6b07034e)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_dp.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_dp.c
++++ b/drivers/gpu/drm/i915/intel_dp.c
+@@ -3558,9 +3558,16 @@ intel_edp_init_dpcd(struct intel_dp *int
+ dev_priv->psr.psr2_support ? "supported" : "not supported");
+ }
+
+- /* Read the eDP Display control capabilities registers */
+- if ((intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
+- drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV,
++ /*
++ * Read the eDP display control registers.
++ *
++ * Do this independent of DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in
++ * DP_EDP_CONFIGURATION_CAP, because some buggy displays do not have it
++ * set, but require eDP 1.4+ detection (e.g. for supported link rates
++ * method). The display control registers should read zero if they're
++ * not supported anyway.
++ */
++ if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV,
+ intel_dp->edp_dpcd, sizeof(intel_dp->edp_dpcd)) ==
+ sizeof(intel_dp->edp_dpcd))
+ DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int) sizeof(intel_dp->edp_dpcd),
--- /dev/null
+From 105ddc93f06ebe3e553f58563d11ed63dbcd59f0 Mon Sep 17 00:00:00 2001
+From: Ashish Samant <ashish.samant@oracle.com>
+Date: Thu, 2 Nov 2017 15:59:37 -0700
+Subject: ocfs2: fstrim: Fix start offset of first cluster group during fstrim
+
+From: Ashish Samant <ashish.samant@oracle.com>
+
+commit 105ddc93f06ebe3e553f58563d11ed63dbcd59f0 upstream.
+
+The first cluster group descriptor is not stored at the start of the
+group but at an offset from the start. We need to take this into
+account while doing fstrim on the first cluster group. Otherwise we
+will wrongly start fstrim a few blocks after the desired start block and
+the range can cross over into the next cluster group and zero out the
+group descriptor there. This can cause filesytem corruption that cannot
+be fixed by fsck.
+
+Link: http://lkml.kernel.org/r/1507835579-7308-1-git-send-email-ashish.samant@oracle.com
+Signed-off-by: Ashish Samant <ashish.samant@oracle.com>
+Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
+Reviewed-by: Joseph Qi <jiangqi903@gmail.com>
+Cc: Mark Fasheh <mfasheh@versity.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ocfs2/alloc.c | 24 ++++++++++++++++++------
+ 1 file changed, 18 insertions(+), 6 deletions(-)
+
+--- a/fs/ocfs2/alloc.c
++++ b/fs/ocfs2/alloc.c
+@@ -7310,13 +7310,24 @@ out:
+
+ static int ocfs2_trim_extent(struct super_block *sb,
+ struct ocfs2_group_desc *gd,
+- u32 start, u32 count)
++ u64 group, u32 start, u32 count)
+ {
+ u64 discard, bcount;
++ struct ocfs2_super *osb = OCFS2_SB(sb);
+
+ bcount = ocfs2_clusters_to_blocks(sb, count);
+- discard = le64_to_cpu(gd->bg_blkno) +
+- ocfs2_clusters_to_blocks(sb, start);
++ discard = ocfs2_clusters_to_blocks(sb, start);
++
++ /*
++ * For the first cluster group, the gd->bg_blkno is not at the start
++ * of the group, but at an offset from the start. If we add it while
++ * calculating discard for first group, we will wrongly start fstrim a
++ * few blocks after the desried start block and the range can cross
++ * over into the next cluster group. So, add it only if this is not
++ * the first cluster group.
++ */
++ if (group != osb->first_cluster_group_blkno)
++ discard += le64_to_cpu(gd->bg_blkno);
+
+ trace_ocfs2_trim_extent(sb, (unsigned long long)discard, bcount);
+
+@@ -7324,7 +7335,7 @@ static int ocfs2_trim_extent(struct supe
+ }
+
+ static int ocfs2_trim_group(struct super_block *sb,
+- struct ocfs2_group_desc *gd,
++ struct ocfs2_group_desc *gd, u64 group,
+ u32 start, u32 max, u32 minbits)
+ {
+ int ret = 0, count = 0, next;
+@@ -7343,7 +7354,7 @@ static int ocfs2_trim_group(struct super
+ next = ocfs2_find_next_bit(bitmap, max, start);
+
+ if ((next - start) >= minbits) {
+- ret = ocfs2_trim_extent(sb, gd,
++ ret = ocfs2_trim_extent(sb, gd, group,
+ start, next - start);
+ if (ret < 0) {
+ mlog_errno(ret);
+@@ -7441,7 +7452,8 @@ int ocfs2_trim_fs(struct super_block *sb
+ }
+
+ gd = (struct ocfs2_group_desc *)gd_bh->b_data;
+- cnt = ocfs2_trim_group(sb, gd, first_bit, last_bit, minlen);
++ cnt = ocfs2_trim_group(sb, gd, group,
++ first_bit, last_bit, minlen);
+ brelse(gd_bh);
+ gd_bh = NULL;
+ if (cnt < 0) {
arm-arm64-kvm-set-right-lr-register-value-for-32-bit-guest-when-inject-abort.patch
arm-arm64-kvm-disable-branch-profiling-in-hyp-code.patch
arm-8715-1-add-a-private-asm-unaligned.h.patch
+drm-amdgpu-return-enoent-from-uvd-6.0-early-init-for-harvesting.patch
+ocfs2-fstrim-fix-start-offset-of-first-cluster-group-during-fstrim.patch
+drm-i915-edp-read-edp-display-control-registers-unconditionally.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
