PowerPC 440EPx Sequoia USB OHCI DTS entry

PowerPC 440EPx Sequoia USB OHCI device tree entry.

Signed-off-by Valentine Barshak <[email protected]>

---
 arch/powerpc/boot/dts/sequoia.dts |    7 +++++++
 1 files changed, 7 insertions(+)

diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts linux-2.6/arch/powerpc/boot/dts/sequoia.dts

arch/powerpc/boot/dts/sequoia.dts +7 -0

@@ -122,6 +122,13 @@
 			interrupt-map-mask = <ffffffff>;
 		};
 
+		USB1: usb@e0000400 {
+			compatible = "ohci-be";
+			reg = <0 e0000400 60>;
+			interrupt-parent = <&UIC0>;
+			interrupts = <15 8>;
+		};
+
 		POB0: opb {
 		  	compatible = "ibm,opb-440epx", "ibm,opb";
 			#address-cells = <1>;

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Quoted 3 lines · On Mon, 8 Oct 2007 18:26:58 +0400 Valentine Barshak <[email protected]>…

PowerPC 440EPx Sequoia USB OHCI device tree entry.

Signed-off-by Valentine Barshak <[email protected]>

I think I saw the OHCI big endian quirk patch go into Linus' tree recently. Is that the only patch this one depends on?

josh

Quoted 25 lines

---
 arch/powerpc/boot/dts/sequoia.dts |    7 +++++++
 1 files changed, 7 insertions(+)

diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts linux-2.6/arch/powerpc/boot/dts/sequoia.dts

arch/powerpc/boot/dts/sequoia.dts +7 -0

@@ -122,6 +122,13 @@
 			interrupt-map-mask = <ffffffff>;
 		};
 
+		USB1: usb@e0000400 {
+			compatible = "ohci-be";
+			reg = <0 e0000400 60>;
+			interrupt-parent = <&UIC0>;
+			interrupts = <15 8>;
+		};
+
 		POB0: opb {
 		  	compatible = "ibm,opb-440epx", "ibm,opb";
 			#address-cells = <1>;

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Quoted 5 lines · Josh Boyer

Quoted 2 lines · On Mon, 8 Oct 2007 18:26:58 +0400 Valentine Barshak <[email protected]>…

PowerPC 440EPx Sequoia USB OHCI device tree entry.

Quoted 5 lines

Quoted 1 line

Signed-off-by Valentine Barshak <[email protected]>

I think I saw the OHCI big endian quirk patch go into Linus' tree recently. Is that the only patch this one depends on?

Yes, now we only need a dts entry to enable ohci support for 440EP(x), Valentine.

Quoted 1 line

+ compatible = "ohci-be";

Can we fix this please, in the same way as with EHCI? I.e., the "compatible" should say it is USB, e.g. "usb-ohci"; and the "big-endian" quirkiness should be expressed by a property, not by the "compatible" name (since that would lead to exponential explosion of all possible combinations of quirks, if nothing else).

Segher

Actually I also don't see much reason for the USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff. Is this really needed?

Quoted 2 lines · Valentine

Actually I also don't see much reason for the USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff. Is this really needed?

I think so. The SOC host controllers are BE and the PCI host controllers are LE. Or, do you have an alternative method of handling both types?

-Dale

Quoted 8 lines · Dale Farnsworth

Quoted 3 lines · Valentine

Actually I also don't see much reason for the USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff. Is this really needed?

I think so. The SOC host controllers are BE and the PCI host controllers are LE. Or, do you have an alternative method of handling both types?

Yes, PCI controllers are LE, but do we really need user-selectable USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected by default for USB_OHCI_HCD_PCI?
The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only. I think it's useless. We should always enable USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF and the real LE/BE implementation should be selected by the corresponding properties in the device tree.

Quoted 7 lines · Valentine Barshak

Quoted 6 lines · Dale Farnsworth

Quoted 2 lines · Valentine

Actually I also don't see much reason for the USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff. Is this really needed?

I think so. The SOC host controllers are BE and the PCI host controllers are LE. Or, do you have an alternative method of handling both types?

Quoted 6 lines

Yes, PCI controllers are LE, but do we really need user-selectable USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected by default for USB_OHCI_HCD_PCI?
The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only.
I think it's useless. We should always enable
USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF
and the real LE/BE implementation should be selected by the corresponding properties in the device tree.

I agree that they don't need to be user selectable. It is far preferable to deduce their values from existing information, if possible.

-Dale

Quoted 18 lines · Dale Farnsworth

Quoted 8 lines · Valentine Barshak

Quoted 7 lines · Dale Farnsworth

Quoted 3 lines · Valentine

Actually I also don't see much reason for the USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff. Is this really needed?

I think so. The SOC host controllers are BE and the PCI host controllers are LE. Or, do you have an alternative method of handling both types?

Quoted 8 lines

Yes, PCI controllers are LE, but do we really need user-selectable USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected by default for USB_OHCI_HCD_PCI?
The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only. I think it's useless. We should always enable USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF and the real LE/BE implementation should be selected by the corresponding properties in the device tree.

Quoted 4 lines

I agree that they don't need to be user selectable. It is far preferable to deduce their values from existing information, if possible.

-Dale

This is the original thread:
http://ozlabs.org/pipermail/linuxppc-embedded/2006-November/025054.html

I think the USB_OHCI_HCD_PPC_OF_LE/BE should be removed.
We can't avoid the slight overhead even using these options, since USB_OHCI_BIG_ENDIAN_MMIO/DESC should always be anabled for PPC OF and we we still enable USB_OHCI_LITTLE_ENDIAN for USB_OHCI_HCD_PCI even if USB_OHCI_HCD_PPC_OF_LE is not set.

Quoted 18 lines · Valentine Barshak

Quoted 17 lines · Dale Farnsworth

Quoted 7 lines · Valentine Barshak

Quoted 6 lines · Dale Farnsworth

Quoted 2 lines · Valentine

Actually I also don't see much reason for the USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff. Is this really needed?

I think so. The SOC host controllers are BE and the PCI host controllers are LE. Or, do you have an alternative method of handling both types?

Quoted 6 lines

Yes, PCI controllers are LE, but do we really need user-selectable USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected by default for USB_OHCI_HCD_PCI?
The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only.
I think it's useless. We should always enable
USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF
and the real LE/BE implementation should be selected by the corresponding properties in the device tree.

I agree that they don't need to be user selectable. It is far preferable to deduce their values from existing information, if possible.

Quoted 6 lines

Quoted 1 line

-Dale

This is the original thread:
http://ozlabs.org/pipermail/linuxppc-embedded/2006-November/025054.html

I think the USB_OHCI_HCD_PPC_OF_LE/BE should be removed.
We can't avoid the slight overhead even using these options, since USB_OHCI_BIG_ENDIAN_MMIO/DESC should always be anabled for PPC OF and we we still enable USB_OHCI_LITTLE_ENDIAN for USB_OHCI_HCD_PCI even if USB_OHCI_HCD_PPC_OF_LE is not set.

I believe you are saying that we can select any valid combination of USB_OHCI_BIG_ENDIAN_DESC, USB_OHCI_BIG_ENDIAN_MMIO, and USB_OHCI_LITTLE_ENDIAN, without using USB_OHCI_HCD_PPC_OF_BE and USB_OHCI_HCD_PPC_OF_LE. I agree. It looks like we can get rid of these last two with zero loss in performance or functionality.

Do you have a patch?

-Dale