public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Thomas Renninger <trenn@suse.de>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	linux-acpi <linux-acpi@vger.kernel.org>,
	Bjorn Helgaas <bjorn.helgaas@hp.com>,
	Alexey Starikovskiy <aystarik@gmail.com>,
	Bernhard Walle <bwalle@suse.de>
Subject: Re: [PATCH] - Increase PNP_MAX_PORT. ACPI devices can have a lot IO resource declarations
Date: Mon, 16 Jul 2007 18:48:56 +0200	[thread overview]
Message-ID: <20070716184856.253203d8@hyperion.delvare> (raw)
In-Reply-To: <1184595667.19959.312.camel@queen.suse.de>

Hi Thomas,

On Mon, 16 Jul 2007 16:21:07 +0200, Thomas Renninger wrote:
> PNP0C02 devices normally have a lot more IO port declarations than
> currently defined in PNP_MAX_PORT
> 
> For checking, have a look at your disassembled DSDT, and look out for
> the _CRS function (and/or a ResourceTemplate often called CRS).
> 
> Here an  example:
> IO (Decode16,0x0010,             // Range Minimum
>              0x0010,             // Range Maximum
>              0x00,               // Alignment
>              0x10,               // Length
> )
> IO (Decode16,
>              0x0022,             // Range Minimum
>              0x0022,             // Range Maximum
>              0x00,               // Alignment
>              0x1E,               // Length
> )
> ...
> IO (Decode16,
>              0x0000,             // Range Minimum
>              0x0000,             // Range Maximum
>              0x00,               // Alignment
>              0x00,               // Length
> _Y06)
> IO (Decode16,
>              0x0000,             // Range Minimum
>              0x0000,             // Range Maximum
>              0x00,               // Alignment
>              0x00,               // Length
> _Y07)
> 
> The latter zeroed (_Y07) declarations are filled with dynamic values in
> _CRS and also need an PNP IO port reserved.
> 
> On this machine (x86_64 workstation) more then 20 IO resource
> declarations exist for one PNP0C02 device.
> It could be that the suggested 32 is still not big enough.

I just tested on my own workstation, and 8 wasn't enough for me either:
there are 12 resources listed for the PNP0C02 device on my workstation.

After applying your patch, I get the following differences in /proc/ioports:

--- ioports.before      2007-07-16 18:29:30.000000000 +0200
+++ ioports.after       2007-07-16 18:39:05.000000000 +0200
@@ -13,7 +13,8 @@
 01f0-01f7 : 0000:00:0f.0
   01f0-01f7 : ide0
 0290-0297 : f71805f
-  0295-0296 : f71805f
+  0290-0297 : pnp 00:03
+    0295-0296 : f71805f
 0376-0376 : 0000:00:0f.0
   0376-0376 : ide1
 0378-037a : parport0
@@ -21,6 +22,8 @@
 03f6-03f6 : 0000:00:0f.0
   03f6-03f6 : ide0
 03f8-03ff : serial
+04d0-04d1 : pnp 00:03
+0800-0805 : pnp 00:03
 0cf8-0cff : PCI conf1
 4000-407f : pnp 00:02
   4000-4003 : ACPI PM1a_EVT_BLK

> (...)
> ------------------
> 
> Increase PNP_MAX_PORT. ACPI devices can have a lot IO resource declarations
> 
> Also print a message if PNP_DEBUG is set if we run out of PNP_MAX_PORTS.
> 
> Signed-off-by: Thomas Renninger <trenn@suse.de>
> 
> ---
>  drivers/pnp/pnpacpi/rsparser.c |    3 ++-
>  include/linux/pnp.h            |    2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.22.1/include/linux/pnp.h
> ===================================================================
> --- linux-2.6.22.1.orig/include/linux/pnp.h
> +++ linux-2.6.22.1/include/linux/pnp.h
> @@ -14,7 +14,7 @@
>  #include <linux/errno.h>
>  #include <linux/mod_devicetable.h>
>  
> -#define PNP_MAX_PORT		8
> +#define PNP_MAX_PORT		32
>  #define PNP_MAX_MEM		4
>  #define PNP_MAX_IRQ		2
>  #define PNP_MAX_DMA		2
> Index: linux-2.6.22.1/drivers/pnp/pnpacpi/rsparser.c
> ===================================================================
> --- linux-2.6.22.1.orig/drivers/pnp/pnpacpi/rsparser.c
> +++ linux-2.6.22.1/drivers/pnp/pnpacpi/rsparser.c
> @@ -185,7 +185,8 @@ pnpacpi_parse_allocated_ioresource(struc
>  		}
>  		res->port_resource[i].start = io;
>  		res->port_resource[i].end = io + len - 1;
> -	}
> +	} else
> +		pnp_dbg("Run out of pnp ports - MAX_PNP_PORT must be increased");

PNP_MAX_PORT, not MAX_PNP_PORT.

>  }
>  
>  static void

I like this patch and I'd like to see it upstream soon. I think it can
even be improved:

* If we run out of pnp ports, we should print an error message rather
than a debug message. If it takes CONFIG_PNP_DEBUG=y to get reports
that the max is too low, we won't have many reports.

* Can we have similar messages for PNP_MAX_MEM, PNP_MAX_IRQ and
PNP_MAX_DMA? I think that we really want to know when we hit limits for
these too.

Thanks,
-- 
Jean Delvare

  reply	other threads:[~2007-07-16 16:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-16 14:21 [PATCH] - Increase PNP_MAX_PORT. ACPI devices can have a lot IO resource declarations Thomas Renninger
2007-07-16 16:48 ` Jean Delvare [this message]
2007-07-17 15:49 ` Bjorn Helgaas
2007-07-18  8:21   ` Thomas Renninger
2007-07-18 21:33     ` Bjorn Helgaas
2007-07-19  9:23       ` Thomas Renninger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070716184856.253203d8@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=aystarik@gmail.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=bwalle@suse.de \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trenn@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox