On Mon, 31 Jan 2005 22:38:17 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> Ick, patch wasn't inline for me to comment on it :(
Here's the patch inline. Big things that need to be addressed...
1) Generating the user space reset event. I tried using the pci
hotplug event but ran into the fb blacklist
On Thu, Jan 27, 2005 at 04:59:45AM -0500, Jon Smirl wrote:
> On Mon, 24 Jan 2005 20:24:59 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > This can be done today in the bus specific match functions. And because
> > of that, I would argue that this belongs in the bus specific code, and
> > not in the
On Gwe, 2005-01-28 at 20:00, Matthew Wilcox wrote:
> Possibly a better solution (less likely to break things) would be to allow
> drivers to reserve the 10-bit aliases too. Something like this:
>
> static inline void request_isa_alias_regions(unsigned long start,
> unsigned long n
On Mon, 24 Jan 2005 20:24:59 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> And yes, I agree that this needs to be done, I've been talking with a
> few other people who are interested in it. I think the lock-rework code
> needs to be finished before it can happen properly, so that we can do
> the "un
On Fri, Jan 28, 2005 at 08:00:10PM +, Matthew Wilcox wrote:
> I've been thinking for a while that we should mark the 10-bit aliases
> of ISA devices as used
ISTR that windows does this.
> Russell, would that allay your issues with the kernel io resource database?
It makes the situation a who
On Fri, Jan 28, 2005 at 12:33:20PM -0700, Grant Grundler wrote:
> > > If it is intended to work with multiple IO Port address spaces,
> > > then it needs to use the pci_dev->resource[] and mangle that
> > > appropriately.
> >
> > There is no resource for some of the I/O port space that cards resp
On Fri, Jan 28, 2005 at 11:41:16AM -0800, Jesse Barnes wrote:
> Yeah, I think I understand. We could probably do the same thing on sn2
> as you do on parisc--add a 'segment 0' offset to the port so that it's routed
> correctly. I think that's a little less flexible than adding a new resource
>
On Fri, Jan 28, 2005 at 10:41:41AM -0800, Jesse Barnes wrote:
> > Eh?! there can only be *one* legacy I/O space.
> > We can support multipl IO port spaces, but only one can be the "legacy".
>
> What do you mean? If you define legacy I/O space to be
> 0x-0x, then y
On Friday, January 28, 2005 11:33 am, Grant Grundler wrote:
> > But
> > if you mean being able to access legacy ports at all, then no. On SGI
> > machines, there's a per-bus base address that can be used as the base for
> > port I/O, which is what I was getting at.
>
> Ok - my point was "0x3fc" wi
On Fri, Jan 28, 2005 at 02:26:40PM -0500, Jon Smirl wrote:
> Next year we are going to see a lot of multiple VGAs. Depending on
> configuration the Nvidia4 chipset can support from one up to eight PCI
> Express video cards simultaneously.
Oh geezsomeone is going to implement IO port space on P
On Fri, 28 Jan 2005 12:15:49 -0700, Grant Grundler
<[EMAIL PROTECTED]> wrote:
> I don't care if it gets fixed (or not) since I don't use
> or need to support multiple VGA cards. If someone else (in
Next year we are going to see a lot of multiple VGAs. Depending on
configuration the Nvidia4 chipset
On Fri, Jan 28, 2005 at 01:36:48PM -0500, Jon Smirl wrote:
> > If it is intended to work with multiple IO Port address spaces,
> > then it needs to use the pci_dev->resource[] and mangle that appropriately.
>
> Post a patch an I will incorporate it.
Sorry - I only wanted to point out the short c
On Fri, 28 Jan 2005 10:32:22 -0700, Grant Grundler
<[EMAIL PROTECTED]> wrote:
> Moving the VGA device can only function within that legacy space
> the way the code is written now (using hard coded addresses).
> If it is intended to work with multiple IO Port address spaces,
> then it needs to use t
On Friday, January 28, 2005 9:32 am, Grant Grundler wrote:
> On Thu, Jan 27, 2005 at 08:28:43AM -0800, Jesse Barnes wrote:
> > But then again,
> > I suppose if a platform supports more than one legacy I/O space,
>
> Eh?! there can only be *one* legacy I/O space.
> We can support multipl IO port spa
On Thu, Jan 27, 2005 at 08:28:43AM -0800, Jesse Barnes wrote:
> But then again,
> I suppose if a platform supports more than one legacy I/O space,
Eh?! there can only be *one* legacy I/O space.
We can support multipl IO port spaces, but only one can be the "legacy".
Moving the VGA device can only
On Thursday, January 27, 2005 1:59 am, Jon Smirl wrote:
> Another item I need to add is generating an initial hotplug event for
> each secondary card. This event has to happen even if there is a card
> specific driver loaded. The event will be used to run the reset
> program needed by secondary car
On Mon, 24 Jan 2005 20:24:59 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> This can be done today in the bus specific match functions. And because
> of that, I would argue that this belongs in the bus specific code, and
> not in the driver core, as it's up to the bus to know what the different
> typ
On Mon, Jan 24, 2005 at 07:55:23PM +, Russell King wrote:
> On Mon, Jan 24, 2005 at 02:42:57PM -0500, Jeff Garzik wrote:
> > Jon Smirl wrote:
> > > Is this a justification for doing device drivers for bridge chips? It
> > > has been mentioned before but no one has done it.
> >
> >
> > Yeah, p
On Mon, 24 Jan 2005 19:55:23 +, Russell King
<[EMAIL PROTECTED]> wrote:
> There's a very good reason not to have a bridge driver at the moment -
> some PCI to PCI bridges need special drivers. Currently, as the device
> model stands today, we can only have ONE PCI to PCI bridge driver for
> al
On Mon, Jan 24, 2005 at 02:17:15PM -0500, Jon Smirl wrote:
> On Mon, 24 Jan 2005 17:51:31 +, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> > Yes -- *very* platform specific. Some are even configurable as to how
> > much they support. See http://ftp.parisc-linux.org/docs/chips/zx1-mio.pdf
>
> I
On Mon, Jan 24, 2005 at 02:42:57PM -0500, Jeff Garzik wrote:
> Jon Smirl wrote:
> >Is this a justification for doing device drivers for bridge chips? It
> >has been mentioned before but no one has done it.
>
> Yeah, people are usually slack and work around the problem.
>
> A bridge driver is real
On Mon, Jan 24, 2005 at 02:42:57PM -0500, Jeff Garzik wrote:
> Jon Smirl wrote:
> > Is this a justification for doing device drivers for bridge chips? It
> > has been mentioned before but no one has done it.
>
>
> Yeah, people are usually slack and work around the problem.
>
> A bridge driver is
Jon Smirl wrote:
Is this a justification for doing device drivers for bridge chips? It
has been mentioned before but no one has done it.
Yeah, people are usually slack and work around the problem.
A bridge driver is really wanted for several situations in today's
hardware...
Jeff
-
To un
On Mon, 24 Jan 2005 17:51:31 +, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> Yes -- *very* platform specific. Some are even configurable as to how
> much they support. See http://ftp.parisc-linux.org/docs/chips/zx1-mio.pdf
Is this a justification for doing device drivers for bridge chips? It
On Monday, January 24, 2005 9:25 am, Jesse Barnes wrote:
> On Saturday, January 22, 2005 11:04 am, Jon Smirl wrote:
> > > Well, not all of them, which is why I asked. Though obviously this
> > > patch will need some very platform specific bits at any rate.
> >
> > What is a case of where the VGA f
On Saturday, January 22, 2005 11:04 am, Jon Smirl wrote:
> > Well, not all of them, which is why I asked. Though obviously this patch
> > will need some very platform specific bits at any rate.
>
> What is a case of where the VGA forwarding bit isn't in the bridge
> control? It's part of the PCI s
On Tue, 18 Jan 2005 13:06:03 -0800, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Tuesday, January 18, 2005 11:38 am, H. Peter Anvin wrote:
> > > On Monday, January 17, 2005 7:43 pm, Jon Smirl wrote:
> > > > Attached is a patch to control VGA bus routing and the active VGA
> > > > device. It works b
On Tuesday, January 18, 2005 11:38 am, H. Peter Anvin wrote:
> > On Monday, January 17, 2005 7:43 pm, Jon Smirl wrote:
> > > Attached is a patch to control VGA bus routing and the active VGA
> > > device. It works by adding sysfs attributes to bridge and VGA devices.
> > > The bridge attribute is r
Followup to: <[EMAIL PROTECTED]>
By author:Jesse Barnes <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Monday, January 17, 2005 7:43 pm, Jon Smirl wrote:
> > Attached is a patch to control VGA bus routing and the active VGA
> > device. It works by adding sysfs attributes to bridge a
On Monday, January 17, 2005 7:43 pm, Jon Smirl wrote:
> Attached is a patch to control VGA bus routing and the active VGA
> device. It works by adding sysfs attributes to bridge and VGA devices.
> The bridge attribute is read only and indicates if the bridge is
> routing VGA. The attribute on the d
Attached is a patch to control VGA bus routing and the active VGA
device. It works by adding sysfs attributes to bridge and VGA devices.
The bridge attribute is read only and indicates if the bridge is
routing VGA. The attribute on the device has four values:
/* echo these values to the sysfs vga
31 matches
Mail list logo
