[PATCH 2/2] pnp: add PNP resource range checking function

[PATCH 2/2] pnp: add PNP resource range checking function

[Pekka J Enberg]

From: Bjorn Helgaas <bjorn.helgaas@hp.com>

Add a PNP resource range check function, indicating whether a resource
has been assigned to any device.

This patch fixes a serious performance regression on Asus Eee PC 701 (and
probably other) systems. See the following URL for details:

  http://bugs.launchpad.net/bugs/349314

[ apw@canonical.com: fixed up exports et al ]
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Colin King <colin.king@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonicalc.com>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
Andrew, I am not completely sure if this is needed or not. But apparently 
the Ubuntu folks think it is and I did test the combination of these two 
patches.

 drivers/pnp/resource.c |   18 ++++++++++++++++++
 include/linux/pnp.h    |    2 ++
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/pnp/resource.c b/drivers/pnp/resource.c
index f604061..ba97654 100644
--- a/drivers/pnp/resource.c
+++ b/drivers/pnp/resource.c
@@ -638,6 +638,24 @@ int pnp_possible_config(struct pnp_dev *dev, int type, resource_size_t start,
 }
 EXPORT_SYMBOL(pnp_possible_config);
 
+int pnp_range_reserved(resource_size_t start, resource_size_t end)
+{
+	struct pnp_dev *dev;
+	struct pnp_resource *pnp_res;
+	resource_size_t *dev_start, *dev_end;
+
+	pnp_for_each_dev(dev) {
+		list_for_each_entry(pnp_res, &dev->resources, list) {
+			dev_start = &pnp_res->res.start;
+			dev_end   = &pnp_res->res.end;
+			if (ranged_conflict(&start, &end, dev_start, dev_end))
+				return 1;
+		}
+	}
+	return 0;
+}
+EXPORT_SYMBOL(pnp_range_reserved);
+
 /* format is: pnp_reserve_irq=irq1[,irq2] .... */
 static int __init pnp_setup_reserve_irq(char *str)
 {
diff --git a/include/linux/pnp.h b/include/linux/pnp.h
index ca3c887..b063c73 100644
--- a/include/linux/pnp.h
+++ b/include/linux/pnp.h
@@ -446,6 +446,7 @@ int pnp_start_dev(struct pnp_dev *dev);
 int pnp_stop_dev(struct pnp_dev *dev);
 int pnp_activate_dev(struct pnp_dev *dev);
 int pnp_disable_dev(struct pnp_dev *dev);
+int pnp_range_reserved(resource_size_t start, resource_size_t end);
 
 /* protocol helpers */
 int pnp_is_active(struct pnp_dev *dev);
@@ -476,6 +477,7 @@ static inline int pnp_start_dev(struct pnp_dev *dev) { return -ENODEV; }
 static inline int pnp_stop_dev(struct pnp_dev *dev) { return -ENODEV; }
 static inline int pnp_activate_dev(struct pnp_dev *dev) { return -ENODEV; }
 static inline int pnp_disable_dev(struct pnp_dev *dev) { return -ENODEV; }
+static inline int pnp_range_reserved(resource_size_t start, resource_size_t end) { return 0;}
 
 /* protocol helpers */
 static inline int pnp_is_active(struct pnp_dev *dev) { return 0; }
-- 
1.5.6.3

Re: [PATCH 2/2] pnp: add PNP resource range checking function

[Frans Pop]

> Add a PNP resource range check function, indicating whether a resource
> has been assigned to any device.

Shouldn't this patch come *before* your patch 1/2?
You now seem to use this function in a commit where it has not yet been 
defined, which could result in build errors during bisections.

Cheers,
FJP

Re: [PATCH 2/2] pnp: add PNP resource range checking function

[Pekka Enberg]

Hi Frans,

Frans Pop wrote:
>> Add a PNP resource range check function, indicating whether a resource
>> has been assigned to any device.
> 
> Shouldn't this patch come *before* your patch 1/2?
> You now seem to use this function in a commit where it has not yet been 
> defined, which could result in build errors during bisections.

Yes, correct. Sorry about that!

			Pekka

Re: [PATCH 2/2] pnp: add PNP resource range checking function

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

On Sat, 2009-06-06 at 10:28 +0300, Pekka Enberg wrote:
> Hi Frans,
> 
> Frans Pop wrote:
> >> Add a PNP resource range check function, indicating whether a resource
> >> has been assigned to any device.
> > 
> > Shouldn't this patch come *before* your patch 1/2?
> > You now seem to use this function in a commit where it has not yet been 
> > defined, which could result in build errors during bisections.
> 
> Yes, correct. Sorry about that!
> 
> 			Pekka

This is already in drm-intel-next

-- 
Eric Anholt
eric@anholt.net                         eric.anholt@intel.com



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH 2/2] pnp: add PNP resource range checking function

[Andrew Morton]

On Mon, 08 Jun 2009 17:53:59 -0700
Eric Anholt <eric@anholt.net> wrote:

> On Sat, 2009-06-06 at 10:28 +0300, Pekka Enberg wrote:
> > Hi Frans,
> > 
> > Frans Pop wrote:
> > >> Add a PNP resource range check function, indicating whether a resource
> > >> has been assigned to any device.
> > > 
> > > Shouldn't this patch come *before* your patch 1/2?
> > > You now seem to use this function in a commit where it has not yet been 
> > > defined, which could result in build errors during bisections.
> > 
> > Yes, correct. Sorry about that!
> > 
> > 			Pekka
> 
> This is already in drm-intel-next
> 

Neither patch is in linux-next.  So either a) drm-intel-next contains
2.6.31 material or b) your processes broke.

Either way, these patches fix a "serious performance regression".  They
should be merged into 2.6.30 or 2.6.30.x, shouldn't they?

Re: [PATCH 2/2] pnp: add PNP resource range checking function

[Jesse Barnes]

On Tue, 9 Jun 2009 15:09:44 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Mon, 08 Jun 2009 17:53:59 -0700
> Eric Anholt <eric@anholt.net> wrote:
> 
> > On Sat, 2009-06-06 at 10:28 +0300, Pekka Enberg wrote:
> > > Hi Frans,
> > > 
> > > Frans Pop wrote:
> > > >> Add a PNP resource range check function, indicating whether a
> > > >> resource has been assigned to any device.
> > > > 
> > > > Shouldn't this patch come *before* your patch 1/2?
> > > > You now seem to use this function in a commit where it has not
> > > > yet been defined, which could result in build errors during
> > > > bisections.
> > > 
> > > Yes, correct. Sorry about that!
> > > 
> > > 			Pekka
> > 
> > This is already in drm-intel-next
> > 
> 
> Neither patch is in linux-next.  So either a) drm-intel-next contains
> 2.6.31 material or b) your processes broke.

drm-intel-next gets into linux-next by way of drm-next.  Not sure if
Dave has pulled Eric's bits yet though.

> Either way, these patches fix a "serious performance regression".
> They should be merged into 2.6.30 or 2.6.30.x, shouldn't they?

I'm still a little nervous about this, but I won't block it.  Since the
commits don't have stable@kernel.org cc'd I guess Pekka will just have
to send a note to stable when they go upstream.

-- 
Jesse Barnes, Intel Open Source Technology Center