Re: Shortened CC (Re: New topic (PowerPC Linux PCI HELL))
> > Several drivers do this. No PCI glue layer will be perfect, and if you try > > to make it perfect it will be bloated and suck. > > Alan, > > What is wrong with an enable struct so that the glue layer is generic? You want to add cache line size to it next, and maybe a flag to say which register to put it in ? Thats the point I was trying to make. By the time you get a pci_enable_feature function that takes 8 parameters or a struct you've missed the point - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Shortened CC (Re: New topic (PowerPC Linux PCI HELL))
On Sat, 23 Sep 2000, Alan Cox wrote: > > Memory Write and Invalidate one way or another, but the decision is not > > arch-specific. It gets worse: it writes cache line size to PCI_COMMAND > > as well. > > Several drivers do this. No PCI glue layer will be perfect, and if you try > to make it perfect it will be bloated and suck. Alan, What is wrong with an enable struct so that the glue layer is generic? Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
> Memory Write and Invalidate one way or another, but the decision is not > arch-specific. It gets worse: it writes cache line size to PCI_COMMAND > as well. Several drivers do this. No PCI glue layer will be perfect, and if you try to make it perfect it will be bloated and suck. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 22 Sep 2000, Jamie Lokier wrote:
> Michel Lanners wrote:
> > >> static inline int pci_enable_device(struct pci_device *dev)
> > >> {
> > >> return pci_enable_device_features(USE_IO|USE_MM);
> > >> }
> > (snip)
> > > And what about other features ?
> > > I mean:
> > > - Bus Master
> > > - Memory Write and Invalidate
> > > - Parity Error response
> >
> > This should probably be handled in arch-dependant code. So make a
> > pci_enable_device() per arch. The point beeing that only this code has a
> > chance to know some of the details of the PCI implementation on this
> > platform/arch. Bus master and MemWI don't hurt, but I guess enabling
> > parity can halt the bus. So you want to be careful...
>
> Take a look at the drivers/net/acenic.c driver. It enables/disables
> Memory Write and Invalidate one way or another, but the decision is not
> arch-specific. It gets worse: it writes cache line size to PCI_COMMAND
> as well.
Why should it not do so, given that no hardware quirks is supplied ?
The fact that you aren't told about something should not make you assume
the worse case, by default. Such behaviour is called paranoia. And,
speaking about PCI, result is that users pay for features the kernel
decide in user's back not to use, even when they are functionning just
fine.
About PCI parity error checking and reporting, this feature is required
for most PCI controller classes. If it is confusing the machine, then
hardware should get garbagged and user should get reimbursed of the
hardware and time wasted.
About the PCI cache line size, there is no valuable reason for the POST
code not to set it. Obviously, MWI requires the right value of the cache
line to be configured. A POST code that does not set the cache line size
to the proper value in order to tell about not using MWI looks like a
definite piece of crap to me. PCI devices may use the configured cache
line size in order to make decision about using MRL and MRM as you know,
and bridges and devices that implement prefetchable memory can gain
advantage of such transactions.
Note that for MRL and MRM, assuming a wrong value of the cache line size
will not break anything, and a not too wrong value (twice or half the
right value) can be adequate.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Michel Lanners wrote:
> >> static inline int pci_enable_device(struct pci_device *dev)
> >> {
> >>return pci_enable_device_features(USE_IO|USE_MM);
> >> }
> (snip)
> > And what about other features ?
> > I mean:
> > - Bus Master
> > - Memory Write and Invalidate
> > - Parity Error response
>
> This should probably be handled in arch-dependant code. So make a
> pci_enable_device() per arch. The point beeing that only this code has a
> chance to know some of the details of the PCI implementation on this
> platform/arch. Bus master and MemWI don't hurt, but I guess enabling
> parity can halt the bus. So you want to be careful...
Take a look at the drivers/net/acenic.c driver. It enables/disables
Memory Write and Invalidate one way or another, but the decision is not
arch-specific. It gets worse: it writes cache line size to PCI_COMMAND
as well.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 22 Sep 2000, Jamie Lokier wrote:
Michel Lanners wrote:
static inline int pci_enable_device(struct pci_device *dev)
{
return pci_enable_device_features(USE_IO|USE_MM);
}
(snip)
And what about other features ?
I mean:
- Bus Master
- Memory Write and Invalidate
- Parity Error response
This should probably be handled in arch-dependant code. So make a
pci_enable_device() per arch. The point beeing that only this code has a
chance to know some of the details of the PCI implementation on this
platform/arch. Bus master and MemWI don't hurt, but I guess enabling
parity can halt the bus. So you want to be careful...
Take a look at the drivers/net/acenic.c driver. It enables/disables
Memory Write and Invalidate one way or another, but the decision is not
arch-specific. It gets worse: it writes cache line size to PCI_COMMAND
as well.
Why should it not do so, given that no hardware quirks is supplied ?
The fact that you aren't told about something should not make you assume
the worse case, by default. Such behaviour is called paranoia. And,
speaking about PCI, result is that users pay for features the kernel
decide in user's back not to use, even when they are functionning just
fine.
About PCI parity error checking and reporting, this feature is required
for most PCI controller classes. If it is confusing the machine, then
hardware should get garbagged and user should get reimbursed of the
hardware and time wasted.
About the PCI cache line size, there is no valuable reason for the POST
code not to set it. Obviously, MWI requires the right value of the cache
line to be configured. A POST code that does not set the cache line size
to the proper value in order to tell about not using MWI looks like a
definite piece of crap to me. PCI devices may use the configured cache
line size in order to make decision about using MRL and MRM as you know,
and bridges and devices that implement prefetchable memory can gain
advantage of such transactions.
Note that for MRL and MRM, assuming a wrong value of the cache line size
will not break anything, and a not too wrong value (twice or half the
right value) can be adequate.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Shortened CC (Re: New topic (PowerPC Linux PCI HELL))
On Sat, 23 Sep 2000, Alan Cox wrote: Memory Write and Invalidate one way or another, but the decision is not arch-specific. It gets worse: it writes cache line size to PCI_COMMAND as well. Several drivers do this. No PCI glue layer will be perfect, and if you try to make it perfect it will be bloated and suck. Alan, What is wrong with an enable struct so that the glue layer is generic? Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On 18 Sep, this message from Gérard Roudier echoed through cyberspace:
>> > All I wanted was a function that allows the driver to decide that which
>> > needs to be enabled.
>> >
>> > pci_enable_device(struct pci_dev *dev, byte enable_mask)
>> >
>> > This would allow drivers to enable that which it needs and not weird out
>> > the hardware that does not like all of this extra fluff.
>>
>> Sounds not too daft
>>
>> static inline int pci_enable_device(struct pci_device *dev)
>> {
>> return pci_enable_device_features(USE_IO|USE_MM);
>> }
(snip)
> And what about other features ?
> I mean:
> - Bus Master
> - Memory Write and Invalidate
> - Parity Error response
This should probably be handled in arch-dependant code. So make a
pci_enable_device() per arch. The point beeing that only this code has a
chance to know some of the details of the PCI implementation on this
platform/arch. Bus master and MemWI don't hurt, but I guess enabling
parity can halt the bus. So you want to be careful... So:
static inline int pci_enable_device(struct pci_device *dev)
{
return pci_enable_device_features(~ENABLE_NONE);
}
and let pci_enable_device_features() chose which features make sense/are
safe.
Michel
-
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes|Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email [EMAIL PROTECTED]|
http://www.cpu.lu/~mlan| Learn Always. "
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Mon, 18 Sep 2000, Alan Cox wrote:
> > All I wanted was a function that allows the driver to decide that which
> > needs to be enabled.
> >
> > pci_enable_device(struct pci_dev *dev, byte enable_mask)
> >
> > This would allow drivers to enable that which it needs and not weird out
> > the hardware that does not like all of this extra fluff.
>
> Sounds not too daft
>
> static inline int pci_enable_device(struct pci_device *dev)
> {
> return pci_enable_device_features(USE_IO|USE_MM);
> }
Should be worded as "Respond to IO", "Respond to Memory" transactions,
given the explicit PCI context.
And what about other features ?
I mean:
- Bus Master
- Memory Write and Invalidate
- Parity Error response
Etc ...
Are they considered as misfeatures ? ;-)
> and then just go and turn the existing enable_device into enable_device_Features ?
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
> All I wanted was a function that allows the driver to decide that which
> needs to be enabled.
>
> pci_enable_device(struct pci_dev *dev, byte enable_mask)
>
> This would allow drivers to enable that which it needs and not weird out
> the hardware that does not like all of this extra fluff.
Sounds not too daft
static inline int pci_enable_device(struct pci_device *dev)
{
return pci_enable_device_features(USE_IO|USE_MM);
}
and then just go and turn the existing enable_device into enable_device_Features ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Mon, 18 Sep 2000, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > Andre Hedrick wrote:
> > >All I wanted was a function that allows the driver to decide that which
> > >needs to be enabled.
> > >
> > >pci_enable_device(struct pci_dev *dev, byte enable_mask)
>
> > This is indeed interesting.
> >
> > Some devices, for example, will provide several apertures (can eat much
> > bus space) while only one of them is actually needed by the driver.
> > Having the driver be able to only enable (and possibly claim) one of them
> > would free up some bus space for other devices (I'm thinking here about
> > hot swap devices that will dynamically claim bus space, like cardbus).
>
> Perhaps I was mistaken, but I was thinking about enable_mask only
> applied to PCI_COMMAND_{IO,MEM}. If that is the case, it sounds like
> your needs would only be met if one set of apertures was driven via
> ISA-style port I/O, and the other set of apertures via PCI shared mem
> (MMIO).
Then change it to :
pci_enable_device(struct pci_dev *dev, struct pci_enable *enable_set)
typedef union {
unsigned all: 8;
struct {
unsigned bar0 : 1;
unsigned bar1 : 1;
unsigned bar2 : 1;
unsigned bar3 : 1;
unsigned bar4 : 1;
unsigned bar5 : 1;
unsigned reserved : 2;
} bar;
} pci_t;
struct pci_enable {
pci_t io_bars;
pci_t mem_bars;
...
pci_t wtf_bars;
...
unsigned long reg[6];
...
(pick and add whatever gets the job done)
};
I am not picky, just want it simple so that It can be tabled out by device
classes.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Mon, 18 Sep 2000, Jeff Garzik wrote:
Benjamin Herrenschmidt wrote:
Andre Hedrick wrote:
All I wanted was a function that allows the driver to decide that which
needs to be enabled.
pci_enable_device(struct pci_dev *dev, byte enable_mask)
This is indeed interesting.
Some devices, for example, will provide several apertures (can eat much
bus space) while only one of them is actually needed by the driver.
Having the driver be able to only enable (and possibly claim) one of them
would free up some bus space for other devices (I'm thinking here about
hot swap devices that will dynamically claim bus space, like cardbus).
Perhaps I was mistaken, but I was thinking about enable_mask only
applied to PCI_COMMAND_{IO,MEM}. If that is the case, it sounds like
your needs would only be met if one set of apertures was driven via
ISA-style port I/O, and the other set of apertures via PCI shared mem
(MMIO).
Then change it to :
pci_enable_device(struct pci_dev *dev, struct pci_enable *enable_set)
typedef union {
unsigned all: 8;
struct {
unsigned bar0 : 1;
unsigned bar1 : 1;
unsigned bar2 : 1;
unsigned bar3 : 1;
unsigned bar4 : 1;
unsigned bar5 : 1;
unsigned reserved : 2;
} bar;
} pci_t;
struct pci_enable {
pci_t io_bars;
pci_t mem_bars;
...
pci_t wtf_bars;
...
unsigned long reg[6];
...
(pick and add whatever gets the job done)
};
I am not picky, just want it simple so that It can be tabled out by device
classes.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
All I wanted was a function that allows the driver to decide that which
needs to be enabled.
pci_enable_device(struct pci_dev *dev, byte enable_mask)
This would allow drivers to enable that which it needs and not weird out
the hardware that does not like all of this extra fluff.
Sounds not too daft
static inline int pci_enable_device(struct pci_device *dev)
{
return pci_enable_device_features(USE_IO|USE_MM);
}
and then just go and turn the existing enable_device into enable_device_Features ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Mon, 18 Sep 2000, Alan Cox wrote:
All I wanted was a function that allows the driver to decide that which
needs to be enabled.
pci_enable_device(struct pci_dev *dev, byte enable_mask)
This would allow drivers to enable that which it needs and not weird out
the hardware that does not like all of this extra fluff.
Sounds not too daft
static inline int pci_enable_device(struct pci_device *dev)
{
return pci_enable_device_features(USE_IO|USE_MM);
}
Should be worded as "Respond to IO", "Respond to Memory" transactions,
given the explicit PCI context.
And what about other features ?
I mean:
- Bus Master
- Memory Write and Invalidate
- Parity Error response
Etc ...
Are they considered as misfeatures ? ;-)
and then just go and turn the existing enable_device into enable_device_Features ?
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On 18 Sep, this message from Gérard Roudier echoed through cyberspace:
All I wanted was a function that allows the driver to decide that which
needs to be enabled.
pci_enable_device(struct pci_dev *dev, byte enable_mask)
This would allow drivers to enable that which it needs and not weird out
the hardware that does not like all of this extra fluff.
Sounds not too daft
static inline int pci_enable_device(struct pci_device *dev)
{
return pci_enable_device_features(USE_IO|USE_MM);
}
(snip)
And what about other features ?
I mean:
- Bus Master
- Memory Write and Invalidate
- Parity Error response
This should probably be handled in arch-dependant code. So make a
pci_enable_device() per arch. The point beeing that only this code has a
chance to know some of the details of the PCI implementation on this
platform/arch. Bus master and MemWI don't hurt, but I guess enabling
parity can halt the bus. So you want to be careful... So:
static inline int pci_enable_device(struct pci_device *dev)
{
return pci_enable_device_features(~ENABLE_NONE);
}
and let pci_enable_device_features() chose which features make sense/are
safe.
Michel
-
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes|Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email [EMAIL PROTECTED]|
http://www.cpu.lu/~mlan| Learn Always. "
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Guys, All I wanted was a function that allows the driver to decide that which needs to be enabled. pci_enable_device(struct pci_dev *dev, byte enable_mask) This would allow drivers to enable that which it needs and not weird out the hardware that does not like all of this extra fluff. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
[SNIPPED...] On Sat, 16 Sep 2000, [ISO-8859-1] Gérard Roudier wrote: > > > > > > In PCI, you donnot enable windows, but you enable/disable devices to > > > generate and/or respond to transactions. > > > > Well really? From the programmers point-of-view, you have just enabled > > some windows into address space. The word "transaction" has gotten way > > too much visibility. The fact that some hardware mechanism has gotten > > involved reading from and writing to a device means nothing except > > that a write (if enabled) is posted. We don't bother thinking about > > "transactions" when we write to SDRAM do we? To the programmer, we > > write to it and it sticks. The fact that there was a hardware transaction > > involving a read/modify/write of (usually) much more than our byte > > isn't a concern. > > Hmmm... If you know what drivers have been written with such a limited > "low skilled" CPU centric approach in mind, let me know. I will just avoid > forever using the resulting crap. > I sure hope they all do. If any driver treats its I/O or memory window into the device any different than it would for shared RAM or decoded I/O ports, when access is provided by the PCI bus, then the programmer is providing a lot of extra code/CPU cycles that can't possibly do anything useful. Once enabled, the PCI bus looks to the CPU (and hence the programmer who writes stuff to be executed by the CPU) just like RAM and/or IO ports. If there is no other activity on the PCI bus at the instant that the CPU writes to your shared-memory window, the CPU will be able to do this with no wait-states until the posted-write FIFO is full. Any read, or write by another device, will force any posted- writes to complete before they are allowed. This just makes sure that what the CPU writes, are atomic to the CPU and to the device, without incurring unnecessary wait-states for a device and bus that is slower than the CPU. Hardware does this, not software. If software is attempting to do something that has already been done in hardware, then software is wasting CPU cycles. If a driver knows that its I/O port allocations have been obtained from the PCI controller, then it need not insert any wait-states into port reads and writes. Currently I/O wait states are obtained by writing to port 0x80 in Linux. This puts, roughly, 300 ns between successive port accesses. This is not necessary when using the PCI bus. However, the overhead necessary to determine the kind of port access to use, for every port access, wastes any CPU cycles gained by not writing to that port. The 'Bible' for the PCI bus seems to be "PCI System Architecture", Tom Shanley and Don Anderson, MindShare Inc. ISBN 0-201-30974-2. This book is over 800 pages long. Unfortunately, You have to get roughly half-way through (page 309) until you get to anything useful to the programmer. By that time, the programmer has learned a lot of "buzz-words" that are best forgotten because they confuse the whole issue. I just got through writing an entire BIOS. Once I got thorough the "fluff", setting up all the PCI devices (including a screen card) and all PnP devices, was a lot easier than reading the first 19 chapters of that damn book. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Guys, All I wanted was a function that allows the driver to decide that which needs to be enabled. pci_enable_device(struct pci_dev *dev, byte enable_mask) This would allow drivers to enable that which it needs and not weird out the hardware that does not like all of this extra fluff. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Richard B. Johnson wrote: > On Fri, 15 Sep 2000, [ISO-8859-1] Gérard Roudier wrote: > > > > > > > On Fri, 15 Sep 2000, Linus Torvalds wrote: > > > > > On Fri, 15 Sep 2000, Gérard Roudier wrote: > > > > > [ ... ] > > > No ifs, why's or buts. A driver that just enables the IO windows is a > > > buggy driver. > > > > In PCI, you donnot enable windows, but you enable/disable devices to > > generate and/or respond to transactions. > > Well really? From the programmers point-of-view, you have just enabled > some windows into address space. The word "transaction" has gotten way > too much visibility. The fact that some hardware mechanism has gotten > involved reading from and writing to a device means nothing except > that a write (if enabled) is posted. We don't bother thinking about > "transactions" when we write to SDRAM do we? To the programmer, we > write to it and it sticks. The fact that there was a hardware transaction > involving a read/modify/write of (usually) much more than our byte > isn't a concern. Hmmm... If you know what drivers have been written with such a limited "low skilled" CPU centric approach in mind, let me know. I will just avoid forever using the resulting crap. Gerard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Richard B. Johnson wrote: On Fri, 15 Sep 2000, [ISO-8859-1] Gérard Roudier wrote: On Fri, 15 Sep 2000, Linus Torvalds wrote: On Fri, 15 Sep 2000, Gérard Roudier wrote: [ ... ] No ifs, why's or buts. A driver that just enables the IO windows is a buggy driver. In PCI, you donnot enable windows, but you enable/disable devices to generate and/or respond to transactions. Well really? From the programmers point-of-view, you have just enabled some windows into address space. The word "transaction" has gotten way too much visibility. The fact that some hardware mechanism has gotten involved reading from and writing to a device means nothing except that a write (if enabled) is posted. We don't bother thinking about "transactions" when we write to SDRAM do we? To the programmer, we write to it and it sticks. The fact that there was a hardware transaction involving a read/modify/write of (usually) much more than our byte isn't a concern. Hmmm... If you know what drivers have been written with such a limited "low skilled" CPU centric approach in mind, let me know. I will just avoid forever using the resulting crap. Gerard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, [ISO-8859-1] Gérard Roudier wrote: > > > On Fri, 15 Sep 2000, Linus Torvalds wrote: > > > On Fri, 15 Sep 2000, Gérard Roudier wrote: > > > [Snipped a lot...] > > Call "pci_enable_device()". > > > > What's so hard about that? > > This function delegates too much as a whole to the PCI generic layer, IMO. > Imagine that for sanity I want to allocate all the device resources, but > only _enable_ part of device features (for example only memory > transactions). Imagine some special handling to be necessary due to some > chip bug. > It's not just 'maybe'. The Tundra Universe chip for interface to the VXI bus (PCI interface to VXI) allows that either/or/both I/O and memory 'windows' can be enabled. VXI bus space is duplicated in both so it's possible to do everything memory-mapped or even (if you really wanted to) from I/O space. > > You don't seem to realize, but it's entirely possible to have a setup > > where some device CANNOT be allocated it's IO region. The BIOS may have > > left the device disabled on purpose, simply because there wasn't enough > > free space in the memory map to enable the device anywhere. > > PCI specs said corresponding BAR must be set to ZERO, here. > Correct. If there are no resources, you clear all address bits. > > You can't just have the device driver enable such a device. It _has_ to > > ask the PCI layer to do it for it - because the PCI layer is the only one > > that can figure out that "Oh, damn, this machine has 3GB of memory, and 4 > > video cards that want a 256MB aperture each, and we don't have any place > > to map this card any more". > > I want to say the generic layer "What to do" in some more fine-grained way > than just a single verb, at least. I may accept to delegate it some "How > to do it". > > > No ifs, why's or buts. A driver that just enables the IO windows is a > > buggy driver. > > In PCI, you donnot enable windows, but you enable/disable devices to > generate and/or respond to transactions. Well really? From the programmers point-of-view, you have just enabled some windows into address space. The word "transaction" has gotten way too much visibility. The fact that some hardware mechanism has gotten involved reading from and writing to a device means nothing except that a write (if enabled) is posted. We don't bother thinking about "transactions" when we write to SDRAM do we? To the programmer, we write to it and it sticks. The fact that there was a hardware transaction involving a read/modify/write of (usually) much more than our byte isn't a concern. As previously stated (under flames), there are only two kinds of "transactions" you need to be concerned about, the first is, or should be, never used anymore (special cycles), and the second is a configuration transaction. These are important in that a current read/write cycle is aborted for such a transaction. Therefore, you don't want to access configuration space dynamically (like for turning ON/OFF device interrupts). PCI configuration space should only be accessed as required during device startup. OTOH, if you look at all the bits > in the COMMAND register, you will see that some other features are also to > be addressed by the enabling/disabling kernel interface. > I think the idea of accessing the PCI bus as a logical object, where the OS 'knows' the best way to do it is a good thing. However, the driver is going to have to pass much more information to the procedure than a simple pci_enable_device(dev). This has particular importance in PPC and other Motorola-type machines where there isn't any I/O space, but hardware emulates it as a memory access. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
> For 2.2, it's probably better to leave things as they are and just ask PPC > guys for adding a special fixup to their code. I'd rather they added a pci_enable_device(). Lets do it right and encourage easily ported drivers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Gérard Roudier wrote: > This function delegates too much as a whole to the PCI generic layer, IMO. > Imagine that for sanity I want to allocate all the device resources, but > only _enable_ part of device features (for example only memory > transactions). Imagine some special handling to be necessary due to some > chip bug. Blindly enabling PIO on VGA devices is bad news, cuz they all want to grab 0x3?0 ports. I always imagined it as something of a special case though. So for VGA devices I agree with you -- I don't care how a device is "enabled", but it would be nice tell the PCI layer that PIO or MMIO bits in PCI_COMMAND need special handling. PCI_DONT_TOUCH_PIO and PCI_DONT_TOUCH_MMIO maybe :) Jeff -- Jeff Garzik | Would you *really* want to Building 1024| get on a non-stop flight? MandrakeSoft, Inc. | -- George Carlin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Linus Torvalds wrote: > On Fri, 15 Sep 2000, Gérard Roudier wrote: > > > > > Just as an example: imagine that the IO windows haven't been set up > > > correctly. If the low-level driver just blindly enables IO cycles by > > > writing to the PCI_COMMAND register, that device may come up in an invalid > > > state, and mess up the whole system. The driver simply does not KNOW > > > enough. It doesn't know where other devices are, and it _shouldn't_ know. > > > > How do you want this to happen ? Could you elaborate. > > It's really easy. > > Call "pci_enable_device()". > > What's so hard about that? This function delegates too much as a whole to the PCI generic layer, IMO. Imagine that for sanity I want to allocate all the device resources, but only _enable_ part of device features (for example only memory transactions). Imagine some special handling to be necessary due to some chip bug. > You don't seem to realize, but it's entirely possible to have a setup > where some device CANNOT be allocated it's IO region. The BIOS may have > left the device disabled on purpose, simply because there wasn't enough > free space in the memory map to enable the device anywhere. PCI specs said corresponding BAR must be set to ZERO, here. > You can't just have the device driver enable such a device. It _has_ to > ask the PCI layer to do it for it - because the PCI layer is the only one > that can figure out that "Oh, damn, this machine has 3GB of memory, and 4 > video cards that want a 256MB aperture each, and we don't have any place > to map this card any more". I want to say the generic layer "What to do" in some more fine-grained way than just a single verb, at least. I may accept to delegate it some "How to do it". > No ifs, why's or buts. A driver that just enables the IO windows is a > buggy driver. In PCI, you donnot enable windows, but you enable/disable devices to generate and/or respond to transactions. OTOH, if you look at all the bits in the COMMAND register, you will see that some other features are also to be addressed by the enabling/disabling kernel interface. > > > In contrast, the general PCI layer _does_ know. It keeps track of > > > resources, makes sure that different cards do not have overlapping address > > > ranges, knows about PCI bridges (a card behind a PCI bridge can only be > > > enabled after the _bridge_ has been enabled and can only be mapped in the > > > region that the bridge maps). > > > > Yes, it is expected to do its work (e.g. assigning ressources to all > > agents on the BUS hierachy). > > Right. > > And sometimes it CANNOT. > > End of story. > > Linus Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Hi! > It is a real issue of failure in 2.2, and it would be useful if the PPC > folks want to use Ultra-ATA cards. For 2.4, making the IDE driver call pci_enable_device() and modifying the PPC PCI code to fix up whatever is needed there. For 2.2, it's probably better to leave things as they are and just ask PPC guys for adding a special fixup to their code. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Q: How to start hacking Linux? A: vi /boot/vmlinuz" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Gérard Roudier wrote: > > > Just as an example: imagine that the IO windows haven't been set up > > correctly. If the low-level driver just blindly enables IO cycles by > > writing to the PCI_COMMAND register, that device may come up in an invalid > > state, and mess up the whole system. The driver simply does not KNOW > > enough. It doesn't know where other devices are, and it _shouldn't_ know. > > How do you want this to happen ? Could you elaborate. It's really easy. Call "pci_enable_device()". What's so hard about that? You don't seem to realize, but it's entirely possible to have a setup where some device CANNOT be allocated it's IO region. The BIOS may have left the device disabled on purpose, simply because there wasn't enough free space in the memory map to enable the device anywhere. You can't just have the device driver enable such a device. It _has_ to ask the PCI layer to do it for it - because the PCI layer is the only one that can figure out that "Oh, damn, this machine has 3GB of memory, and 4 video cards that want a 256MB aperture each, and we don't have any place to map this card any more". No ifs, why's or buts. A driver that just enables the IO windows is a buggy driver. > > In contrast, the general PCI layer _does_ know. It keeps track of > > resources, makes sure that different cards do not have overlapping address > > ranges, knows about PCI bridges (a card behind a PCI bridge can only be > > enabled after the _bridge_ has been enabled and can only be mapped in the > > region that the bridge maps). > > Yes, it is expected to do its work (e.g. assigning ressources to all > agents on the BUS hierachy). Right. And sometimes it CANNOT. End of story. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Linus Torvalds wrote: > On Fri, 15 Sep 2000, Richard B. Johnson wrote: > > > > The PCI Specification states, in part, that either the BIOS or the > > driver has to enable the device. So, many drivers find that the device > > has not been enabled. This is normal and necessary because many/most > > PCI hardware had better not be enabled until an ISR is in-place. > > But that's why we have the "pci_enable_device()" function. And that's why > we have the generic PCI setup functionality that finds and enables devices > at the right addresses. > > DO NOT USE ANY LOCAL HACKS. Use the proper function. Don't go mucking > around with random configuration state information: enabling a device > involves a lot more than just writing stuff to configuration ports. Things > like making sure the interrupt routing on the motherboard has been > enabled, etc. Things that the driver does not know about, and should not > even _try_ to understand. > > The PCI layer should be used to handle generic PCI issues. A low-level > driver should _never_ try to handle resource allocation and enabling in > hardware. Disagreed about `enabling'. > Just as an example: imagine that the IO windows haven't been set up > correctly. If the low-level driver just blindly enables IO cycles by > writing to the PCI_COMMAND register, that device may come up in an invalid > state, and mess up the whole system. The driver simply does not KNOW > enough. It doesn't know where other devices are, and it _shouldn't_ know. How do you want this to happen ? Could you elaborate. > In contrast, the general PCI layer _does_ know. It keeps track of > resources, makes sure that different cards do not have overlapping address > ranges, knows about PCI bridges (a card behind a PCI bridge can only be > enabled after the _bridge_ has been enabled and can only be mapped in the > region that the bridge maps). Yes, it is expected to do its work (e.g. assigning ressources to all agents on the BUS hierachy). > To make a long story short: a driver that touches the PCI_COMMAND or other > generic PCI registers by hand is a _buggy_ driver. It's a sure recipe for > disaster. I disagree 100% with this statement. The genericity of PCI configuration is only here to facilitate configuration of all the devices on a BUS hierarchy. Indeed a PCI device driver must not tamper the resources the device got from the generic PCI layer. But it is expected to know better about the PCI devices it supports that any generic PCI layer. Not everything are generic in PCI. What about device bugs, for example? About bridges, part of their configuration can be handled generically, but not everything. The generic PCI layer that deals with bridges have to know bridge quirks and special features as you know. In some way, the PCI generic layer acts as PCI device drivers for the bridges. Configuring and enabling are 2 different issues. Configuring has been designed to be generic in PCI but the `enabling' should be performed by the entity that knows the best about the real device, thus the PCI device driver. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Alan Cox wrote: > > The PCI Specification states, in part, that either the BIOS or the > > driver has to enable the device. So, many drivers find that the device > > has not been enabled. This is normal and necessary because many/most > > PCI hardware had better not be enabled until an ISR is in-place. > > The Linux 2.4 kernel API means that you must call > > pci_enable_device(dev) > > which also knows about architecture specific magic too > > Alan > Okay. So, in effect, PCI is no longer a bus that drivers have to know about, but a logical device. This is good. The stuff I've been working on (2.2.+) doesn't have this capability. It will be good when we have a stable version (err non-broken) of 2.4 for me to port my drivers to. I just conldn't keep up with the continual changes and sorta gave up for the time being. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
> The PCI Specification states, in part, that either the BIOS or the > driver has to enable the device. So, many drivers find that the device > has not been enabled. This is normal and necessary because many/most > PCI hardware had better not be enabled until an ISR is in-place. The Linux 2.4 kernel API means that you must call pci_enable_device(dev) which also knows about architecture specific magic too Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Richard B. Johnson wrote: > > The PCI Specification states, in part, that either the BIOS or the > driver has to enable the device. So, many drivers find that the device > has not been enabled. This is normal and necessary because many/most > PCI hardware had better not be enabled until an ISR is in-place. But that's why we have the "pci_enable_device()" function. And that's why we have the generic PCI setup functionality that finds and enables devices at the right addresses. DO NOT USE ANY LOCAL HACKS. Use the proper function. Don't go mucking around with random configuration state information: enabling a device involves a lot more than just writing stuff to configuration ports. Things like making sure the interrupt routing on the motherboard has been enabled, etc. Things that the driver does not know about, and should not even _try_ to understand. The PCI layer should be used to handle generic PCI issues. A low-level driver should _never_ try to handle resource allocation and enabling in hardware. Just as an example: imagine that the IO windows haven't been set up correctly. If the low-level driver just blindly enables IO cycles by writing to the PCI_COMMAND register, that device may come up in an invalid state, and mess up the whole system. The driver simply does not KNOW enough. It doesn't know where other devices are, and it _shouldn't_ know. In contrast, the general PCI layer _does_ know. It keeps track of resources, makes sure that different cards do not have overlapping address ranges, knows about PCI bridges (a card behind a PCI bridge can only be enabled after the _bridge_ has been enabled and can only be mapped in the region that the bridge maps). To make a long story short: a driver that touches the PCI_COMMAND or other generic PCI registers by hand is a _buggy_ driver. It's a sure recipe for disaster. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Linus Torvalds wrote: > > > On Wed, 13 Sep 2000, Andre Hedrick wrote: > > > > Okay who can teach me how to force hooks and ram this down the PPC > > > > pci_write_config_word(dev, PCI_COMMAND, 0x05); > > If the PPC PCI code doesn't do this, then that's a PPC architecture bug. > > DO NOT DO THIS IN THE DRIVER! Fix the real problem instead. > > Linus > The PCI Specification states, in part, that either the BIOS or the driver has to enable the device. So, many drivers find that the device has not been enabled. This is normal and necessary because many/most PCI hardware had better not be enabled until an ISR is in-place. So, the only safe place you can enable the device is in the driver. It is normal and the printk()'s warning about this should be removed. Also, the PCI_COMMAND should probably be 0x07 for all devices. The ones that "stay" are the ones actually supported. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, 13 Sep 2000, Andre Hedrick wrote: > > Okay who can teach me how to force hooks and ram this down the PPC > > pci_write_config_word(dev, PCI_COMMAND, 0x05); If the PPC PCI code doesn't do this, then that's a PPC architecture bug. DO NOT DO THIS IN THE DRIVER! Fix the real problem instead. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, 13 Sep 2000, Andre Hedrick wrote: Okay who can teach me how to force hooks and ram this down the PPC pci_write_config_word(dev, PCI_COMMAND, 0x05); If the PPC PCI code doesn't do this, then that's a PPC architecture bug. DO NOT DO THIS IN THE DRIVER! Fix the real problem instead. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
The PCI Specification states, in part, that either the BIOS or the driver has to enable the device. So, many drivers find that the device has not been enabled. This is normal and necessary because many/most PCI hardware had better not be enabled until an ISR is in-place. The Linux 2.4 kernel API means that you must call pci_enable_device(dev) which also knows about architecture specific magic too Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Alan Cox wrote: The PCI Specification states, in part, that either the BIOS or the driver has to enable the device. So, many drivers find that the device has not been enabled. This is normal and necessary because many/most PCI hardware had better not be enabled until an ISR is in-place. The Linux 2.4 kernel API means that you must call pci_enable_device(dev) which also knows about architecture specific magic too Alan Okay. So, in effect, PCI is no longer a bus that drivers have to know about, but a logical device. This is good. The stuff I've been working on (2.2.+) doesn't have this capability. It will be good when we have a stable version (err non-broken) of 2.4 for me to port my drivers to. I just conldn't keep up with the continual changes and sorta gave up for the time being. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Gérard Roudier wrote: Just as an example: imagine that the IO windows haven't been set up correctly. If the low-level driver just blindly enables IO cycles by writing to the PCI_COMMAND register, that device may come up in an invalid state, and mess up the whole system. The driver simply does not KNOW enough. It doesn't know where other devices are, and it _shouldn't_ know. How do you want this to happen ? Could you elaborate. It's really easy. Call "pci_enable_device()". What's so hard about that? You don't seem to realize, but it's entirely possible to have a setup where some device CANNOT be allocated it's IO region. The BIOS may have left the device disabled on purpose, simply because there wasn't enough free space in the memory map to enable the device anywhere. You can't just have the device driver enable such a device. It _has_ to ask the PCI layer to do it for it - because the PCI layer is the only one that can figure out that "Oh, damn, this machine has 3GB of memory, and 4 video cards that want a 256MB aperture each, and we don't have any place to map this card any more". No ifs, why's or buts. A driver that just enables the IO windows is a buggy driver. In contrast, the general PCI layer _does_ know. It keeps track of resources, makes sure that different cards do not have overlapping address ranges, knows about PCI bridges (a card behind a PCI bridge can only be enabled after the _bridge_ has been enabled and can only be mapped in the region that the bridge maps). Yes, it is expected to do its work (e.g. assigning ressources to all agents on the BUS hierachy). Right. And sometimes it CANNOT. End of story. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Hi! It is a real issue of failure in 2.2, and it would be useful if the PPC folks want to use Ultra-ATA cards. For 2.4, making the IDE driver call pci_enable_device() and modifying the PPC PCI code to fix up whatever is needed there. For 2.2, it's probably better to leave things as they are and just ask PPC guys for adding a special fixup to their code. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ "Q: How to start hacking Linux? A: vi /boot/vmlinuz" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Linus Torvalds wrote: On Fri, 15 Sep 2000, Gérard Roudier wrote: Just as an example: imagine that the IO windows haven't been set up correctly. If the low-level driver just blindly enables IO cycles by writing to the PCI_COMMAND register, that device may come up in an invalid state, and mess up the whole system. The driver simply does not KNOW enough. It doesn't know where other devices are, and it _shouldn't_ know. How do you want this to happen ? Could you elaborate. It's really easy. Call "pci_enable_device()". What's so hard about that? This function delegates too much as a whole to the PCI generic layer, IMO. Imagine that for sanity I want to allocate all the device resources, but only _enable_ part of device features (for example only memory transactions). Imagine some special handling to be necessary due to some chip bug. You don't seem to realize, but it's entirely possible to have a setup where some device CANNOT be allocated it's IO region. The BIOS may have left the device disabled on purpose, simply because there wasn't enough free space in the memory map to enable the device anywhere. PCI specs said corresponding BAR must be set to ZERO, here. You can't just have the device driver enable such a device. It _has_ to ask the PCI layer to do it for it - because the PCI layer is the only one that can figure out that "Oh, damn, this machine has 3GB of memory, and 4 video cards that want a 256MB aperture each, and we don't have any place to map this card any more". I want to say the generic layer "What to do" in some more fine-grained way than just a single verb, at least. I may accept to delegate it some "How to do it". No ifs, why's or buts. A driver that just enables the IO windows is a buggy driver. In PCI, you donnot enable windows, but you enable/disable devices to generate and/or respond to transactions. OTOH, if you look at all the bits in the COMMAND register, you will see that some other features are also to be addressed by the enabling/disabling kernel interface. In contrast, the general PCI layer _does_ know. It keeps track of resources, makes sure that different cards do not have overlapping address ranges, knows about PCI bridges (a card behind a PCI bridge can only be enabled after the _bridge_ has been enabled and can only be mapped in the region that the bridge maps). Yes, it is expected to do its work (e.g. assigning ressources to all agents on the BUS hierachy). Right. And sometimes it CANNOT. End of story. Linus Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
For 2.2, it's probably better to leave things as they are and just ask PPC guys for adding a special fixup to their code. I'd rather they added a pci_enable_device(). Lets do it right and encourage easily ported drivers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, [ISO-8859-1] Gérard Roudier wrote: On Fri, 15 Sep 2000, Linus Torvalds wrote: On Fri, 15 Sep 2000, Gérard Roudier wrote: [Snipped a lot...] Call "pci_enable_device()". What's so hard about that? This function delegates too much as a whole to the PCI generic layer, IMO. Imagine that for sanity I want to allocate all the device resources, but only _enable_ part of device features (for example only memory transactions). Imagine some special handling to be necessary due to some chip bug. It's not just 'maybe'. The Tundra Universe chip for interface to the VXI bus (PCI interface to VXI) allows that either/or/both I/O and memory 'windows' can be enabled. VXI bus space is duplicated in both so it's possible to do everything memory-mapped or even (if you really wanted to) from I/O space. You don't seem to realize, but it's entirely possible to have a setup where some device CANNOT be allocated it's IO region. The BIOS may have left the device disabled on purpose, simply because there wasn't enough free space in the memory map to enable the device anywhere. PCI specs said corresponding BAR must be set to ZERO, here. Correct. If there are no resources, you clear all address bits. You can't just have the device driver enable such a device. It _has_ to ask the PCI layer to do it for it - because the PCI layer is the only one that can figure out that "Oh, damn, this machine has 3GB of memory, and 4 video cards that want a 256MB aperture each, and we don't have any place to map this card any more". I want to say the generic layer "What to do" in some more fine-grained way than just a single verb, at least. I may accept to delegate it some "How to do it". No ifs, why's or buts. A driver that just enables the IO windows is a buggy driver. In PCI, you donnot enable windows, but you enable/disable devices to generate and/or respond to transactions. Well really? From the programmers point-of-view, you have just enabled some windows into address space. The word "transaction" has gotten way too much visibility. The fact that some hardware mechanism has gotten involved reading from and writing to a device means nothing except that a write (if enabled) is posted. We don't bother thinking about "transactions" when we write to SDRAM do we? To the programmer, we write to it and it sticks. The fact that there was a hardware transaction involving a read/modify/write of (usually) much more than our byte isn't a concern. As previously stated (under flames), there are only two kinds of "transactions" you need to be concerned about, the first is, or should be, never used anymore (special cycles), and the second is a configuration transaction. These are important in that a current read/write cycle is aborted for such a transaction. Therefore, you don't want to access configuration space dynamically (like for turning ON/OFF device interrupts). PCI configuration space should only be accessed as required during device startup. OTOH, if you look at all the bits in the COMMAND register, you will see that some other features are also to be addressed by the enabling/disabling kernel interface. I think the idea of accessing the PCI bus as a logical object, where the OS 'knows' the best way to do it is a good thing. However, the driver is going to have to pass much more information to the procedure than a simple pci_enable_device(dev). This has particular importance in PPC and other Motorola-type machines where there isn't any I/O space, but hardware emulates it as a memory access. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Thu, Sep 14, 2000 at 09:59:35AM +0200, Vojtech Pavlik wrote:
> On Wed, Sep 13, 2000 at 05:29:58PM -0700, Andre Hedrick wrote:
>
> > Okay who can teach me how to force hooks and ram this down the PPC
> >
> > pci_write_config_word(dev, PCI_COMMAND, 0x05);
> >
> > I have all the address registered.
> > My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
> > alive. Thus I get some of the most beuatiful lockups ever.
> > I suspect that this needs to be handled down in the arch.
> >
> > ./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
> >
> > Basically I can not get the IO's active, regardless of BIOS on the card.
> > Yes this is the old trick that used to work of making ix86 cards run in
> > non ix86-pci slots.
> >
> > Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
> > under Mac OS, but the IO's are not enable in linux and it crash like a big
> > dog also.
>
> The same happens for OHCI on new Macs. The correct function to use is:
>
> pci_enable_device(dev);
>
> This function will enable the i/o, mem and irqs, and assign them if they
> were not assigned for some reason, too.
Once all the PCI oddities are worked out of 2.4.0-testX on PPC, yes :)
Right now I have to disable that call in aic7xxx to use my adaptec card
(none of the pci patches yet seem to work on all machines).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Thu, 14 Sep 2000, Alan Cox wrote: > > > It seems you forget to call pci_enable_device() in the PCI IDE driver. > > > > Hi Martin, > > > > Can we do this for 2.2 ? also ?? > > Right now pci_enable_device is a no-op for compatibility on 2.2. If you need > it to do the real thing go for it It is a real issue of failure in 2.2, and it would be useful if the PPC folks want to use Ultra-ATA cards. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Thu, 14 Sep 2000, Martin Mares wrote: > Hi! > > > > It belongs in arch/ppc/kernel/*pci*.c > > > > > > This is precisely the kind of compat stuff which should be fixed up in > > > the arch-specific PCI support code. > > > > Martin, cross-platform party on PCI stuff > > It seems you forget to call pci_enable_device() in the PCI IDE driver. Hi Martin, Can we do this for 2.2 ? also ?? Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Hi! > > It belongs in arch/ppc/kernel/*pci*.c > > > > This is precisely the kind of compat stuff which should be fixed up in > > the arch-specific PCI support code. > > Martin, cross-platform party on PCI stuff It seems you forget to call pci_enable_device() in the PCI IDE driver. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "In accord to UNIX philosophy, PERL gives you enough rope to hang yourself." -- Larry Wall - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, Sep 13, 2000 at 05:29:58PM -0700, Andre Hedrick wrote:
> Okay who can teach me how to force hooks and ram this down the PPC
>
> pci_write_config_word(dev, PCI_COMMAND, 0x05);
>
> I have all the address registered.
> My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
> alive. Thus I get some of the most beuatiful lockups ever.
> I suspect that this needs to be handled down in the arch.
>
> ./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
>
> Basically I can not get the IO's active, regardless of BIOS on the card.
> Yes this is the old trick that used to work of making ix86 cards run in
> non ix86-pci slots.
>
> Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
> under Mac OS, but the IO's are not enable in linux and it crash like a big
> dog also.
The same happens for OHCI on new Macs. The correct function to use is:
pci_enable_device(dev);
This function will enable the i/o, mem and irqs, and assign them if they
were not assigned for some reason, too.
And you should use it on any PCI device you want to use before using
it, on all architectures. Also check its return value.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, Sep 13, 2000 at 05:29:58PM -0700, Andre Hedrick wrote:
Okay who can teach me how to force hooks and ram this down the PPC
pci_write_config_word(dev, PCI_COMMAND, 0x05);
I have all the address registered.
My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
alive. Thus I get some of the most beuatiful lockups ever.
I suspect that this needs to be handled down in the arch.
./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
Basically I can not get the IO's active, regardless of BIOS on the card.
Yes this is the old trick that used to work of making ix86 cards run in
non ix86-pci slots.
Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
under Mac OS, but the IO's are not enable in linux and it crash like a big
dog also.
The same happens for OHCI on new Macs. The correct function to use is:
pci_enable_device(dev);
This function will enable the i/o, mem and irqs, and assign them if they
were not assigned for some reason, too.
And you should use it on any PCI device you want to use before using
it, on all architectures. Also check its return value.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Thu, 14 Sep 2000, Martin Mares wrote: Hi! It belongs in arch/ppc/kernel/*pci*.c This is precisely the kind of compat stuff which should be fixed up in the arch-specific PCI support code. Martin, cross-platform party on PCI stuff It seems you forget to call pci_enable_device() in the PCI IDE driver. Hi Martin, Can we do this for 2.2 ? also ?? Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Thu, 14 Sep 2000, Alan Cox wrote: It seems you forget to call pci_enable_device() in the PCI IDE driver. Hi Martin, Can we do this for 2.2 ? also ?? Right now pci_enable_device is a no-op for compatibility on 2.2. If you need it to do the real thing go for it It is a real issue of failure in 2.2, and it would be useful if the PPC folks want to use Ultra-ATA cards. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Thu, Sep 14, 2000 at 09:59:35AM +0200, Vojtech Pavlik wrote:
On Wed, Sep 13, 2000 at 05:29:58PM -0700, Andre Hedrick wrote:
Okay who can teach me how to force hooks and ram this down the PPC
pci_write_config_word(dev, PCI_COMMAND, 0x05);
I have all the address registered.
My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
alive. Thus I get some of the most beuatiful lockups ever.
I suspect that this needs to be handled down in the arch.
./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
Basically I can not get the IO's active, regardless of BIOS on the card.
Yes this is the old trick that used to work of making ix86 cards run in
non ix86-pci slots.
Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
under Mac OS, but the IO's are not enable in linux and it crash like a big
dog also.
The same happens for OHCI on new Macs. The correct function to use is:
pci_enable_device(dev);
This function will enable the i/o, mem and irqs, and assign them if they
were not assigned for some reason, too.
Once all the PCI oddities are worked out of 2.4.0-testX on PPC, yes :)
Right now I have to disable that call in aic7xxx to use my adaptec card
(none of the pci patches yet seem to work on all machines).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Hi! It belongs in arch/ppc/kernel/*pci*.c This is precisely the kind of compat stuff which should be fixed up in the arch-specific PCI support code. Martin, cross-platform party on PCI stuff It seems you forget to call pci_enable_device() in the PCI IDE driver. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ "In accord to UNIX philosophy, PERL gives you enough rope to hang yourself." -- Larry Wall - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, 13 Sep 2000, David S. Miller wrote: >Date: Wed, 13 Sep 2000 18:00:02 -0700 (PDT) >From: Matthew Jacob <[EMAIL PROTECTED]> > >This seems to be an artifact of some OBP implementations for PPC- >apples in particular. > >It assigns both I/O and Mem addrs and IRQs, but doesn't enable >either memory or I/O. So you have to do it for it. > > Yeah, but this doesn't belong in the drivers that is for sure. Verified, because it fails and it is way to late. > It belongs in arch/ppc/kernel/*pci*.c > > This is precisely the kind of compat stuff which should be fixed up in > the arch-specific PCI support code. Martin, cross-platform party on PCI stuff Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, 13 Sep 2000, David S. Miller wrote: >Date: Wed, 13 Sep 2000 18:00:02 -0700 (PDT) >From: Matthew Jacob <[EMAIL PROTECTED]> > >This seems to be an artifact of some OBP implementations for PPC- >apples in particular. > >It assigns both I/O and Mem addrs and IRQs, but doesn't enable >either memory or I/O. So you have to do it for it. > > Yeah, but this doesn't belong in the drivers that is for sure. > > It belongs in arch/ppc/kernel/*pci*.c > > This is precisely the kind of compat stuff which should be fixed up in > the arch-specific PCI support code. I couldn't agree more. However- I can only write the bits for my driver and maybe *suggest* stuff to the PPC maintainers (I'm relatively new to having a PPC to play with). -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Date:Wed, 13 Sep 2000 18:00:02 -0700 (PDT) From: Matthew Jacob <[EMAIL PROTECTED]> This seems to be an artifact of some OBP implementations for PPC- apples in particular. It assigns both I/O and Mem addrs and IRQs, but doesn't enable either memory or I/O. So you have to do it for it. Yeah, but this doesn't belong in the drivers that is for sure. It belongs in arch/ppc/kernel/*pci*.c This is precisely the kind of compat stuff which should be fixed up in the arch-specific PCI support code. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
This seems to be an artifact of some OBP implementations for PPC- apples in
particular.
It assigns both I/O and Mem addrs and IRQs, but doesn't enable either memory
or I/O. So you have to do it for it.
On Wed, 13 Sep 2000, Andre Hedrick wrote:
>
> Okay who can teach me how to force hooks and ram this down the PPC
>
> pci_write_config_word(dev, PCI_COMMAND, 0x05);
>
> I have all the address registered.
> My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
> alive. Thus I get some of the most beuatiful lockups ever.
> I suspect that this needs to be handled down in the arch.
>
> ./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
>
> Basically I can not get the IO's active, regardless of BIOS on the card.
> Yes this is the old trick that used to work of making ix86 cards run in
> non ix86-pci slots.
>
> Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
> under Mac OS, but the IO's are not enable in linux and it crash like a big
> dog also.
>
> Cheers,
>
>
> Andre Hedrick
> The Linux ATA/IDE guy
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, Sep 13, 2000 at 05:29:58PM -0700, Andre Hedrick wrote:
>
> Okay who can teach me how to force hooks and ram this down the PPC
>
> pci_write_config_word(dev, PCI_COMMAND, 0x05);
>
> I have all the address registered.
> My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
> alive. Thus I get some of the most beuatiful lockups ever.
> I suspect that this needs to be handled down in the arch.
>
> ./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
>
> Basically I can not get the IO's active, regardless of BIOS on the card.
> Yes this is the old trick that used to work of making ix86 cards run in
> non ix86-pci slots.
>
> Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
> under Mac OS, but the IO's are not enable in linux and it crash like a big
> dog also.
I'm going to bet you need to look at Michel Lanners' (did I spell that
right this time?) PCI patches. For instance, I've always needed this
hideous patch on my 7300/200 to get a Promise Ultra66 card to work:
diff -ur merging-bk/drivers/block/ide-pci.c work-bk/drivers/block/ide-pci.c
--- merging-bk/drivers/block/ide-pci.c Tue Apr 4 22:19:16 2000
+++ work-bk/drivers/block/ide-pci.c Thu Mar 9 15:33:25 2000
@@ -468,6 +468,15 @@
printk("%s: error accessing PCI regs\n", d->name);
return;
}
+#ifdef __powerpc__
+ if (!(pcicmd & PCI_COMMAND_IO)) { /* is device disabled? */
+ pci_write_config_word(dev, PCI_COMMAND, pcicmd | PCI_COMMAND_IO);
+ if (pci_read_config_word(dev, PCI_COMMAND, )) {
+ printk("%s: error accessing PCI regs\n", d->name);
+ return;
+ }
+ }
+#endif
if (!(pcicmd & PCI_COMMAND_IO)) { /* is device disabled? */
/*
* PnP BIOS was *supposed* to have set this device up for us,
Dan
/\ /\
| Daniel Jacobowitz|__|SCS Class of 2002 |
| Debian GNU/Linux Developer__Carnegie Mellon University |
| [EMAIL PROTECTED] | | [EMAIL PROTECTED] |
\/ \/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
New topic (PowerPC Linux PCI HELL)
Okay who can teach me how to force hooks and ram this down the PPC
pci_write_config_word(dev, PCI_COMMAND, 0x05);
I have all the address registered.
My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
alive. Thus I get some of the most beuatiful lockups ever.
I suspect that this needs to be handled down in the arch.
./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
Basically I can not get the IO's active, regardless of BIOS on the card.
Yes this is the old trick that used to work of making ix86 cards run in
non ix86-pci slots.
Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
under Mac OS, but the IO's are not enable in linux and it crash like a big
dog also.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Date:Wed, 13 Sep 2000 18:00:02 -0700 (PDT) From: Matthew Jacob [EMAIL PROTECTED] This seems to be an artifact of some OBP implementations for PPC- apples in particular. It assigns both I/O and Mem addrs and IRQs, but doesn't enable either memory or I/O. So you have to do it for it. Yeah, but this doesn't belong in the drivers that is for sure. It belongs in arch/ppc/kernel/*pci*.c This is precisely the kind of compat stuff which should be fixed up in the arch-specific PCI support code. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, 13 Sep 2000, David S. Miller wrote: Date: Wed, 13 Sep 2000 18:00:02 -0700 (PDT) From: Matthew Jacob [EMAIL PROTECTED] This seems to be an artifact of some OBP implementations for PPC- apples in particular. It assigns both I/O and Mem addrs and IRQs, but doesn't enable either memory or I/O. So you have to do it for it. Yeah, but this doesn't belong in the drivers that is for sure. It belongs in arch/ppc/kernel/*pci*.c This is precisely the kind of compat stuff which should be fixed up in the arch-specific PCI support code. I couldn't agree more. However- I can only write the bits for my driver and maybe *suggest* stuff to the PPC maintainers (I'm relatively new to having a PPC to play with). -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, 13 Sep 2000, David S. Miller wrote: Date: Wed, 13 Sep 2000 18:00:02 -0700 (PDT) From: Matthew Jacob [EMAIL PROTECTED] This seems to be an artifact of some OBP implementations for PPC- apples in particular. It assigns both I/O and Mem addrs and IRQs, but doesn't enable either memory or I/O. So you have to do it for it. Yeah, but this doesn't belong in the drivers that is for sure. Verified, because it fails and it is way to late. It belongs in arch/ppc/kernel/*pci*.c This is precisely the kind of compat stuff which should be fixed up in the arch-specific PCI support code. Martin, cross-platform party on PCI stuff Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
