But 0 _is_ a valid PCI I/O address. Do we now have to start
I wasn't in PCI 2.1 (later the corresponding passage have
disppeared).
SFF controllers often use 0 to indicate a channel isn't configured and
present. Libata and old IDE both assume these semantics for an SFF
IDE device reportin
The hardware is called (E)IDE, the protocol is called ATA.
Or that's what I was told -- I think there's some historic
revisionism involved, too.
ATA is the interface and standards for the ANSI standards based disk
attachment. IDE "Integrated Drive Electronics" is a marketing name used
to cover a
More importantly, "reg-shift" doesn't say what part of
the bigger words to access. A common example is byte-wide
registers on a 32-bit-only bus; it's about 50%-50% between
connecting the registers to the low byte vs. connecting it
to the byte with the lowest address.
We already have "big-end
I never suggested that -- what I did suggest was make of_serial.c
recognize certain chip types and register them with 8250 driver.
What would be the advantage of maintaining a list of chips whose only
difference is register spacing, rather than just using reg-shift and
being done with it?
r
+ [EMAIL PROTECTED] {
+ compatible = "mmio-ide";
+ device_type = "ide";
Why not "ata"?
The hardware is called (E)IDE, the protocol is called ATA.
Or that's what I was told -- I think there's some historic
revisionism involved, too.
Also, what mmio-i
This doesn't mean that shift is better anyway. If everyone
considers it
better, I give up. But be warned that shift (stride) is not the only
property
characterizing register accesses -- the regs might be only accessible
as
16/32-bit quantities, for example (16-bit is a real world example --
+ [EMAIL PROTECTED] {
+ #interrupt-cells = <2>;
Hm, why define that prop for a node with no children?
+ interrupts = <17 8>;
+ interrupt-map = <0 0 0 1 700 17 8>;
+ interrupt-map-mask = <0
Also, in this particular case, the bindings are not standardized, and
there's a good chance that whatever new platform uses a similar device
will need to do something slightly different.
Yeah, everyone else will do the sane thing, and describe
the two register ranges the IDE uses, not a much big
It's unlikely that this driver will ever be of any use on other
architectures.
It's already being used, for example, the AMD8111 is used
one some PowerPC systems (some with IDE connected even).
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a mess
setup-pci is for SFF8038i devices. It therefore knows that for
assigned
resources they must be I/O. It also assumes that zero is not a
valid I/O
port just like zero is not a valid IRQ. Stick a real IDE resource
at zero
and drivers/ide can't cope.
But 0 _is_ a valid PCI I/O address. Do we
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -1234,6 +1234,14 @@ static void __devinit fixup_resource(str
struct pci_controller *hose = pci_bus_to_host(dev->bus);
unsigned long start, end, mask, offset;
+ /*
+* tell the core code that this
Please make this run on pSeries only; on a PowerMac for
example, it's totally normal that the first PCI legacy I/O
BAR in the system gets assigned 0.
What do you mean by legacy I/O BAR?
Any PCI BAR with bits 1:0 == 0b01.
If you mean IDE controller, that would drive IDE core mad like this:
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -1234,6 +1234,14 @@ static void __devinit fixup_resource(str
struct pci_controller *hose = pci_bus_to_host(dev->bus);
unsigned long start, end, mask, offset;
+ /*
+* tell the core code that this
13 matches
Mail list logo
