On Thu Feb 24 2005 - 01:33:38 Adam Belay wrote:
>The basic flow of the new code is as follows:
>1.) A standard "driver core" driver binds to a bridge device.
>2.) When "*probe" is called it sets up the hardware and allocates a
"struct pci_bus".
>3.) The "struct pci_bus" is filled with information
On Monday, February 28, 2005 4:13 pm, Adam Belay wrote:
> 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
> >
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 l
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 futur
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 c
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 b
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 device structure
itself so that the platform code would know
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
> > leg
On Thu, Feb 24, 2005 at 01:22:01AM -0500, Adam Belay wrote:
> 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
On Wednesday, February 23, 2005 11:03 pm, Adam Belay wrote:
> Yeah, actually I've been thinking about this issue a lot. I think it
> would make a lot of sense to export this sort of thing under the
> "pci_bus" class in sysfs. The ISA enable bit should probably also be
> exported. Furthermore, we
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".
What you need to be aware of is that cardbus hardware is special - it
may change its resource requirements at any time, both in terms of the
num
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 bridge function.
An ISA LPC bridge driver would be nice too.
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 s
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 PCI driver. It turns out to be a major
What about
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 compon
15 matches
Mail list logo
