This is already fixed in the most recent ACPI CPUIDLE tree.
Thanks,
Adam
On Mon, 2007-08-27 at 23:27 +0200, Adrian Bunk wrote:
> On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.23-rc2-mm2:
> >...
> > git-acpi.patch
> >...
> > git trees
> >...
>
>
This is already fixed in the most recent ACPI CPUIDLE tree.
Thanks,
Adam
On Mon, 2007-08-27 at 23:27 +0200, Adrian Bunk wrote:
On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
...
Changes since 2.6.23-rc2-mm2:
...
git-acpi.patch
...
git trees
...
struct
On Tue, 2007-04-10 at 15:20 -0700, Venki Pallipadi wrote:
> On Mon, Apr 09, 2007 at 07:40:52PM +0200, Rafael J. Wysocki wrote:
> > On Monday, 9 April 2007 18:14, Pallipadi, Venkatesh wrote:
> > >
> > > >-Original Message-
> > > >From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
> > >
On Tue, 2007-04-10 at 15:20 -0700, Venki Pallipadi wrote:
On Mon, Apr 09, 2007 at 07:40:52PM +0200, Rafael J. Wysocki wrote:
On Monday, 9 April 2007 18:14, Pallipadi, Venkatesh wrote:
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Monday, April
On Mon, 2007-03-26 at 13:36 +0800, Shaohua Li wrote:
> Hi,
> On Sat, 2007-03-24 at 03:47 -0400, Adam Belay wrote:
> > This patch adds the 'menu' governor, as was described in my first email.
> >
>
> > +/**
> > + * menu_select - selects the next idle sta
On Mon, 2007-03-26 at 13:36 +0800, Shaohua Li wrote:
Hi,
On Sat, 2007-03-24 at 03:47 -0400, Adam Belay wrote:
This patch adds the 'menu' governor, as was described in my first email.
+/**
+ * menu_select - selects the next idle state to enter
+ * @dev: the CPU
+ */
+static int
This patch exposes information about the time remaining until the next
timer interrupt expires by utilizing the dynticks infrastructure. It
also modifies the main idle loop to allow dynticks to handle
non-interrupt break events (e.g. DMA). Finally, it exposes sleep ticks
information to external
- the menu idle governor
+ *
+ * Copyright (C) 2006-2007 Adam Belay <[EMAIL PROTECTED]>
+ *
+ * This code is licenced under the GPL.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BM_HOLDOFF 2 /* 20 ms */
+
+struct menu_device {
+
Hi All,
Here is my first take at implementing an idle PM governor that takes
full advantage of NO_HZ. I call it the 'menu' governor because it
considers the full list of idle states before each entry.
I've kept the implementation fairly simple. It attempts to guess the
next residency time and
This patch prepares cpuidle for the menu governor. It adds an optional
stage after idle state entry to give the governor an opportunity to
check why the state was exited. Also it makes sure the idle loop
returns after each state entry, allowing the appropriate dynticks code
to run.
Thanks,
Adam
Hi All,
Here is my first take at implementing an idle PM governor that takes
full advantage of NO_HZ. I call it the 'menu' governor because it
considers the full list of idle states before each entry.
I've kept the implementation fairly simple. It attempts to guess the
next residency time and
This patch prepares cpuidle for the menu governor. It adds an optional
stage after idle state entry to give the governor an opportunity to
check why the state was exited. Also it makes sure the idle loop
returns after each state entry, allowing the appropriate dynticks code
to run.
Thanks,
Adam
This patch exposes information about the time remaining until the next
timer interrupt expires by utilizing the dynticks infrastructure. It
also modifies the main idle loop to allow dynticks to handle
non-interrupt break events (e.g. DMA). Finally, it exposes sleep ticks
information to external
- the menu idle governor
+ *
+ * Copyright (C) 2006-2007 Adam Belay [EMAIL PROTECTED]
+ *
+ * This code is licenced under the GPL.
+ */
+
+#include linux/kernel.h
+#include linux/cpuidle.h
+#include linux/latency.h
+#include linux/time.h
+#include linux/ktime.h
+#include linux/tick.h
+#include linux
p, server,
> > > laptop on battery etc).
> > > Main advantage of the infrastructure being, it allows independent
> > development
> > > of drivers and governors and allows for better CPU power management.
> > >
> > > A huge thanks to Adam Belay and Shao
for better CPU power management.
A huge thanks to Adam Belay and Shaohua Li who were part of this
mini-project
since its beginning and are greatly responsible for this patchset.
interesting. Though I wonder about giving admins _more_ knobs to twiddle.
It took cpufreq a long time
On Mon, Aug 08, 2005 at 09:00:21AM -0700, Greg KH wrote:
> On Mon, Aug 08, 2005 at 11:11:45AM -0700, Matthew Gilbert wrote:
> > Below is a patch that adds an additional resource class to the platform
> > resource types. This is to support additional resources that need to be
> > passed
> > to
On Mon, Aug 08, 2005 at 09:00:21AM -0700, Greg KH wrote:
On Mon, Aug 08, 2005 at 11:11:45AM -0700, Matthew Gilbert wrote:
Below is a patch that adds an additional resource class to the platform
resource types. This is to support additional resources that need to be
passed
to drivers
On Fri, 2005-07-15 at 09:58 +0100, Russell King wrote:
> On Thu, Jul 14, 2005 at 04:55:19AM -0400, Adam Belay wrote:
> > This patch adds a basic PCI<->PCI bridge driver that utilizes the new
> > PCI bus class API.
>
> Thanks. I think this breaks Cardbus.
>
&g
On Fri, 2005-07-15 at 09:58 +0100, Russell King wrote:
On Thu, Jul 14, 2005 at 04:55:19AM -0400, Adam Belay wrote:
This patch adds a basic PCI-PCI bridge driver that utilizes the new
PCI bus class API.
Thanks. I think this breaks Cardbus.
The whole point of the way PCI is _presently_
On Thu, 2005-07-14 at 12:30 -0700, Greg KH wrote:
> On Thu, Jul 14, 2005 at 07:10:14PM +0200, Francois Romieu wrote:
> > Adam Belay <[EMAIL PROTECTED]> :
> > [...]
> >
> > Some nits + a suspect error branch. It seems nice otherwise.
>
> If I'm
On Thu, 2005-07-14 at 12:33 -0700, Greg KH wrote:
> On Thu, Jul 14, 2005 at 04:55:12AM -0400, Adam Belay wrote:
> > +EXPORT_SYMBOL(pci_add_bus);
>
> This doens't need to be exported, right? No module uses it. But if
> they do, I suggest EXPORT_SYMBOL_GPL() instead, is th
This patch prevents the PCI<->PCI bridge driver from binding to PCI
express devices. This is needed to coexist with the PCI express root
port driver. Eventually we may want to rework and better integrate
linux PCI express link support, but for now this should work.
Signed-off-by: Adam
The PCI bridge driver now checks if changing bridge_ctrl is necessary.
It also restores the original bridge_ctl settings when finished scanning
for devices. Finally, a pci_bus setup fix is included.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/pci-bridge.c 2005
to the PCI bus class driver and PCI device
detection in general.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/Makefile 2005-07-08 17:06:19.0 -0400
+++ b/drivers/pci/Makefile 2005-07-10 22:32:53.0 -0400
@@ -2,9 +2,9 @@
# Makefile for the PCI bus
This patch prevents the root bridge drivers from using the legacy API.
It also updates the PCI<->PCI bridge driver to better coexist with the
legacy code.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/pci-bridge.c 2005-07-14 02:17:04.735566464 -0400
+++ b
This patch adds a basic PCI<->PCI bridge driver that utilizes the new
PCI bus class API.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/pci-bridge.c 1969-12-31 19:00:00.0 -0500
+++ b/drivers/pci/bus/pci-bridge.c 2005-07-08 02:18:43.0 -
This patch moves all device registration related functions to
bus/device.c.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/device.c 1969-12-31 19:00:00.0 -0500
+++ b/drivers/pci/bus/device.c 2005-07-12 01:32:41.0 -0400
@@ -0,0 +1,187 @@
+/*
+ * de
This patch adds pci_add_bus() for PCI bus registration. It also moves
pci_remove_bus() from remove.c to bus/bus.c for consistency.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/bus.c 2005-07-12 00:59:58.0 -0400
+++ b/drivers/pci/bus/bus.c 2005-07-12
This patch updates pci_scan_bus_parented() and also has some important
fixes to the PCI bus class.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/bus.c 2005-07-12 01:08:20.0 -0400
+++ b/drivers/pci/bus/bus.c 2005-07-13 02:01:57.0 -0400
@@ -81,7
This patch adds very simplistic suspend/resume support for the PCI
bridge driver. Soon this will be replaced with bridge specific code,
but for now we'll try using pci_save/restore_state().
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/pci-bridge.c 2005-07-14
Hi all,
I'm in the process of overhauling some aspects of the PCI subsystem.
This patch series is a rewrite of the PCI probing and detection code.
It creates a well defined PCI bus class API and allows a standard PCI
driver to bind to PCI bridge devices. This results in the following:
* cleaner
Hi all,
I'm in the process of overhauling some aspects of the PCI subsystem.
This patch series is a rewrite of the PCI probing and detection code.
It creates a well defined PCI bus class API and allows a standard PCI
driver to bind to PCI bridge devices. This results in the following:
* cleaner
This patch adds very simplistic suspend/resume support for the PCI
bridge driver. Soon this will be replaced with bridge specific code,
but for now we'll try using pci_save/restore_state().
Signed-off-by: Adam Belay [EMAIL PROTECTED]
--- a/drivers/pci/bus/pci-bridge.c 2005-07-14 04:22
This patch updates pci_scan_bus_parented() and also has some important
fixes to the PCI bus class.
Signed-off-by: Adam Belay [EMAIL PROTECTED]
--- a/drivers/pci/bus/bus.c 2005-07-12 01:08:20.0 -0400
+++ b/drivers/pci/bus/bus.c 2005-07-13 02:01:57.0 -0400
@@ -81,7 +81,7
This patch adds pci_add_bus() for PCI bus registration. It also moves
pci_remove_bus() from remove.c to bus/bus.c for consistency.
Signed-off-by: Adam Belay [EMAIL PROTECTED]
--- a/drivers/pci/bus/bus.c 2005-07-12 00:59:58.0 -0400
+++ b/drivers/pci/bus/bus.c 2005-07-12 01:01
This patch moves all device registration related functions to
bus/device.c.
Signed-off-by: Adam Belay [EMAIL PROTECTED]
--- a/drivers/pci/bus/device.c 1969-12-31 19:00:00.0 -0500
+++ b/drivers/pci/bus/device.c 2005-07-12 01:32:41.0 -0400
@@ -0,0 +1,187 @@
+/*
+ * device.c - PCI
This patch adds a basic PCI-PCI bridge driver that utilizes the new
PCI bus class API.
Signed-off-by: Adam Belay [EMAIL PROTECTED]
--- a/drivers/pci/bus/pci-bridge.c 1969-12-31 19:00:00.0 -0500
+++ b/drivers/pci/bus/pci-bridge.c 2005-07-08 02:18:43.0 -0400
@@ -0,0
bus class driver and PCI device
detection in general.
Signed-off-by: Adam Belay [EMAIL PROTECTED]
--- a/drivers/pci/Makefile 2005-07-08 17:06:19.0 -0400
+++ b/drivers/pci/Makefile 2005-07-10 22:32:53.0 -0400
@@ -2,9 +2,9 @@
# Makefile for the PCI bus specific drivers
The PCI bridge driver now checks if changing bridge_ctrl is necessary.
It also restores the original bridge_ctl settings when finished scanning
for devices. Finally, a pci_bus setup fix is included.
Signed-off-by: Adam Belay [EMAIL PROTECTED]
--- a/drivers/pci/bus/pci-bridge.c 2005-07-12
This patch prevents the PCI-PCI bridge driver from binding to PCI
express devices. This is needed to coexist with the PCI express root
port driver. Eventually we may want to rework and better integrate
linux PCI express link support, but for now this should work.
Signed-off-by: Adam Belay
On Thu, 2005-07-14 at 12:33 -0700, Greg KH wrote:
On Thu, Jul 14, 2005 at 04:55:12AM -0400, Adam Belay wrote:
+EXPORT_SYMBOL(pci_add_bus);
This doens't need to be exported, right? No module uses it. But if
they do, I suggest EXPORT_SYMBOL_GPL() instead, is that ok?
thanks,
greg k-h
On Thu, 2005-07-14 at 12:30 -0700, Greg KH wrote:
On Thu, Jul 14, 2005 at 07:10:14PM +0200, Francois Romieu wrote:
Adam Belay [EMAIL PROTECTED] :
[...]
Some nits + a suspect error branch. It seems nice otherwise.
If I'm correct, this patch only moves the code into different files
On Fri, Jul 08, 2005 at 02:34:56PM -0400, John W. Linville wrote:
> Some PCI devices lose all configuration (including BARs) when
> transitioning from D3hot->D0. This leaves such a device in an
> inaccessible state. The patch below causes the BARs to be restored
> when enabling such a device, so
On Thu, Jun 16, 2005 at 11:37:30PM +0100, James Courtier-Dutton wrote:
> Hi,
>
> I have tried conacting the mailing list for the PCMCIA subsystem in
> Linux, but no-one seems to respond.
>
> PCMCIA SUBSYSTEM
> L: http://lists.infradead.org/mailman/listinfo/linux-pcmcia
> S:
On Thu, Jun 16, 2005 at 11:37:30PM +0100, James Courtier-Dutton wrote:
Hi,
I have tried conacting the mailing list for the PCMCIA subsystem in
Linux, but no-one seems to respond.
PCMCIA SUBSYSTEM
L: http://lists.infradead.org/mailman/listinfo/linux-pcmcia
S: Unmaintained
I
On Fri, Jul 08, 2005 at 02:34:56PM -0400, John W. Linville wrote:
Some PCI devices lose all configuration (including BARs) when
transitioning from D3hot-D0. This leaves such a device in an
inaccessible state. The patch below causes the BARs to be restored
when enabling such a device, so that
On Sat, Apr 09, 2005 at 08:03:52PM +0200, Adrian Bunk wrote:
> This patch fixes an array overflow found by the Coverity checker.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
Looks good.
Thanks,
Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Sat, Apr 09, 2005 at 08:03:52PM +0200, Adrian Bunk wrote:
This patch fixes an array overflow found by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Looks good.
Thanks,
Adam
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Tue, 2005-04-05 at 11:24 +0200, Pavel Machek wrote:
> Hi!
>
> > > You have a few things here that can easily conflict, and that will be
> > > developed at different paces. I like the direction that it's going, but
> > > how do you intend to do it gradually. I.e. what to do first?
> >
> > I
On Tue, 2005-04-05 at 11:24 +0200, Pavel Machek wrote:
Hi!
You have a few things here that can easily conflict, and that will be
developed at different paces. I like the direction that it's going, but
how do you intend to do it gradually. I.e. what to do first?
I think the first
On Mon, Apr 04, 2005 at 12:56:32PM -0700, Randy.Dunlap wrote:
> maximilian attems wrote:
> >one of the last buildcheck errors on i386,
> >thanks Randy again for double checking.
> >
> >Fix pnpbios section references:
> >make dmi_system_id pnpbios_dmi_table __initdata
> >
> >Error:
On Mon, Apr 04, 2005 at 12:56:32PM -0700, Randy.Dunlap wrote:
maximilian attems wrote:
one of the last buildcheck errors on i386,
thanks Randy again for double checking.
Fix pnpbios section references:
make dmi_system_id pnpbios_dmi_table __initdata
Error: ./drivers/pnp/pnpbios/core.o
On Sat, Apr 02, 2005 at 01:04:33PM -0500, Marty Leisner wrote:
> I have to write some code to insert a non-standard bridge
> (it identifies itself as bridge-other, but it functions
> as a pci-pci bridge).
>
> I'm going to be using 2.4.2x and eventually 2.6.x for intel
> and ppc...
I'm currently
On Sat, Apr 02, 2005 at 01:04:33PM -0500, Marty Leisner wrote:
I have to write some code to insert a non-standard bridge
(it identifies itself as bridge-other, but it functions
as a pci-pci bridge).
I'm going to be using 2.4.2x and eventually 2.6.x for intel
and ppc...
I'm currently
Dynamic power management may require devices and drivers to transition
between various physical and logical states. I would like to start a
discussion on how these might be defined at the bus, driver, and class
levels.
Bus Level
=
At the bus level, there are two state attributes, power
On Sun, 2005-03-27 at 23:43 +0200, Dominik Brodowski wrote:
> On Sun, Mar 27, 2005 at 04:27:24PM -0500, Adam Belay wrote:
> > > extern int device_create_file(struct device *device, struct
> > > device_attribute
> > > * entry);
> > > and delete them (e.
One of the original design goals of sysfs was to provide a standardized
location to keep driver configuration attributes. Although sysfs
handles this very well for bus devices and class devices, there isn't
currently a method to export attributes for device drivers and their
specific bound device
One of the original design goals of sysfs was to provide a standardized
location to keep driver configuration attributes. Although sysfs
handles this very well for bus devices and class devices, there isn't
currently a method to export attributes for device drivers and their
specific bound device
On Sun, 2005-03-27 at 23:43 +0200, Dominik Brodowski wrote:
On Sun, Mar 27, 2005 at 04:27:24PM -0500, Adam Belay wrote:
extern int device_create_file(struct device *device, struct
device_attribute
* entry);
and delete them (e.g. in -remove) using
extern void device_remove_file
Dynamic power management may require devices and drivers to transition
between various physical and logical states. I would like to start a
discussion on how these might be defined at the bus, driver, and class
levels.
Bus Level
=
At the bus level, there are two state attributes, power
On Mon, 2005-03-21 at 19:32, Andrew Morton wrote:
> Adam Belay <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2005-03-11 at 17:35 -0800, Andrew Morton wrote:
> > > Felix von Leitner <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Finally Centrino
On Mon, 2005-03-21 at 19:32, Andrew Morton wrote:
Adam Belay [EMAIL PROTECTED] wrote:
On Fri, 2005-03-11 at 17:35 -0800, Andrew Morton wrote:
Felix von Leitner [EMAIL PROTECTED] wrote:
Finally Centrino SpeedStep.
I have a Intel(R) Pentium(R) M processor 1.80GHz in my notebook
On Fri, 2005-03-11 at 17:35 -0800, Andrew Morton wrote:
> Felix von Leitner <[EMAIL PROTECTED]> wrote:
> >
> > Finally Centrino SpeedStep.
> > I have a "Intel(R) Pentium(R) M processor 1.80GHz" in my notebook.
> > Linux does not support it. This architecture has been out there for
> > months now,
On Fri, 2005-03-11 at 20:21 +, Felix von Leitner wrote:
> Linux is getting less and less usable for me. :-(
>
>
> My new nForce 4 mainboard has 10 or so USB 2.0 outlets. In Windows,
> they all work. In Linux, two of them work. Putting my USB stick or
> anything else in one of the others
On Sun, 2005-02-20 at 09:23 -0800, Linus Torvalds wrote:
>
> On Sun, 20 Feb 2005, Russell King wrote:
> > On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
> > > BIOS-e820: - 0009f000 (usable)
> > > BIOS-e820: 0009f000 - 000a (reserved)
On Sat, 2005-02-19 at 20:02 -0800, Linus Torvalds wrote:
>
> On Sat, 19 Feb 2005, Steven Rostedt wrote:
> >
> > On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
> >
> > > I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
> > >
> > > static void __devinit
> So in short, I'd rather not remove them, because they take away from the
> original design of the PnP layer.
s/they/it would
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 2005-03-11 at 16:23 -0800, Andrew Morton wrote:
> Adam Belay <[EMAIL PROTECTED]> wrote:
> >
> > This patch essential makes it impossible for PnP protocols to be
> > modules. Currently, they are all in-kernel. If that is acceptable...,
> > then this patc
This patch essential makes it impossible for PnP protocols to be
modules. Currently, they are all in-kernel. If that is acceptable...,
then this patch looks fine to me. Any comments?
Thanks,
Adam
On Fri, 2005-03-11 at 19:16 +0100, Adrian Bunk wrote:
> This patch contains the following
This patch essential makes it impossible for PnP protocols to be
modules. Currently, they are all in-kernel. If that is acceptable...,
then this patch looks fine to me. Any comments?
Thanks,
Adam
On Fri, 2005-03-11 at 19:16 +0100, Adrian Bunk wrote:
This patch contains the following possible
On Fri, 2005-03-11 at 16:23 -0800, Andrew Morton wrote:
Adam Belay [EMAIL PROTECTED] wrote:
This patch essential makes it impossible for PnP protocols to be
modules. Currently, they are all in-kernel. If that is acceptable...,
then this patch looks fine to me. Any comments?
You're
So in short, I'd rather not remove them, because they take away from the
original design of the PnP layer.
s/they/it would
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sat, 2005-02-19 at 20:02 -0800, Linus Torvalds wrote:
On Sat, 19 Feb 2005, Steven Rostedt wrote:
On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
static void __devinit
On Sun, 2005-02-20 at 09:23 -0800, Linus Torvalds wrote:
On Sun, 20 Feb 2005, Russell King wrote:
On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
BIOS-e820: - 0009f000 (usable)
BIOS-e820: 0009f000 - 000a (reserved)
On Fri, 2005-03-11 at 20:21 +, Felix von Leitner wrote:
Linux is getting less and less usable for me. :-(
My new nForce 4 mainboard has 10 or so USB 2.0 outlets. In Windows,
they all work. In Linux, two of them work. Putting my USB stick or
anything else in one of the others
On Fri, 2005-03-11 at 17:35 -0800, Andrew Morton wrote:
Felix von Leitner [EMAIL PROTECTED] wrote:
Finally Centrino SpeedStep.
I have a Intel(R) Pentium(R) M processor 1.80GHz in my notebook.
Linux does not support it. This architecture has been out there for
months now, and there even
On Mon, 2005-03-07 at 18:03 -0500, Jon Smirl wrote:
> What about a bridge driver for ISA LPC bridges? That would also
> provide a logical place to hang serial ports, floppy, parallel port,
> ps2 port, etc. Things in /sys/bus/platform are really attached to the
> LPC bridge.
>
I agree that
On Mon, 2005-03-07 at 15:43 -0800, Jesse Barnes wrote:
> On Monday, March 7, 2005 3:39 pm, Jon Smirl wrote:
> > How is sys/bus/platform/* going to work for IA64 machine line SGI SVN?
> > SVN supports multiple simultaneously active legacy spaces, that means
> > that there can be multiple floppy,
On Fri, Feb 18, 2005 at 08:49:58AM +0100, Matthias Urlichs wrote:
> Hi,
>
> we have a bunch of systems which semi-reproducibly (chance of 1:1000) hang
> when a PCMCIA card is removed from its PCI->PCMCIA interface via "cardctl
> eject". Right *here*, in fact:
>
> static int pci_conf1_read (int
On Fri, Feb 18, 2005 at 08:49:58AM +0100, Matthias Urlichs wrote:
Hi,
we have a bunch of systems which semi-reproducibly (chance of 1:1000) hang
when a PCMCIA card is removed from its PCI-PCMCIA interface via cardctl
eject. Right *here*, in fact:
static int pci_conf1_read (int seg, int
On Mon, 2005-03-07 at 15:43 -0800, Jesse Barnes wrote:
On Monday, March 7, 2005 3:39 pm, Jon Smirl wrote:
How is sys/bus/platform/* going to work for IA64 machine line SGI SVN?
SVN supports multiple simultaneously active legacy spaces, that means
that there can be multiple floppy, serial,
On Mon, 2005-03-07 at 18:03 -0500, Jon Smirl wrote:
What about a bridge driver for ISA LPC bridges? That would also
provide a logical place to hang serial ports, floppy, parallel port,
ps2 port, etc. Things in /sys/bus/platform are really attached to the
LPC bridge.
I agree that
On Mon, 2005-02-28 at 15:38 -0800, Jesse Barnes wrote:
> On Monday, February 28, 2005 3:27 pm, Adam Belay wrote:
> > How can we specify which bus to target?
>
> Maybe we could have a list of legacy (ISA?) devices for drivers like vgacon
> to
> attach to? The bus
On Fri, 2005-02-25 at 15:41 -0800, Greg KH wrote:
> On Thu, Feb 10, 2005 at 04:37:03PM -0500, Adam Belay wrote:
> > On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
> > > On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > > > > I think the i
On Fri, 2005-02-25 at 15:38 -0800, Greg KH wrote:
> On Thu, Feb 24, 2005 at 01:22:01AM -0500, Adam Belay wrote:
> > I look forward to any comments or suggestions.
>
> I like it all :)
>
> If you want to submit patches now that rearrange the code to make it
>
On Thu, 2005-02-24 at 10:03 +, Russell King wrote:
> On Thu, Feb 24, 2005 at 01:22:01AM -0500, Adam Belay wrote:
> > 5.) write a bridge driver for Cardbus hardware
>
> We have this already - it's called "yenta".
Yes, I'm aware. It should read:
5.) adapt the Yenta
On Thu, 2005-02-24 at 02:25 -0500, Jon Smirl wrote:
> When you start writing the PCI root bridge driver you'll run into the
> AGP drivers that are already attached to the bridge. I was surprised
> by this since I expected AGP to be attached to the AGP bridge but now
> I learned that it is a root
On Thu, 2005-02-24 at 15:02 -0800, Jesse Barnes wrote:
> On Wednesday, February 23, 2005 11:03 pm, Adam Belay wrote:
>
> > > Jesse can comment on the specific support needed for multiple legacy IO
> > > spaces.
> >
> > That would be great. Most of my ex
On Thu, 2005-02-24 at 15:02 -0800, Jesse Barnes wrote:
On Wednesday, February 23, 2005 11:03 pm, Adam Belay wrote:
Jesse can comment on the specific support needed for multiple legacy IO
spaces.
That would be great. Most of my experience has been with only a couple
legacy IO port
On Thu, 2005-02-24 at 02:25 -0500, Jon Smirl wrote:
When you start writing the PCI root bridge driver you'll run into the
AGP drivers that are already attached to the bridge. I was surprised
by this since I expected AGP to be attached to the AGP bridge but now
I learned that it is a root
On Thu, 2005-02-24 at 10:03 +, Russell King wrote:
On Thu, Feb 24, 2005 at 01:22:01AM -0500, Adam Belay wrote:
5.) write a bridge driver for Cardbus hardware
We have this already - it's called yenta.
Yes, I'm aware. It should read:
5.) adapt the Yenta driver to the new PCI bus class
On Fri, 2005-02-25 at 15:38 -0800, Greg KH wrote:
On Thu, Feb 24, 2005 at 01:22:01AM -0500, Adam Belay wrote:
I look forward to any comments or suggestions.
I like it all :)
If you want to submit patches now that rearrange the code to make it
easier for you to modify in the future
On Fri, 2005-02-25 at 15:41 -0800, Greg KH wrote:
On Thu, Feb 10, 2005 at 04:37:03PM -0500, Adam Belay wrote:
On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
I think the issue that Al raises about drivers grabbing
On Mon, 2005-02-28 at 15:38 -0800, Jesse Barnes wrote:
On Monday, February 28, 2005 3:27 pm, Adam Belay wrote:
How can we specify which bus to target?
Maybe we could have a list of legacy (ISA?) devices for drivers like vgacon
to
attach to? The bus info could be stuffed into the legacy
On Thu, 2005-02-24 at 01:45 -0500, Jon Smirl wrote:
> On Thu, 24 Feb 2005 01:22:01 -0500, Adam Belay <[EMAIL PROTECTED]> wrote:
> > For the past couple weeks I have been reorganizing the PCI subsystem to
> > better utilize the driver model. Specifically, the bus detection
Hi all,
For the past couple weeks I have been reorganizing the PCI subsystem to
better utilize the driver model. Specifically, the bus detection code
is now using a standard PCI driver. It turns out to be a major
undertaking, as the PCI probing code is closely tied into a lot of other
PCI
Hi all,
For the past couple weeks I have been reorganizing the PCI subsystem to
better utilize the driver model. Specifically, the bus detection code
is now using a standard PCI driver. It turns out to be a major
undertaking, as the PCI probing code is closely tied into a lot of other
PCI
On Thu, 2005-02-24 at 01:45 -0500, Jon Smirl wrote:
On Thu, 24 Feb 2005 01:22:01 -0500, Adam Belay [EMAIL PROTECTED] wrote:
For the past couple weeks I have been reorganizing the PCI subsystem to
better utilize the driver model. Specifically, the bus detection code
is now using a standard
On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
> On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > > I think the issue that Al raises about drivers grabbing devices, and
> > > then trying to unbind them might be a real problem.
> >
> > I
1 - 100 of 129 matches
Mail list logo
