| Message ID | CAKhsbWaeMMFtSWUxamvVNS5_74K80TmwYECUmc1xmy6pReyKVQ@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 19 Dec 2012 00:49:28 +0800 "G.R." <firemeteor@users.sourceforge.net> wrote: > Hi guys, > > In XEN HVM guest, there is always an emulated PIIX3 ISA bridge on slot 01.0. > This shadows the PCH ISA bridge on 1f.0 with the current > intel_detect_pch() implementation. > The issue can be easily solved by looping through all the ISA bridges > until the first match is found, instead of just check against the > first one. > > Here I attach the patch I used locally. It's created on Torvalds's git. > Looking forward to your comments. > > Thanks, > Timothy > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 530db83..3f7e5fb 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -408,9 +408,11 @@ void intel_detect_pch(struct drm_device *dev) > * underneath. This is a requirement from virtualization team. > */ > pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, NULL); > - if (pch) { > + while (pch) { > + struct pci_dev * curr = pch; > if (pch->vendor == PCI_VENDOR_ID_INTEL) { > unsigned short id; > + unsigned found = 1; > id = pch->device & INTEL_PCH_DEVICE_ID_MASK; > dev_priv->pch_id = id; > > @@ -440,10 +442,20 @@ void intel_detect_pch(struct drm_device *dev) > dev_priv->num_pch_pll = 0; > DRM_DEBUG_KMS("Found LynxPoint LP PCH\n"); > WARN_ON(!IS_HASWELL(dev)); > + } else { > + found = 0; > + } > + if (found) { > + BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); > + pci_dev_put(pch); > + break; > } > - BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); > } > - pci_dev_put(pch); > + pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, curr); > + pci_dev_put(curr); > + } > + if (!pch) { > + DRM_DEBUG_KMS("No PCH found?\n"); > } > } > I'd like to see a comment about this being for Xen in here, and I wonder if there are other places where we might have to worry about the Xen implementation. In that case, setting a flag in dev_priv when we don't find the PCH where we expect would be a good idea too. Ack on the general idea though; I'd like us to be able to run under Xen without modification. Jesse
On Wed, 19 Dec 2012 00:49:28 +0800 "G.R." <firemeteor@users.sourceforge.net> wrote: > Hi guys, > > In XEN HVM guest, there is always an emulated PIIX3 ISA bridge on slot 01.0. > This shadows the PCH ISA bridge on 1f.0 with the current > intel_detect_pch() implementation. > The issue can be easily solved by looping through all the ISA bridges > until the first match is found, instead of just check against the > first one. > > Here I attach the patch I used locally. It's created on Torvalds's git. > Looking forward to your comments. > > Thanks, > Timothy Is this functionally equivalent to http://lists.freedesktop.org/archives/intel-gfx/2012-July/019126.html? > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 530db83..3f7e5fb 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -408,9 +408,11 @@ void intel_detect_pch(struct drm_device *dev) > * underneath. This is a requirement from virtualization team. > */ > pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, NULL); > - if (pch) { > + while (pch) { > + struct pci_dev * curr = pch; > if (pch->vendor == PCI_VENDOR_ID_INTEL) { > unsigned short id; > + unsigned found = 1; > id = pch->device & INTEL_PCH_DEVICE_ID_MASK; > dev_priv->pch_id = id; > > @@ -440,10 +442,20 @@ void intel_detect_pch(struct drm_device *dev) > dev_priv->num_pch_pll = 0; > DRM_DEBUG_KMS("Found LynxPoint LP PCH\n"); > WARN_ON(!IS_HASWELL(dev)); > + } else { > + found = 0; > + } > + if (found) { > + BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); > + pci_dev_put(pch); > + break; > } > - BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); > } > - pci_dev_put(pch); > + pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, curr); > + pci_dev_put(curr); > + } > + if (!pch) { > + DRM_DEBUG_KMS("No PCH found?\n"); > } > } > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Dec 19, 2012 at 12:53 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > On Wed, 19 Dec 2012 00:49:28 +0800 > "G.R." <firemeteor@users.sourceforge.net> wrote: > >> Hi guys, >> >> In XEN HVM guest, there is always an emulated PIIX3 ISA bridge on slot 01.0. >> This shadows the PCH ISA bridge on 1f.0 with the current >> intel_detect_pch() implementation. >> The issue can be easily solved by looping through all the ISA bridges >> until the first match is found, instead of just check against the >> first one. >> >> Here I attach the patch I used locally. It's created on Torvalds's git. >> Looking forward to your comments. >> >> Thanks, >> Timothy >> >> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c >> index 530db83..3f7e5fb 100644 >> --- a/drivers/gpu/drm/i915/i915_drv.c >> +++ b/drivers/gpu/drm/i915/i915_drv.c >> @@ -408,9 +408,11 @@ void intel_detect_pch(struct drm_device *dev) >> * underneath. This is a requirement from virtualization team. >> */ >> pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, NULL); >> - if (pch) { >> + while (pch) { >> + struct pci_dev * curr = pch; >> if (pch->vendor == PCI_VENDOR_ID_INTEL) { >> unsigned short id; >> + unsigned found = 1; >> id = pch->device & INTEL_PCH_DEVICE_ID_MASK; >> dev_priv->pch_id = id; >> >> @@ -440,10 +442,20 @@ void intel_detect_pch(struct drm_device *dev) >> dev_priv->num_pch_pll = 0; >> DRM_DEBUG_KMS("Found LynxPoint LP PCH\n"); >> WARN_ON(!IS_HASWELL(dev)); >> + } else { >> + found = 0; >> + } >> + if (found) { >> + BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); >> + pci_dev_put(pch); >> + break; >> } >> - BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); >> } >> - pci_dev_put(pch); >> + pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, curr); >> + pci_dev_put(curr); >> + } >> + if (!pch) { >> + DRM_DEBUG_KMS("No PCH found?\n"); >> } >> } >> > > I'd like to see a comment about this being for Xen in here, and I > wonder if there are other places where we might have to worry about the > Xen implementation. In that case, setting a flag in dev_priv when we > don't find the PCH where we expect would be a good idea too. > I can add a comment here if the overall idea is acceptable to you. But there is already a comment mentioning that the ISA bridge check is for virtualization: 404 /* 405 * The reason to probe ISA bridge instead of Dev31:Fun0 is to 406 * make graphics device passthrough work easy for VMM, that only 407 * need to expose ISA bridge to let driver know the real hardware 408 * underneath. This is a requirement from virtualization team. 409 */ > Ack on the general idea though; I'd like us to be able to run under Xen > without modification. > Stefano may be able to comment if it's feasible to achieve zero modification in this case. I believe this has something to do with getting rid of the PIIX3 device provided by qemu. But generally I think it's very hard to achieve perfect emulation. You can't always foresee what assumption a guest driver would make. Maybe we need some compromise. > Jesse > > -- > Jesse Barnes, Intel Open Source Technology Center
On Wed, 19 Dec 2012 01:43:22 +0800 "G.R." <firemeteor@users.sourceforge.net> wrote: > On Wed, Dec 19, 2012 at 12:53 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > > On Wed, 19 Dec 2012 00:49:28 +0800 > > "G.R." <firemeteor@users.sourceforge.net> wrote: > > > >> Hi guys, > >> > >> In XEN HVM guest, there is always an emulated PIIX3 ISA bridge on slot 01.0. > >> This shadows the PCH ISA bridge on 1f.0 with the current > >> intel_detect_pch() implementation. > >> The issue can be easily solved by looping through all the ISA bridges > >> until the first match is found, instead of just check against the > >> first one. > >> > >> Here I attach the patch I used locally. It's created on Torvalds's git. > >> Looking forward to your comments. > >> > >> Thanks, > >> Timothy > >> > >> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > >> index 530db83..3f7e5fb 100644 > >> --- a/drivers/gpu/drm/i915/i915_drv.c > >> +++ b/drivers/gpu/drm/i915/i915_drv.c > >> @@ -408,9 +408,11 @@ void intel_detect_pch(struct drm_device *dev) > >> * underneath. This is a requirement from virtualization team. > >> */ > >> pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, NULL); > >> - if (pch) { > >> + while (pch) { > >> + struct pci_dev * curr = pch; > >> if (pch->vendor == PCI_VENDOR_ID_INTEL) { > >> unsigned short id; > >> + unsigned found = 1; > >> id = pch->device & INTEL_PCH_DEVICE_ID_MASK; > >> dev_priv->pch_id = id; > >> > >> @@ -440,10 +442,20 @@ void intel_detect_pch(struct drm_device *dev) > >> dev_priv->num_pch_pll = 0; > >> DRM_DEBUG_KMS("Found LynxPoint LP PCH\n"); > >> WARN_ON(!IS_HASWELL(dev)); > >> + } else { > >> + found = 0; > >> + } > >> + if (found) { > >> + BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); > >> + pci_dev_put(pch); > >> + break; > >> } > >> - BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); > >> } > >> - pci_dev_put(pch); > >> + pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, curr); > >> + pci_dev_put(curr); > >> + } > >> + if (!pch) { > >> + DRM_DEBUG_KMS("No PCH found?\n"); > >> } > >> } > >> > > > > I'd like to see a comment about this being for Xen in here, and I > > wonder if there are other places where we might have to worry about the > > Xen implementation. In that case, setting a flag in dev_priv when we > > don't find the PCH where we expect would be a good idea too. > > > > I can add a comment here if the overall idea is acceptable to you. > But there is already a comment mentioning that the ISA bridge check is > for virtualization: > > 404 /* > 405 * The reason to probe ISA bridge instead of Dev31:Fun0 is to > 406 * make graphics device passthrough work easy for VMM, that only > 407 * need to expose ISA bridge to let driver know the real hardware > 408 * underneath. This is a requirement from virtualization team. > 409 */ > > > Ack on the general idea though; I'd like us to be able to run under Xen > > without modification. > > > > Stefano may be able to comment if it's feasible to achieve zero > modification in this case. > I believe this has something to do with getting rid of the PIIX3 > device provided by qemu. > > But generally I think it's very hard to achieve perfect emulation. > You can't always foresee what assumption a guest driver would make. > Maybe we need some compromise. I meant that I'd like to see any other patches required for Xen get merged, that way people won't have to patch their kernels for i915 under Xen.
On Wed, Dec 19, 2012 at 2:20 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > On Wed, 19 Dec 2012 01:43:22 +0800 > "G.R." <firemeteor@users.sourceforge.net> wrote: > >> On Wed, Dec 19, 2012 at 12:53 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote: >> > On Wed, 19 Dec 2012 00:49:28 +0800 >> > "G.R." <firemeteor@users.sourceforge.net> wrote: >> > >> >> Hi guys, >> >> >> >> In XEN HVM guest, there is always an emulated PIIX3 ISA bridge on slot 01.0. >> >> This shadows the PCH ISA bridge on 1f.0 with the current >> >> intel_detect_pch() implementation. >> >> The issue can be easily solved by looping through all the ISA bridges >> >> until the first match is found, instead of just check against the >> >> first one. >> >> >> >> Here I attach the patch I used locally. It's created on Torvalds's git. >> >> Looking forward to your comments. >> >> >> >> Thanks, >> >> Timothy >> >> >> >> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c >> >> index 530db83..3f7e5fb 100644 >> >> --- a/drivers/gpu/drm/i915/i915_drv.c >> >> +++ b/drivers/gpu/drm/i915/i915_drv.c >> >> @@ -408,9 +408,11 @@ void intel_detect_pch(struct drm_device *dev) >> >> * underneath. This is a requirement from virtualization team. >> >> */ >> >> pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, NULL); >> >> - if (pch) { >> >> + while (pch) { >> >> + struct pci_dev * curr = pch; >> >> if (pch->vendor == PCI_VENDOR_ID_INTEL) { >> >> unsigned short id; >> >> + unsigned found = 1; >> >> id = pch->device & INTEL_PCH_DEVICE_ID_MASK; >> >> dev_priv->pch_id = id; >> >> >> >> @@ -440,10 +442,20 @@ void intel_detect_pch(struct drm_device *dev) >> >> dev_priv->num_pch_pll = 0; >> >> DRM_DEBUG_KMS("Found LynxPoint LP PCH\n"); >> >> WARN_ON(!IS_HASWELL(dev)); >> >> + } else { >> >> + found = 0; >> >> + } >> >> + if (found) { >> >> + BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); >> >> + pci_dev_put(pch); >> >> + break; >> >> } >> >> - BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); >> >> } >> >> - pci_dev_put(pch); >> >> + pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, curr); >> >> + pci_dev_put(curr); >> >> + } >> >> + if (!pch) { >> >> + DRM_DEBUG_KMS("No PCH found?\n"); >> >> } >> >> } >> >> >> > >> > I'd like to see a comment about this being for Xen in here, and I >> > wonder if there are other places where we might have to worry about the >> > Xen implementation. In that case, setting a flag in dev_priv when we >> > don't find the PCH where we expect would be a good idea too. >> > >> >> I can add a comment here if the overall idea is acceptable to you. >> But there is already a comment mentioning that the ISA bridge check is >> for virtualization: >> >> 404 /* >> 405 * The reason to probe ISA bridge instead of Dev31:Fun0 is to >> 406 * make graphics device passthrough work easy for VMM, that only >> 407 * need to expose ISA bridge to let driver know the real hardware >> 408 * underneath. This is a requirement from virtualization team. >> 409 */ >> >> > Ack on the general idea though; I'd like us to be able to run under Xen >> > without modification. >> > >> >> Stefano may be able to comment if it's feasible to achieve zero >> modification in this case. >> I believe this has something to do with getting rid of the PIIX3 >> device provided by qemu. >> >> But generally I think it's very hard to achieve perfect emulation. >> You can't always foresee what assumption a guest driver would make. >> Maybe we need some compromise. > > I meant that I'd like to see any other patches required for Xen get > merged, that way people won't have to patch their kernels for i915 > under Xen. > Sorry for misreading your comment :-) > -- > Jesse Barnes, Intel Open Source Technology Center
On Wed, Dec 19, 2012 at 1:21 AM, Ben Widawsky <ben@bwidawsk.net> wrote: > On Wed, 19 Dec 2012 00:49:28 +0800 > "G.R." <firemeteor@users.sourceforge.net> wrote: > >> Hi guys, >> >> In XEN HVM guest, there is always an emulated PIIX3 ISA bridge on slot 01.0. >> This shadows the PCH ISA bridge on 1f.0 with the current >> intel_detect_pch() implementation. >> The issue can be easily solved by looping through all the ISA bridges >> until the first match is found, instead of just check against the >> first one. >> >> Here I attach the patch I used locally. It's created on Torvalds's git. >> Looking forward to your comments. >> >> Thanks, >> Timothy > > Is this functionally equivalent to > http://lists.freedesktop.org/archives/intel-gfx/2012-July/019126.html? > I don't think so. The patch you mentioned tries to detect the VM. The info could be used enables any required workaround later. Jesse also expressed the same concern in his mail. The problem is that there is no standard way to detect a VM. The patch you mentioned should only work for XEN HVM config. My patch tries to correctly detect the PCH type in a IGD passthrough VM. This enables PCH specific code path in the driver. It really fixes some failure related to gaming / video play back with VAAPI etc in such a config. (But it's not a cure-all solution of course, since this is specific to linux driver. And there may still be other some xen specific issues to triage. For example, my linux box almost work great now, but win7 still keeping BSOD and I even have no idea how to debug) I think it is feasible to combine the two ideas together if you are willing to provide VM specific support in your driver. But as I mentioned before, the problem is we may still need to do it case by case... >> >> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c >> index 530db83..3f7e5fb 100644 >> --- a/drivers/gpu/drm/i915/i915_drv.c >> +++ b/drivers/gpu/drm/i915/i915_drv.c >> @@ -408,9 +408,11 @@ void intel_detect_pch(struct drm_device *dev) >> * underneath. This is a requirement from virtualization team. >> */ >> pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, NULL); >> - if (pch) { >> + while (pch) { >> + struct pci_dev * curr = pch; >> if (pch->vendor == PCI_VENDOR_ID_INTEL) { >> unsigned short id; >> + unsigned found = 1; >> id = pch->device & INTEL_PCH_DEVICE_ID_MASK; >> dev_priv->pch_id = id; >> >> @@ -440,10 +442,20 @@ void intel_detect_pch(struct drm_device *dev) >> dev_priv->num_pch_pll = 0; >> DRM_DEBUG_KMS("Found LynxPoint LP PCH\n"); >> WARN_ON(!IS_HASWELL(dev)); >> + } else { >> + found = 0; >> + } >> + if (found) { >> + BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); >> + pci_dev_put(pch); >> + break; >> } >> - BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); >> } >> - pci_dev_put(pch); >> + pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, curr); >> + pci_dev_put(curr); >> + } >> + if (!pch) { >> + DRM_DEBUG_KMS("No PCH found?\n"); >> } >> } >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > Ben Widawsky, Intel Open Source Technology Center
On Wed, Dec 19, 2012 at 2:20 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote: >> > >> > I'd like to see a comment about this being for Xen in here, and I >> > wonder if there are other places where we might have to worry about the >> > Xen implementation. In that case, setting a flag in dev_priv when we >> > don't find the PCH where we expect would be a good idea too. >> > >> >> I can add a comment here if the overall idea is acceptable to you. >> But there is already a comment mentioning that the ISA bridge check is >> for virtualization: >> >> 404 /* >> 405 * The reason to probe ISA bridge instead of Dev31:Fun0 is to >> 406 * make graphics device passthrough work easy for VMM, that only >> 407 * need to expose ISA bridge to let driver know the real hardware >> 408 * underneath. This is a requirement from virtualization team. >> 409 */ >> >> > Ack on the general idea though; I'd like us to be able to run under Xen >> > without modification. >> > >> >> Stefano may be able to comment if it's feasible to achieve zero >> modification in this case. >> I believe this has something to do with getting rid of the PIIX3 >> device provided by qemu. >> >> But generally I think it's very hard to achieve perfect emulation. >> You can't always foresee what assumption a guest driver would make. >> Maybe we need some compromise. > > I meant that I'd like to see any other patches required for Xen get > merged, that way people won't have to patch their kernels for i915 > under Xen. Hi Jesse, I think I need to resend the patch with proper comment to have it formally accepted. Any guide line for formal patch submission? Do I need to start a separate thread?
On Thu, 20 Dec 2012 12:04:11 +0800 "G.R." <firemeteor@users.sourceforge.net> wrote: > On Wed, Dec 19, 2012 at 2:20 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > >> > > >> > I'd like to see a comment about this being for Xen in here, and I > >> > wonder if there are other places where we might have to worry about the > >> > Xen implementation. In that case, setting a flag in dev_priv when we > >> > don't find the PCH where we expect would be a good idea too. > >> > > >> > >> I can add a comment here if the overall idea is acceptable to you. > >> But there is already a comment mentioning that the ISA bridge check is > >> for virtualization: > >> > >> 404 /* > >> 405 * The reason to probe ISA bridge instead of Dev31:Fun0 is to > >> 406 * make graphics device passthrough work easy for VMM, that only > >> 407 * need to expose ISA bridge to let driver know the real hardware > >> 408 * underneath. This is a requirement from virtualization team. > >> 409 */ > >> > >> > Ack on the general idea though; I'd like us to be able to run under Xen > >> > without modification. > >> > > >> > >> Stefano may be able to comment if it's feasible to achieve zero > >> modification in this case. > >> I believe this has something to do with getting rid of the PIIX3 > >> device provided by qemu. > >> > >> But generally I think it's very hard to achieve perfect emulation. > >> You can't always foresee what assumption a guest driver would make. > >> Maybe we need some compromise. > > > > I meant that I'd like to see any other patches required for Xen get > > merged, that way people won't have to patch their kernels for i915 > > under Xen. > > Hi Jesse, I think I need to resend the patch with proper comment to > have it formally accepted. > Any guide line for formal patch submission? Do I need to start a > separate thread? No, just cc Daniel Vetter.
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 530db83..3f7e5fb 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -408,9 +408,11 @@ void intel_detect_pch(struct drm_device *dev) * underneath. This is a requirement from virtualization team. */ pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, NULL); - if (pch) { + while (pch) { + struct pci_dev * curr = pch; if (pch->vendor == PCI_VENDOR_ID_INTEL) { unsigned short id; + unsigned found = 1; id = pch->device & INTEL_PCH_DEVICE_ID_MASK; dev_priv->pch_id = id; @@ -440,10 +442,20 @@ void intel_detect_pch(struct drm_device *dev) dev_priv->num_pch_pll = 0; DRM_DEBUG_KMS("Found LynxPoint LP PCH\n"); WARN_ON(!IS_HASWELL(dev)); + } else { + found = 0; + } + if (found) { + BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); + pci_dev_put(pch); + break; } - BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS); } - pci_dev_put(pch); + pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, curr); + pci_dev_put(curr); + } + if (!pch) { + DRM_DEBUG_KMS("No PCH found?\n"); } } _______________________________________________