Hi Jesse,
(I am cc'ing linux-kernel.)
On Mon, 01 Jun 2009 22:31:13 +0300
> Pekka Enberg <[email protected]> wrote:
>
> > Hi Jesse,
> >
> > I am seeing this on my Eee PC 701 which is running a Ubuntu
> > 2.6.28-11.42-generic stock kernel:
> >
> > [ 76.826966] [drm:i915_gem_detect_bit_6_swizzle] *ERROR* Couldn't
> > read from MCHBAR. Disabling tiling.
> > [ 76.827215] [drm] Initialized i915 1.6.0 20080730 on minor 0
> > [ 76.834037] [drm:i915_setparam] *ERROR* unknown parameter 4
> > [ 76.834104] [drm:i915_getparam] *ERROR* Unknown parameter 6
> >
> > Google turned up this patch
> >
> > http://lists.freedesktop.org/archives/intel-gfx/2009-January/001186.html
> >
> > but I don't seem to find it mainline kernel.
> >
> > Was the bug fixed in some other way? It seem that distributions have
> > not yet picked up your patch and I am unsure if it's in any of the
> > -stable kernels.
On Thu, 2009-06-04 at 11:27 +0100, Jesse Barnes wrote:
> I think Eric acked it but may not have pushed it to drm-intel-next
> yet. Should happen in the next week or two though as we prepare the
> merge window series.
OK, thanks for the info! FYI, I tested 2.6.30-rc8 with your patch
applied and everything works smoothly on my EeePC 701. I did not test
plain 2.6.30-rc8 as I expect it to show same kind of behavior as Ubuntu
distro kernel. Is this correct or do you want me to test 2.6.30-rc8 too?
I wonder why the patch hasn't received more attention as it's a pretty
critical bug. The _default_ Ubuntu 9.04 netbook remix installation is
completely broken for EeePC 701 (and probably others as well) without
the patch. And it's not as if I'm the only one that suffers from it. A
quick Google search reveals that a lot of people are hitting it.
So I really do think we need to merge this patch to the upcoming 2.6.31
ASAP and backport it to -stable after it has gotten some more testing.
Pekka
On Fri, 05 Jun 2009 11:02:21 +0300
Pekka Enberg <[email protected]> wrote:
> Hi Jesse,
>
> (I am cc'ing linux-kernel.)
>
> On Mon, 01 Jun 2009 22:31:13 +0300
> > Pekka Enberg <[email protected]> wrote:
> >
> > > Hi Jesse,
> > >
> > > I am seeing this on my Eee PC 701 which is running a Ubuntu
> > > 2.6.28-11.42-generic stock kernel:
> > >
> > > [ 76.826966] [drm:i915_gem_detect_bit_6_swizzle] *ERROR* Couldn't
> > > read from MCHBAR. Disabling tiling.
> > > [ 76.827215] [drm] Initialized i915 1.6.0 20080730 on minor 0
> > > [ 76.834037] [drm:i915_setparam] *ERROR* unknown parameter 4
> > > [ 76.834104] [drm:i915_getparam] *ERROR* Unknown parameter 6
> > >
> > > Google turned up this patch
> > >
> > > http://lists.freedesktop.org/archives/intel-gfx/2009-January/001186.html
> > >
> > > but I don't seem to find it mainline kernel.
> > >
> > > Was the bug fixed in some other way? It seem that distributions have
> > > not yet picked up your patch and I am unsure if it's in any of the
> > > -stable kernels.
>
> On Thu, 2009-06-04 at 11:27 +0100, Jesse Barnes wrote:
> > I think Eric acked it but may not have pushed it to drm-intel-next
> > yet. Should happen in the next week or two though as we prepare the
> > merge window series.
>
> OK, thanks for the info! FYI, I tested 2.6.30-rc8 with your patch
> applied and everything works smoothly on my EeePC 701. I did not test
> plain 2.6.30-rc8 as I expect it to show same kind of behavior as Ubuntu
> distro kernel. Is this correct or do you want me to test 2.6.30-rc8 too?
>
> I wonder why the patch hasn't received more attention as it's a pretty
> critical bug. The _default_ Ubuntu 9.04 netbook remix installation is
> completely broken for EeePC 701 (and probably others as well) without
> the patch. And it's not as if I'm the only one that suffers from it. A
> quick Google search reveals that a lot of people are hitting it.
>
> So I really do think we need to merge this patch to the upcoming 2.6.31
> ASAP and backport it to -stable after it has gotten some more testing.
>
Wanna show us the patch?
Because the world could certainly do with more i915 bugfixes :(
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9851589..5919537 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -143,6 +143,8 @@ typedef struct drm_i915_private {
drm_local_map_t hws_map;
struct drm_gem_object *hws_obj;
+ struct resource mch_res;
+
unsigned int cpp;
int back_offset;
int front_offset;
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index fe7877a..1441a9e 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -24,6 +24,7 @@
* Eric Anholt <[email protected]>
*
*/
+#include <linux/acpi.h>
#include "linux/string.h"
#include "linux/bitops.h"
@@ -81,6 +82,176 @@
* to match what the GPU expects.
*/
+#define MCHBAR_I915 0x44
+#define MCHBAR_I965 0x48
+#define MCHBAR_SIZE (4*4096)
+
+#define DEVEN_REG 0x54
+#define DEVEN_MCHBAR_EN (1 << 28)
+
+/*
+ * ACPI resource checking fun. So the MCHBAR has *probably* been set
+ * up by the BIOS since drivers need to poke at it, but out of paranoia
+ * or whatever, many BIOSes disable the MCHBAR at boot. So we check
+ * to make sure any existing address is reserved before using it. If
+ * we can't find a match or there is no address, allocate some new PCI
+ * space for it, and then enable it. And of course 915 has to be different
+ * and put its enable bit somewhere else...
+ */
+static acpi_status __init check_mch_resource(struct acpi_resource *res,
+ void *data)
+{
+ struct resource *mch_res = data;
+ struct acpi_resource_address64 address;
+ acpi_status status;
+
+ if (res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
+ struct acpi_resource_fixed_memory32 *fixmem32 =
+ &res->data.fixed_memory32;
+ if (!fixmem32)
+ return AE_OK;
+
+ if ((mch_res->start >= fixmem32->address) &&
+ (mch_res->end < (fixmem32->address +
+ fixmem32->address_length))) {
+ mch_res->flags = 1;
+ return AE_CTRL_TERMINATE;
+ }
+ }
+ if ((res->type != ACPI_RESOURCE_TYPE_ADDRESS32) &&
+ (res->type != ACPI_RESOURCE_TYPE_ADDRESS64))
+ return AE_OK;
+
+ status = acpi_resource_to_address64(res, &address);
+ if (ACPI_FAILURE(status) ||
+ (address.address_length <= 0) ||
+ (address.resource_type != ACPI_MEMORY_RANGE))
+ return AE_OK;
+
+ if ((mch_res->start >= address.minimum) &&
+ (mch_res->end < (address.minimum + address.address_length))) {
+ mch_res->flags = 1;
+ return AE_CTRL_TERMINATE;
+ }
+ return AE_OK;
+}
+
+static acpi_status __init find_mboard_resource(acpi_handle handle, u32 lvl,
+ void *context, void **rv)
+{
+ struct resource *mch_res = context;
+
+ acpi_walk_resources(handle, METHOD_NAME__CRS,
+ check_mch_resource, context);
+
+ if (mch_res->flags)
+ return AE_CTRL_TERMINATE;
+
+ return AE_OK;
+}
+
+static int __init is_acpi_reserved(u64 start, u64 end, unsigned not_used)
+{
+ struct resource mch_res;
+
+ mch_res.start = start;
+ mch_res.end = end;
+ mch_res.flags = 0;
+
+ acpi_get_devices("PNP0C01", find_mboard_resource, &mch_res, NULL);
+
+ if (!mch_res.flags)
+ acpi_get_devices("PNP0C02", find_mboard_resource, &mch_res,
+ NULL);
+
+ return mch_res.flags;
+}
+
+/* Allocate space for the MCH regs if needed, return nonzero on error */
+static int
+intel_alloc_mchbar_resource(struct drm_device *dev)
+{
+ struct pci_dev *bridge_dev;
+ drm_i915_private_t *dev_priv = dev->dev_private;
+ int reg = IS_I965G(dev) ? MCHBAR_I965 : MCHBAR_I915;
+ u32 temp_lo, temp_hi = 0;
+ u64 mchbar_addr;
+ int ret;
+
+ bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0,0));
+ if (!bridge_dev) {
+ DRM_DEBUG("no bridge dev?!\n");
+ return -ENODEV;
+ }
+
+ if (IS_I965G(dev))
+ pci_read_config_dword(bridge_dev, reg + 4, &temp_hi);
+ pci_read_config_dword(bridge_dev, reg, &temp_lo);
+ mchbar_addr = ((u64)temp_hi << 32) | temp_lo;
+
+ /* If ACPI doesn't have it, assume we need to allocate it ourselves */
+ if (mchbar_addr &&
+ is_acpi_reserved(mchbar_addr, mchbar_addr + MCHBAR_SIZE, 0))
+ return 0;
+
+ /* Get some space for it */
+ ret = pci_bus_alloc_resource(bridge_dev->bus, &dev_priv->mch_res,
+ MCHBAR_SIZE, MCHBAR_SIZE,
+ PCIBIOS_MIN_MEM,
+ 0, pcibios_align_resource,
+ bridge_dev);
+ if (ret) {
+ DRM_DEBUG("failed bus alloc: %d\n", ret);
+ dev_priv->mch_res.start = 0;
+ return ret;
+ }
+
+ if (IS_I965G(dev))
+ pci_write_config_dword(bridge_dev, reg + 4,
+ upper_32_bits(dev_priv->mch_res.start));
+
+ pci_write_config_dword(bridge_dev, reg,
+ lower_32_bits(dev_priv->mch_res.start));
+
+ return 0;
+}
+
+static void
+intel_setup_mchbar(struct drm_device *dev)
+{
+ struct pci_dev *bridge_dev;
+ int mchbar_reg = IS_I965G(dev) ? MCHBAR_I965 : MCHBAR_I915;
+ u32 temp;
+
+ bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0,0));
+ if (!bridge_dev) {
+ DRM_DEBUG("no bridge dev?!\n");
+ return;
+ }
+
+ if (intel_alloc_mchbar_resource(dev))
+ return;
+
+ /* Now enable it */
+ if (IS_I915G(dev) || IS_I915GM(dev)) {
+ pci_read_config_dword(bridge_dev, DEVEN_REG, &temp);
+ pci_write_config_dword(bridge_dev, DEVEN_REG,
+ temp | DEVEN_MCHBAR_EN);
+ } else {
+ pci_read_config_dword(bridge_dev, mchbar_reg, &temp);
+ pci_write_config_dword(bridge_dev, mchbar_reg, temp | 1);
+ }
+}
+
+static void
+intel_teardown_mchbar(struct drm_device *dev)
+{
+ drm_i915_private_t *dev_priv = dev->dev_private;
+
+ if (dev_priv->mch_res.start)
+ release_resource(&dev_priv->mch_res);
+}
+
/**
* Detects bit 6 swizzling of address lookup between IGD access and CPU
* access through main memory.
@@ -101,6 +272,9 @@ i915_gem_detect_bit_6_swizzle(struct drm
} else if (IS_MOBILE(dev)) {
uint32_t dcc;
+ /* Try to make sure MCHBAR is enabled before poking at it */
+ intel_setup_mchbar(dev);
+
/* On mobile 9xx chipsets, channel interleave by the CPU is
* determined by DCC. For single-channel, neither the CPU
* nor the GPU do swizzling. For dual channel interleaved,
@@ -140,6 +314,8 @@ i915_gem_detect_bit_6_swizzle(struct drm
swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
}
+
+ intel_teardown_mchbar(dev);
} else {
/* The 965, G33, and newer, have a very flexible memory
* configuration. It will enable dual-channel mode
Woody Suwalski wrote:
> Andrew Morton wrote:
>> On Fri, 05 Jun 2009 11:02:21 +0300
>> Pekka Enberg <[email protected]> wrote:
>>
>>
>>> Hi Jesse,
>>>
>>> (I am cc'ing linux-kernel.)
>>>
>>> On Mon, 01 Jun 2009 22:31:13 +0300
>>>
>>>> Pekka Enberg <[email protected]> wrote:
>>>>
>>>>
>>>>> Hi Jesse,
>>>>>
>>>>> I am seeing this on my Eee PC 701 which is running a Ubuntu
>>>>> 2.6.28-11.42-generic stock kernel:
>>>>>
>>>>> [ 76.826966] [drm:i915_gem_detect_bit_6_swizzle] *ERROR* Couldn't
>>>>> read from MCHBAR. Disabling tiling.
>>>>> [ 76.827215] [drm] Initialized i915 1.6.0 20080730 on minor 0
>>>>> [ 76.834037] [drm:i915_setparam] *ERROR* unknown parameter 4
>>>>> [ 76.834104] [drm:i915_getparam] *ERROR* Unknown parameter 6
>>>>>
>>>>> Google turned up this patch
>>>>>
>>>>> http://lists.freedesktop.org/archives/intel-gfx/2009-January/001186.html
>>>>>
>>>>>
>>>>> but I don't seem to find it mainline kernel.
>>>>>
>>>>> Was the bug fixed in some other way? It seem that distributions have
>>>>> not yet picked up your patch and I am unsure if it's in any of the
>>>>> -stable kernels.
>>>>>
>>> On Thu, 2009-06-04 at 11:27 +0100, Jesse Barnes wrote:
>>>
>>>> I think Eric acked it but may not have pushed it to drm-intel-next
>>>> yet. Should happen in the next week or two though as we prepare the
>>>> merge window series.
>>>>
>>> OK, thanks for the info! FYI, I tested 2.6.30-rc8 with your patch
>>> applied and everything works smoothly on my EeePC 701. I did not test
>>> plain 2.6.30-rc8 as I expect it to show same kind of behavior as Ubuntu
>>> distro kernel. Is this correct or do you want me to test 2.6.30-rc8 too?
>>>
>>> I wonder why the patch hasn't received more attention as it's a pretty
>>> critical bug. The _default_ Ubuntu 9.04 netbook remix installation is
>>> completely broken for EeePC 701 (and probably others as well) without
>>> the patch. And it's not as if I'm the only one that suffers from it. A
>>> quick Google search reveals that a lot of people are hitting it.
>>>
>>> So I really do think we need to merge this patch to the upcoming 2.6.31
>>> ASAP and backport it to -stable after it has gotten some more testing.
>>
>> Wanna show us the patch?
>>
>> Because the world could certainly do with more i915 bugfixes :(
>
> Here is Jesse's patch from
> http://lists.freedesktop.org/archives/intel-gfx/2009-January/001186.html
> adopted for 2.6.30-rc8... (needed to redo hunk #3 for i915_gem_tile.c)
Yup. I took the two patches from here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/349314
and did the same rediffing on top of 2.6.30-rc8 for the first one.
Andrew, do you want me to forward you the (tested) patches or should we
wait for Jesse et al to take care of it?
Pekka
On Sat, 06 Jun 2009 09:14:41 +0300 Pekka Enberg <[email protected]> wrote:
> >> Wanna show us the patch?
> >>
> >> Because the world could certainly do with more i915 bugfixes :(
> >
> > Here is Jesse's patch from
> > http://lists.freedesktop.org/archives/intel-gfx/2009-January/001186.html
> > adopted for 2.6.30-rc8... (needed to redo hunk #3 for i915_gem_tile.c)
>
> Yup. I took the two patches from here:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/349314
>
> and did the same rediffing on top of 2.6.30-rc8 for the first one.
>
> Andrew, do you want me to forward you the (tested) patches or should we
> wait for Jesse et al to take care of it?
Yes, please send them out.
These might end up being 2.6.30.1 material.
Hi Andrew,
On Sat, 06 Jun 2009 09:14:41 +0300 Pekka Enberg <[email protected]>
wrote:
>>>> Wanna show us the patch?
>>>>
>>>> Because the world could certainly do with more i915 bugfixes :(
>>>
>>> Here is Jesse's patch from
>>> http://lists.freedesktop.org/archives/intel-gfx/2009-January/001186.html
>>> adopted for 2.6.30-rc8... (needed to redo hunk #3 for i915_gem_tile.c)
>> Yup. I took the two patches from here:
>>
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/349314
>>
>> and did the same rediffing on top of 2.6.30-rc8 for the first one.
>>
>> Andrew, do you want me to forward you the (tested) patches or should we
>> wait for Jesse et al to take care of it?
>
> Yes, please send them out.
OK, I did that. I am bit unhappy that I had to do it, though. The patch
dates back to January (!) and Ubuntu folks have been carrying it for a
while now.
Looking at the amount of reports out in the wild (on Ubuntu forums,
etc.), I really don't understand why this wasn't submitted earlier.
Instead, the bug was flagged with low priority because it's "just a
performance problem." Considering the system is more or less unusable
for me, I obviously think it's a critical bug fix.
Andrew Morton wrote:
> These might end up being 2.6.30.1 material.
Yes, agreed completely. We probably want ACK from Jesse and Bjorn, though.
Pekka
On Sat, 06 Jun 2009 09:37:00 +0300
Pekka Enberg <[email protected]> wrote:
> Hi Andrew,
>
> On Sat, 06 Jun 2009 09:14:41 +0300 Pekka Enberg
> <[email protected]> wrote:
> >>>> Wanna show us the patch?
> >>>>
> >>>> Because the world could certainly do with more i915 bugfixes :(
> >>>
> >>> Here is Jesse's patch from
> >>> http://lists.freedesktop.org/archives/intel-gfx/2009-January/001186.html
> >>> adopted for 2.6.30-rc8... (needed to redo hunk #3 for
> >>> i915_gem_tile.c)
> >> Yup. I took the two patches from here:
> >>
> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/349314
> >>
> >> and did the same rediffing on top of 2.6.30-rc8 for the first one.
> >>
> >> Andrew, do you want me to forward you the (tested) patches or
> >> should we wait for Jesse et al to take care of it?
> >
> > Yes, please send them out.
>
> OK, I did that. I am bit unhappy that I had to do it, though. The
> patch dates back to January (!) and Ubuntu folks have been carrying
> it for a while now.
>
> Looking at the amount of reports out in the wild (on Ubuntu forums,
> etc.), I really don't understand why this wasn't submitted earlier.
> Instead, the bug was flagged with low priority because it's "just a
> performance problem." Considering the system is more or less unusable
> for me, I obviously think it's a critical bug fix.
>
> Andrew Morton wrote:
> > These might end up being 2.6.30.1 material.
>
> Yes, agreed completely. We probably want ACK from Jesse and Bjorn,
> though.
I'm ok with it being 2.6.30.1 stuff, but given the significance of the
change we were worried about putting it into 2.6.30 late in the cycle.
But as you say, it's a very important performance fix for many
machines...
Anyway, Eric may already have it merged. Eric?
Jesse
On Sat, Jun 06, 2009 at 09:37:00AM +0300, Pekka Enberg wrote:
> Hi Andrew,
>
> On Sat, 06 Jun 2009 09:14:41 +0300 Pekka Enberg <[email protected]>
> wrote:
>>>>> Wanna show us the patch?
>>>>>
>>>>> Because the world could certainly do with more i915 bugfixes :(
>>>> Here is Jesse's patch from
>>>> http://lists.freedesktop.org/archives/intel-gfx/2009-January/001186.html
>>>> adopted for 2.6.30-rc8... (needed to redo hunk #3 for
>>>> i915_gem_tile.c)
>>> Yup. I took the two patches from here:
>>>
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/349314
>>>
>>> and did the same rediffing on top of 2.6.30-rc8 for the first one.
>>>
>>> Andrew, do you want me to forward you the (tested) patches or should
>>> we wait for Jesse et al to take care of it?
>>
>> Yes, please send them out.
>
> OK, I did that. I am bit unhappy that I had to do it, though. The patch
> dates back to January (!) and Ubuntu folks have been carrying it for a
> while now.
We cirtainly have been carrying for some time. My understanding was
that the maintainers had it and had been expecting it to merge through
them. Did we miss a trick somewhere?
-apw
On Sat, 6 Jun 2009 21:27:59 +0100
Jesse Barnes <[email protected]> wrote:
> On Sat, 06 Jun 2009 09:37:00 +0300
> Pekka Enberg <[email protected]> wrote:
>
> > Hi Andrew,
> >
> > On Sat, 06 Jun 2009 09:14:41 +0300 Pekka Enberg
> > <[email protected]> wrote:
> > >>>> Wanna show us the patch?
> > >>>>
> > >>>> Because the world could certainly do with more i915 bugfixes :(
> > >>>
> > >>> Here is Jesse's patch from
> > >>> http://lists.freedesktop.org/archives/intel-gfx/2009-January/001186.html
> > >>> adopted for 2.6.30-rc8... (needed to redo hunk #3 for
> > >>> i915_gem_tile.c)
> > >> Yup. I took the two patches from here:
> > >>
> > >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/349314
> > >>
> > >> and did the same rediffing on top of 2.6.30-rc8 for the first
> > >> one.
> > >>
> > >> Andrew, do you want me to forward you the (tested) patches or
> > >> should we wait for Jesse et al to take care of it?
> > >
> > > Yes, please send them out.
> >
> > OK, I did that. I am bit unhappy that I had to do it, though. The
> > patch dates back to January (!) and Ubuntu folks have been carrying
> > it for a while now.
> >
> > Looking at the amount of reports out in the wild (on Ubuntu forums,
> > etc.), I really don't understand why this wasn't submitted earlier.
> > Instead, the bug was flagged with low priority because it's "just a
> > performance problem." Considering the system is more or less
> > unusable for me, I obviously think it's a critical bug fix.
> >
> > Andrew Morton wrote:
> > > These might end up being 2.6.30.1 material.
> >
> > Yes, agreed completely. We probably want ACK from Jesse and Bjorn,
> > though.
>
> I'm ok with it being 2.6.30.1 stuff, but given the significance of the
> change we were worried about putting it into 2.6.30 late in the cycle.
> But as you say, it's a very important performance fix for many
> machines...
>
> Anyway, Eric may already have it merged. Eric?
>
It's merged now into the drm-intel-next tree, and therefore queued for
the merge window.
Jeses
On Tue, 9 Jun 2009 15:07:57 -0700
Jesse Barnes <[email protected]> wrote:
> > > Andrew Morton wrote:
> > > > These might end up being 2.6.30.1 material.
> > >
> > > Yes, agreed completely. We probably want ACK from Jesse and Bjorn,
> > > though.
> >
> > I'm ok with it being 2.6.30.1 stuff, but given the significance of the
> > change we were worried about putting it into 2.6.30 late in the cycle.
> > But as you say, it's a very important performance fix for many
> > machines...
> >
> > Anyway, Eric may already have it merged. Eric?
> >
>
> It's merged now into the drm-intel-next tree, and therefore queued for
> the merge window.
<hunts around for a while>
This? http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commitdiff;h=d765898970f35acef960581f678b9da9d5c779fa;hp=1b8e69662e1a086878bf930a6042daf7f8a076cc
It doesn't have cc:stable in the changelog, so there's a reasonable
chance that it will get lost.
The -stable guys troll the commit list looking for mainline commits
which mention [email protected] in the changelog.
On Tue, Jun 09, 2009 at 03:28:28PM -0700, Andrew Morton wrote:
> On Tue, 9 Jun 2009 15:07:57 -0700
> Jesse Barnes <[email protected]> wrote:
>
> > > > Andrew Morton wrote:
> > > > > These might end up being 2.6.30.1 material.
> > > >
> > > > Yes, agreed completely. We probably want ACK from Jesse and Bjorn,
> > > > though.
> > >
> > > I'm ok with it being 2.6.30.1 stuff, but given the significance of the
> > > change we were worried about putting it into 2.6.30 late in the cycle.
> > > But as you say, it's a very important performance fix for many
> > > machines...
> > >
> > > Anyway, Eric may already have it merged. Eric?
> > >
> >
> > It's merged now into the drm-intel-next tree, and therefore queued for
> > the merge window.
>
> <hunts around for a while>
>
> This? http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commitdiff;h=d765898970f35acef960581f678b9da9d5c779fa;hp=1b8e69662e1a086878bf930a6042daf7f8a076cc
>
> It doesn't have cc:stable in the changelog, so there's a reasonable
> chance that it will get lost.
>
> The -stable guys troll the commit list looking for mainline commits
> which mention [email protected] in the changelog.
I got it for the next .30 release.
thanks,
greg k-h
On Mon, Jun 29, 2009 at 10:33:08AM -0700, Greg KH wrote:
> On Tue, Jun 09, 2009 at 03:28:28PM -0700, Andrew Morton wrote:
> > On Tue, 9 Jun 2009 15:07:57 -0700
> > Jesse Barnes <[email protected]> wrote:
> >
> > > > > Andrew Morton wrote:
> > > > > > These might end up being 2.6.30.1 material.
> > > > >
> > > > > Yes, agreed completely. We probably want ACK from Jesse and Bjorn,
> > > > > though.
> > > >
> > > > I'm ok with it being 2.6.30.1 stuff, but given the significance of the
> > > > change we were worried about putting it into 2.6.30 late in the cycle.
> > > > But as you say, it's a very important performance fix for many
> > > > machines...
> > > >
> > > > Anyway, Eric may already have it merged. Eric?
> > > >
> > >
> > > It's merged now into the drm-intel-next tree, and therefore queued for
> > > the merge window.
> >
> > <hunts around for a while>
> >
> > This? http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commitdiff;h=d765898970f35acef960581f678b9da9d5c779fa;hp=1b8e69662e1a086878bf930a6042daf7f8a076cc
> >
> > It doesn't have cc:stable in the changelog, so there's a reasonable
> > chance that it will get lost.
> >
> > The -stable guys troll the commit list looking for mainline commits
> > which mention [email protected] in the changelog.
>
> I got it for the next .30 release.
I take it back. It doesn't build properly on 2.6.30, can someone
backport commit d765898970f35acef960581f678b9da9d5c779fa to the 2.6.30
tree and send it to [email protected] so that we can apply it to resolve
this issue?
And is it relevant to 2.6.29 as well?
thanks,
greg k-h
Greg KH wrote:
> I take it back. It doesn't build properly on 2.6.30, can someone
> backport commit d765898970f35acef960581f678b9da9d5c779fa to the 2.6.30
> tree and send it to [email protected] so that we can apply it to resolve
> this issue?
> ease read the FAQ at http://www.tux.org/lkml/
>
There was this commit on top of them which was fixed the build problem
for me:
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fanholt%2Fdrm-intel.git;a=commitdiff_plain;h=34c8638bb5ee130b8151c57708284bcd4972e2e1;hp=003c9ca68810bc0a63a1f3ff6beec839b197e23b
On Mon, Jun 29, 2009 at 09:51:51PM +0300, Ozan Çağlayan wrote:
> Greg KH wrote:
> > I take it back. It doesn't build properly on 2.6.30, can someone
> > backport commit d765898970f35acef960581f678b9da9d5c779fa to the 2.6.30
> > tree and send it to [email protected] so that we can apply it to resolve
> > this issue?
> > ease read the FAQ at http://www.tux.org/lkml/
> >
>
> There was this commit on top of them which was fixed the build problem
> for me:
> http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fanholt%2Fdrm-intel.git;a=commitdiff_plain;h=34c8638bb5ee130b8151c57708284bcd4972e2e1;hp=003c9ca68810bc0a63a1f3ff6beec839b197e23b
No, the issue is the pnp_resource() call, that's not present in 2.6.30.
Can someone backport whatever is needed in .30 and send it to us?
thanks,
greg k-h