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
24 matches
Mail list logo
