From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omzsmtpe01.verizonbusiness.com ([199.249.25.210]:39332 "EHLO omzsmtpe01.verizonbusiness.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754235AbdDDTdP (ORCPT ); Tue, 4 Apr 2017 15:33:15 -0400 From: alexander.levin@verizon.com To: "gregkh@linuxfoundation.org" CC: "stable@vger.kernel.org" Subject: [PATCH for 4.9 46/98] drm/i915: actually drive the BDW reserved IDs Date: Tue, 4 Apr 2017 19:32:19 +0000 Message-ID: <20170404193158.19041-47-alexander.levin@verizon.com> References: <20170404193158.19041-1-alexander.levin@verizon.com> In-Reply-To: <20170404193158.19041-1-alexander.levin@verizon.com> Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org List-ID: From: Paulo Zanoni [ Upstream commit 98b2f01c8dfc8922a2af1fe82a1c40cac4911634 ] Back in 2014, commit fb7023e0e248 ("drm/i915: BDW: Adding Reserved PCI IDs.") added the reserved PCI IDs in order to try to make sure we had working drivers in case we ever released products using these IDs (since we had instances of this type of problem in the past). The problem is that the patch only touched the macros used by early-quirks.c and by the user space components that rely on i915_pciids.h, it didn't touch the macros used by i915_pci.c. So we correctly handled the stolen memory for these theoretical IDs, but we didn't actually drive the devices from i915.ko. So this patch fixes the original commit by actually making i915.ko drive these IDs, which was the goal. There's no information on what would be the GT count on these IDs, so we just go with the safer intel_broadwell_info, at the risk of ignoring a possibly inexistent BSD2_RING. I did some checking, and it seems that these IDs are driven by intel-gpu-tools, xf86-video-intel and libdrm (since they contain old copies of i915_pciids.h), but they are not checked by mesa. The alternative to this patch would be to just assume we're actually never going to use these IDs, and then remove them from our ID lists and make sure our user space components sync the latest i915_pciids.h copy. I'm fine with either approaches, as long as we make sure that every component tries to drive the same list of PCI IDs. Fixes: fb7023e0e248 ("drm/i915: BDW: Adding Reserved PCI IDs.") Cc: Rodrigo Vivi Cc: Ben Widawsky Cc: Jani Nikula Signed-off-by: Paulo Zanoni Reviewed-by: Rodrigo Vivi Link: http://patchwork.freedesktop.org/patch/msgid/1483473860-17644-3-git-s= end-email-paulo.r.zanoni@intel.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/i915/i915_pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pc= i.c index 31e6edd..9e94886 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -417,6 +417,7 @@ static const struct pci_device_id pciidlist[] =3D { INTEL_VLV_IDS(&intel_valleyview_info), INTEL_BDW_GT12_IDS(&intel_broadwell_info), INTEL_BDW_GT3_IDS(&intel_broadwell_gt3_info), + INTEL_BDW_RSVD_IDS(&intel_broadwell_info), INTEL_CHV_IDS(&intel_cherryview_info), INTEL_SKL_GT1_IDS(&intel_skylake_info), INTEL_SKL_GT2_IDS(&intel_skylake_info), --=20 2.9.3