* ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
@ 2005-12-08 21:00 Jordan Crouse
2005-12-10 5:13 ` [linux-usb-devel] " David Brownell
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: Jordan Crouse @ 2005-12-08 21:00 UTC (permalink / raw)
To: linux-mips; +Cc: linux-usb-devel, matthias.lenk
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
Ok, here we go. I give you the OHCI/EHCI host controller support for
the Alchemy AU1200 processor. I'm sending this up, partly because I have
it ready to go, but also because it seems that enough folks are getting their
hands on AU1200 parts to make this a hot topic.
Special thanks to Pete Popov and his merry band of kernel hackers for
paving the way by pushing to seperate EHCI and PCI in the USB subsystem.
Note that the AU1200 does support UDC/OTG as well, but thats another patch
for another day. :)
Jordan
[-- Attachment #2: usb_host.patch --]
[-- Type: text/plain, Size: 42383 bytes --]
ALCHEMY: Add Au1200 support for OHCI and EHCI
Add the Au1200 platform to the alchemy OHCI and EHCI drivers.
Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
---
arch/mips/au1000/common/cputable.c | 2
arch/mips/au1000/common/platform.c | 4
drivers/usb/Kconfig | 8 -
drivers/usb/Makefile | 7
drivers/usb/core/Kconfig | 5
drivers/usb/core/hcd.c | 13 +
drivers/usb/core/hcd.h | 4
drivers/usb/core/hub.c | 76 ++++-
drivers/usb/core/usb.c | 63 ++++
drivers/usb/host/Kconfig | 2
drivers/usb/host/ehci-au1xxx.c | 304 ++++++++++++++++++++
drivers/usb/host/ehci-hcd.c | 81 +++++
drivers/usb/host/ehci-hub.c | 74 +++++
drivers/usb/host/ehci.h | 8 +
drivers/usb/host/ohci-au1xxx.c | 109 ++++++-
drivers/usb/host/ohci-hcd.c | 73 +++++
drivers/usb/host/ohci-hub.c | 56 ++++
drivers/usb/host/ohci-pci.c | 4
drivers/usb/host/ohci.h | 1
include/asm-mips/mach-mips/cpu-feature-overrides.h | 4
include/linux/usb.h | 7
21 files changed, 861 insertions(+), 44 deletions(-)
diff --git a/arch/mips/au1000/common/cputable.c b/arch/mips/au1000/common/cputable.c
index 4dbde82..d8df5fd 100644
--- a/arch/mips/au1000/common/cputable.c
+++ b/arch/mips/au1000/common/cputable.c
@@ -38,7 +38,7 @@ struct cpu_spec cpu_specs[] = {
{ 0xffffffff, 0x02030204, "Au1100 BE", 0, 1 },
{ 0xffffffff, 0x03030200, "Au1550 AA", 0, 1 },
{ 0xffffffff, 0x04030200, "Au1200 AB", 0, 0 },
- { 0xffffffff, 0x04030201, "Au1200 AC", 0, 1 },
+ { 0xffffffff, 0x04030201, "Au1200 AC", 1, 0 },
{ 0x00000000, 0x00000000, "Unknown Au1xxx", 1, 0 },
};
diff --git a/arch/mips/au1000/common/platform.c b/arch/mips/au1000/common/platform.c
index 48d3f54..dbb4ee7 100644
--- a/arch/mips/au1000/common/platform.c
+++ b/arch/mips/au1000/common/platform.c
@@ -20,7 +20,7 @@
static struct resource au1xxx_usb_ohci_resources[] = {
[0] = {
.start = USB_OHCI_BASE,
- .end = USB_OHCI_BASE + USB_OHCI_LEN,
+ .end = USB_OHCI_BASE + USB_OHCI_LEN - 1,
.flags = IORESOURCE_MEM,
},
[1] = {
@@ -278,9 +278,7 @@ static struct platform_device *au1xxx_pl
&au1100_lcd_device,
#endif
#ifdef CONFIG_SOC_AU1200
-#if 0 /* fixme */
&au1xxx_usb_ehci_device,
-#endif
&au1xxx_usb_gdt_device,
&au1xxx_usb_otg_device,
&au1200_lcd_device,
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 85dacc9..bff1258 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -9,10 +9,16 @@ menu "USB support"
# NOTE: SL-811 option should be board-specific ...
config USB_ARCH_HAS_HCD
boolean
- default y if USB_ARCH_HAS_OHCI
+ default y if USB_ARCH_HAS_OHCI || USB_ARCH_HAS_EHCI
default y if ARM # SL-811
default PCI
+# some non-PCI hcds implement EHCI
+config USB_ARCH_HAS_EHCI
+ boolean
+ default y if SOC_AU1200
+ default PCI
+
# many non-PCI SOC chips embed OHCI
config USB_ARCH_HAS_OHCI
boolean
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index a50c2bc..f9642e8 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -76,3 +76,10 @@ obj-$(CONFIG_USB_SISUSBVGA) += misc/
obj-$(CONFIG_USB_ATM) += atm/
obj-$(CONFIG_USB_SPEEDTOUCH) += atm/
+
+
+ifneq ($(CONFIG_USB_GADGET_AMD5536UDC),y)
+ifeq ($(CONFIG_USB_PORT_AMD5536OTG),y)
+obj-$(CONFIG_USB) += gadget/
+endif
+endif
diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index ff03184..7293161 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -82,6 +82,11 @@ config USB_OTG
select USB_SUSPEND
default n
+config USB_OTG_HIGHSPEED
+ bool
+ depends on USB_OTG
+ default n
+
config USB_OTG_WHITELIST
bool "Rely on OTG Targeted Peripherals List"
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index da24c31..031147c 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -714,6 +714,7 @@ static void usb_bus_init (struct usb_bus
bus->root_hub = NULL;
bus->hcpriv = NULL;
bus->busnum = -1;
+ bus->otg_port = 0;
bus->bandwidth_allocated = 0;
bus->bandwidth_int_reqs = 0;
bus->bandwidth_isoc_reqs = 0;
@@ -1830,6 +1831,12 @@ int usb_add_hcd(struct usb_hcd *hcd,
rhdev->speed = (hcd->driver->flags & HCD_USB2) ? USB_SPEED_HIGH :
USB_SPEED_FULL;
+#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG)
+ if ((retval = hcd->driver->start_otg (hcd)) < 0) {
+ dev_warn (hcd->self.controller, "OTG init error %d\n", retval);
+ goto err_hcd_driver_start;
+ }
+#endif
/* Although in principle hcd->driver->start() might need to use rhdev,
* none of the current drivers do.
*/
@@ -1855,6 +1862,9 @@ int usb_add_hcd(struct usb_hcd *hcd,
err_register_root_hub:
hcd->driver->stop(hcd);
+#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG)
+ hcd->driver->stop_otg (hcd);
+#endif
err_hcd_driver_start:
usb_put_dev(rhdev);
@@ -1897,6 +1907,9 @@ void usb_remove_hcd(struct usb_hcd *hcd)
del_timer_sync(&hcd->rh_timer);
hcd->driver->stop(hcd);
+#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG)
+ hcd->driver->stop_otg(hcd);
+#endif
hcd->state = HC_STATE_HALT;
if (hcd->irq >= 0)
diff --git a/drivers/usb/core/hcd.h b/drivers/usb/core/hcd.h
index c8a1b35..48c6dd6 100644
--- a/drivers/usb/core/hcd.h
+++ b/drivers/usb/core/hcd.h
@@ -216,6 +216,10 @@ struct hc_driver {
int (*bus_suspend)(struct usb_hcd *);
int (*bus_resume)(struct usb_hcd *);
int (*start_port_reset)(struct usb_hcd *, unsigned port_num);
+#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG)
+ int (*start_otg)(struct usb_hcd *);
+ void (*stop_otg)(struct usb_hcd *);
+#endif
void (*hub_irq_enable)(struct usb_hcd *);
/* Needed only if port-change IRQs are level-triggered */
};
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index f78bd12..629124e 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1228,6 +1228,10 @@ int usb_new_device(struct usb_device *ud
{
int err;
int c;
+#ifdef CONFIG_USB_OTG_WHITELIST_RELAXED
+ unsigned port1 = 0;
+ struct usb_device *root = udev->bus->root_hub;
+#endif
err = usb_get_configuration(udev);
if (err < 0) {
@@ -1253,14 +1257,29 @@ int usb_new_device(struct usb_device *ud
show_string(udev, "SerialNumber", udev->serial);
#ifdef CONFIG_USB_OTG
+
+#ifdef CONFIG_USB_OTG_WHITELIST_RELAXED
+
+ if (udev->parent) {
+
+ struct usb_device *tdev = udev;
+
+ while (tdev->parent != root)
+ tdev = tdev->parent;
+ for (port1 = 1; port1 <= root->maxchild; port1++) {
+ if (root->children[port1-1] == tdev)
+ break;
+ }
+ }
+ root = udev->parent;
+#endif
/*
* OTG-aware devices on OTG-capable root hubs may be able to use SRP,
* to wake us after we've powered off VBUS; and HNP, switching roles
* "host" to "peripheral". The OTG descriptor helps figure this out.
*/
if (!udev->bus->is_b_host
- && udev->config
- && udev->parent == udev->bus->root_hub) {
+ && udev->config) {
struct usb_otg_descriptor *desc = 0;
struct usb_bus *bus = udev->bus;
@@ -1269,6 +1288,7 @@ int usb_new_device(struct usb_device *ud
le16_to_cpu(udev->config[0].desc.wTotalLength),
USB_DT_OTG, (void **) &desc) == 0) {
if (desc->bmAttributes & USB_OTG_HNP) {
+#ifndef CONFIG_USB_OTG_WHITELIST_RELAXED
unsigned port1;
struct usb_device *root = udev->parent;
@@ -1277,15 +1297,23 @@ int usb_new_device(struct usb_device *ud
if (root->children[port1-1] == udev)
break;
}
-
- dev_info(&udev->dev,
- "Dual-Role OTG device on %sHNP port\n",
- (port1 == bus->otg_port)
- ? "" : "non-");
-
- /* enable HNP before suspend, it's simpler */
- if (port1 == bus->otg_port)
+#endif
+ if (udev->parent != bus->root_hub) {
+ dev_info(&udev->dev,
+ "Dual-Role OTG device connected through hub(s)\n");
+ bus->b_hnp_enable = 0;
+ }
+ else if (port1 == bus->otg_port) {
+ dev_info(&udev->dev,
+ "Dual-Role OTG device on HNP port\n");
bus->b_hnp_enable = 1;
+ }
+ else {
+ dev_info(&udev->dev,
+ "Dual-Role OTG device on non-HNP port\n");
+ bus->b_hnp_enable = 0;
+ }
+ /* enable HNP before suspend, it's simpler */
err = usb_control_msg(udev,
usb_sndctrlpipe(udev, 0),
USB_REQ_SET_FEATURE, 0,
@@ -1298,16 +1326,22 @@ int usb_new_device(struct usb_device *ud
* customize to match your product.
*/
dev_info(&udev->dev,
- "can't set HNP mode; %d\n",
+ "Device Not Responding (trying to set HNP mode: %d)\n",
err);
bus->b_hnp_enable = 0;
+ goto fail;
}
}
}
}
- if (!is_targeted(udev)) {
-
+#ifdef CONFIG_USB_OTG_WHITELIST_RELAXED
+ if (port1 && (port1 == udev->bus->otg_port) \
+ && !is_targeted(udev))
+#else
+ if (!is_targeted(udev))
+#endif
+ {
/* Maybe it can talk to us, though we can't talk to it.
* (Includes HNP test device.)
*/
@@ -1315,10 +1349,12 @@ int usb_new_device(struct usb_device *ud
static int __usb_suspend_device(struct usb_device *,
int port1);
err = __usb_suspend_device(udev, udev->bus->otg_port);
- if (err < 0)
+ if (err < 0) {
dev_dbg(&udev->dev, "HNP fail, %d\n", err);
+ goto fail;
+ }
}
- err = -ENODEV;
+ err = -ENOTCONN;
goto fail;
}
#endif
@@ -2565,6 +2601,16 @@ static void hub_port_connect_change(stru
}
up (&udev->serialize);
+
+#ifdef CONFIG_USB_OTG
+
+ /* don't want to disturb HNP: no retry */
+ if ((udev->bus->is_b_host || udev->bus->b_hnp_enable)
+ && (status == -ENOTCONN))
+ /* FIXME: rather keep the port enabled until */
+ /* disconnect, but it works this way */
+ goto loop;
+#endif
if (status)
goto loop_disable;
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index e197ce9..13113b3 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -81,6 +81,11 @@ static struct device_driver usb_generic_
static int usb_generic_driver_data;
+#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG)
+
+struct otg_transceiver * (*usb_otg_get_transceiver)(void) = NULL;
+#endif
+
/* called from driver core with usb_bus_type.subsys writelock */
static int usb_probe_interface(struct device *dev)
{
@@ -1485,6 +1490,58 @@ static int usb_generic_resume(struct dev
return 0;
}
+#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG)
+/*
+ * To be called from OTG controller driver
+ */
+int usb_host_register_otg(struct otg_transceiver * (*get_transceiver)(void))
+{
+ struct list_head *tmp;
+ struct usb_bus *bus;
+ struct usb_hcd *hcd;
+
+ if (get_transceiver) {
+ usb_otg_get_transceiver = get_transceiver;
+ down (&usb_bus_list_lock);
+ tmp = usb_bus_list.next;
+ while (tmp != &usb_bus_list) {
+ bus = list_entry(tmp, struct usb_bus, bus_list);
+ tmp = tmp->next;
+ hcd = container_of (bus, struct usb_hcd, self);
+ hcd->driver->start_otg (hcd);
+ }
+ up (&usb_bus_list_lock);
+ pr_info("USB OTG driver registered\n");
+ return 0;
+ }
+ else {
+ printk(KERN_ERR "can't register OTG, no device\n");
+ return -ENODEV;
+ }
+}
+
+void usb_host_deregister_otg(void)
+{
+ struct list_head *tmp;
+ struct usb_bus *bus;
+ struct usb_hcd *hcd;
+
+ down (&usb_bus_list_lock);
+ tmp = usb_bus_list.next;
+ while (tmp != &usb_bus_list) {
+ bus = list_entry(tmp, struct usb_bus, bus_list);
+ tmp = tmp->next;
+ if (bus->otg_port) {
+ hcd = container_of (bus, struct usb_hcd, self);
+ hcd->driver->stop_otg (hcd);
+ }
+ }
+ up (&usb_bus_list_lock);
+ usb_otg_get_transceiver = NULL;
+ pr_info("USB OTG driver deregistered\n");
+}
+#endif
+
struct bus_type usb_bus_type = {
.name = "usb",
.match = usb_device_match,
@@ -1642,4 +1699,10 @@ EXPORT_SYMBOL (usb_buffer_dmasync_sg);
#endif
EXPORT_SYMBOL (usb_buffer_unmap_sg);
+#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG)
+EXPORT_SYMBOL(usb_host_register_otg);
+EXPORT_SYMBOL(usb_host_deregister_otg);
+EXPORT_SYMBOL(usb_otg_get_transceiver);
+#endif
+
MODULE_LICENSE("GPL");
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index ed1899d..4a4db1a 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -6,7 +6,7 @@ comment "USB Host Controller Drivers"
config USB_EHCI_HCD
tristate "EHCI HCD (USB 2.0) support"
- depends on USB && PCI
+ depends on USB && USB_ARCH_HAS_EHCI
---help---
The Enhanced Host Controller Interface (EHCI) is standard for USB 2.0
"high speed" (480 Mbit/sec, 60 Mbyte/sec) host controller hardware.
diff --git a/drivers/usb/host/ehci-au1xxx.c b/drivers/usb/host/ehci-au1xxx.c
new file mode 100644
index 0000000..32cf6e6
--- /dev/null
+++ b/drivers/usb/host/ehci-au1xxx.c
@@ -0,0 +1,304 @@
+/*
+ * EHCI HCD (Host Controller Driver) for USB.
+ *
+ * (C) Copyright 2000-2004 David Brownell <dbrownell@users.sourceforge.net>
+ *
+ * Bus Glue for AMD Alchemy Au1xxx
+ *
+ * Based on "ohci-au1xxx.c" by Matt Porter <mporter@kernel.crashing.org>
+ *
+ * Modified for AMD Alchemy Au1200 EHC
+ * by K.Boge <karsten.boge@amd.com>
+ *
+ * This file is licenced under the GPL.
+ */
+
+#include <linux/platform_device.h>
+#include <asm/mach-au1x00/au1000.h>
+
+#ifndef CONFIG_SOC_AU1200
+#error "Alchemy chip doesn't have EHC"
+#else /* Au1200 */
+
+#define USB_HOST_CONFIG (USB_MSR_BASE + USB_MSR_MCFG)
+#define USB_MCFG_PFEN (1<<31)
+#define USB_MCFG_RDCOMB (1<<30)
+#define USB_MCFG_SSDEN (1<<23)
+#define USB_MCFG_PHYPLLEN (1<<19)
+#define USB_MCFG_EHCCLKEN (1<<17)
+#define USB_MCFG_UCAM (1<<7)
+#define USB_MCFG_EBMEN (1<<3)
+#define USB_MCFG_EMEMEN (1<<2)
+
+#define USBH_ENABLE_CE (USB_MCFG_PHYPLLEN | USB_MCFG_EHCCLKEN)
+#ifdef CONFIG_DMA_COHERENT
+#define USBH_ENABLE_INIT (USBH_ENABLE_CE \
+ | USB_MCFG_PFEN | USB_MCFG_RDCOMB \
+ | USB_MCFG_SSDEN | USB_MCFG_UCAM \
+ | USB_MCFG_EBMEN | USB_MCFG_EMEMEN)
+#else
+#define USBH_ENABLE_INIT (USBH_ENABLE_CE \
+ | USB_MCFG_PFEN | USB_MCFG_RDCOMB \
+ | USB_MCFG_SSDEN \
+ | USB_MCFG_EBMEN | USB_MCFG_EMEMEN)
+#endif
+#define USBH_DISABLE (USB_MCFG_EBMEN | USB_MCFG_EMEMEN)
+
+#endif /* Au1200 */
+
+extern int usb_disabled(void);
+
+/*-------------------------------------------------------------------------*/
+
+static void au1xxx_start_ehc(struct platform_device *dev)
+{
+ pr_debug(__FILE__ ": starting Au1xxx EHCI USB Controller\n");
+
+ /* write HW defaults again in case Yamon cleared them */
+ if (au_readl(USB_HOST_CONFIG) == 0) {
+ au_writel(0x00d02000, USB_HOST_CONFIG);
+ au_readl(USB_HOST_CONFIG);
+ udelay(1000);
+ }
+ /* enable host controller */
+ au_writel(USBH_ENABLE_CE | au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG);
+ au_readl(USB_HOST_CONFIG);
+ udelay(1000);
+ au_writel(USBH_ENABLE_INIT | au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG);
+ au_readl(USB_HOST_CONFIG);
+ udelay(1000);
+
+ pr_debug(__FILE__ ": Clock to USB host has been enabled\n");
+}
+
+static void au1xxx_stop_ehc(struct platform_device *dev)
+{
+ pr_debug(__FILE__ ": stopping Au1xxx EHCI USB Controller\n");
+
+ /* Disable mem */
+ au_writel(~USBH_DISABLE & au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG);
+ udelay(1000);
+ /* Disable clock */
+ au_writel(~USB_MCFG_EHCCLKEN & au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG);
+ au_readl(USB_HOST_CONFIG);
+}
+
+/*-------------------------------------------------------------------------*/
+
+/* configure so an HC device and id are always provided */
+/* always called with process context; sleeping is OK */
+
+
+/**
+ * usb_ehci_au1xxx_probe - initialize Au1xxx-based HCDs
+ * Context: !in_interrupt()
+ *
+ * Allocates basic resources for this USB host controller, and
+ * then invokes the start() method for the HCD associated with it
+ * through the hotplug entry's driver_data.
+ *
+ */
+int usb_ehci_au1xxx_probe (const struct hc_driver *driver,
+ struct usb_hcd **hcd_out,
+ struct platform_device *dev)
+{
+ int retval;
+ struct usb_hcd *hcd;
+
+#if defined(CONFIG_SOC_AU1200) && defined(CONFIG_DMA_COHERENT)
+
+ /* Au1200 AB USB does not support coherent memory */
+ if (!(read_c0_prid() & 0xff)) {
+ pr_info ("Au1200 ohci: !!! This is chip revision AB !!!\n");
+ pr_info (" !!! update your board or re-configure the kernel !!!\n");
+ return -ENODEV;
+ }
+#endif
+
+ if (dev->resource[1].flags != IORESOURCE_IRQ) {
+ pr_debug ("resource[1] is not IORESOURCE_IRQ");
+ retval = -ENOMEM;
+ }
+
+ hcd = usb_create_hcd(driver, &dev->dev, "Au1xxx");
+ if (!hcd)
+ return -ENOMEM;
+ hcd->rsrc_start = dev->resource[0].start;
+ hcd->rsrc_len = dev->resource[0].end - dev->resource[0].start + 1;
+
+ if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) {
+ pr_debug("request_mem_region failed");
+ retval = -EBUSY;
+ goto err1;
+ }
+
+ hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len);
+ if (!hcd->regs) {
+ pr_debug("ioremap failed");
+ retval = -ENOMEM;
+ goto err2;
+ }
+
+ au1xxx_start_ehc(dev);
+
+ if ((retval = driver->reset (hcd)) < 0) {
+ pr_debug ("can't reset hc\n");
+ goto err3;
+ }
+
+ /* ehci_hcd_init(hcd_to_ehci(hcd)); */
+
+ retval = usb_add_hcd(hcd, dev->resource[1].start, SA_INTERRUPT | SA_SHIRQ);
+ if (retval == 0)
+ return retval;
+
+ err3:
+ au1xxx_stop_ehc(dev);
+ iounmap(hcd->regs);
+ err2:
+ release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
+ err1:
+ usb_put_hcd(hcd);
+ return retval;
+}
+
+
+/* may be called without controller electrically present */
+/* may be called with controller, bus, and devices active */
+
+/**
+ * usb_ehci_hcd_au1xxx_remove - shutdown processing for Au1xxx-based HCDs
+ * @dev: USB Host Controller being removed
+ * Context: !in_interrupt()
+ *
+ * Reverses the effect of usb_ehci_hcd_au1xxx_probe(), first invoking
+ * the HCD's stop() method. It is always called from a thread
+ * context, normally "rmmod", "apmd", or something similar.
+ *
+ */
+void usb_ehci_au1xxx_remove (struct usb_hcd *hcd, struct platform_device *dev)
+{
+ usb_remove_hcd(hcd);
+ au1xxx_stop_ehc(dev);
+ iounmap(hcd->regs);
+ release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
+ usb_put_hcd(hcd);
+}
+
+/*-------------------------------------------------------------------------*/
+
+static const struct hc_driver ehci_au1xxx_hc_driver = {
+ .description = hcd_name,
+ .product_desc = "Au1xxx EHCI",
+ .hcd_priv_size = sizeof(struct ehci_hcd),
+
+ /*
+ * generic hardware linkage
+ */
+ .irq = ehci_irq,
+ .flags = HCD_MEMORY | HCD_USB2,
+
+ /*
+ * basic lifecycle operations
+ */
+ .reset = ehci_init,
+ .start = ehci_run,
+#ifdef CONFIG_PM
+ /* suspend: ehci_au1xxx_suspend, -- tbd */
+ /* resume: ehci_au1xxx_resume, -- tbd */
+#endif /*CONFIG_PM*/
+ .stop = ehci_stop,
+
+ /*
+ * managing i/o requests and associated device resources
+ */
+ .urb_enqueue = ehci_urb_enqueue,
+ .urb_dequeue = ehci_urb_dequeue,
+ .endpoint_disable = ehci_endpoint_disable,
+
+ /*
+ * scheduling support
+ */
+ .get_frame_number = ehci_get_frame,
+
+ /*
+ * root hub support
+ */
+ .hub_status_data = ehci_hub_status_data,
+ .hub_control = ehci_hub_control,
+#ifdef CONFIG_USB_SUSPEND
+ .hub_suspend = ehci_hub_suspend,
+ .hub_resume = ehci_hub_resume,
+#endif
+ .start_port_reset = ehci_start_port_reset,
+#ifdef CONFIG_USB_OTG_HIGHSPEED
+ .start_otg = ehci_start_otg,
+ .stop_otg = ehci_stop_otg,
+#endif
+};
+
+/*-------------------------------------------------------------------------*/
+
+static int ehci_hcd_au1xxx_drv_probe(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct usb_hcd *hcd = NULL;
+ int ret;
+
+ pr_debug ("In ehci_hcd_au1xxx_drv_probe\n");
+
+ if (usb_disabled())
+ return -ENODEV;
+
+ ret = usb_ehci_au1xxx_probe(&ehci_au1xxx_hc_driver, &hcd, pdev);
+ return ret;
+}
+
+static int ehci_hcd_au1xxx_drv_remove(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+
+ usb_ehci_au1xxx_remove(hcd, pdev);
+ return 0;
+}
+ /*TBD*/
+/*static int ehci_hcd_au1xxx_drv_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+
+ return 0;
+}
+static int ehci_hcd_au1xxx_drv_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+
+ return 0;
+}
+*/
+
+static struct device_driver ehci_hcd_au1xxx_driver = {
+ .name = "au1xxx-ehci",
+ .bus = &platform_bus_type,
+ .probe = ehci_hcd_au1xxx_drv_probe,
+ .remove = ehci_hcd_au1xxx_drv_remove,
+ /*.suspend = ehci_hcd_au1xxx_drv_suspend, */
+ /*.resume = ehci_hcd_au1xxx_drv_resume, */
+};
+
+static int __init ehci_hcd_au1xxx_init (void)
+{
+ pr_debug (DRIVER_INFO " (Au1xxx)\n");
+
+ return driver_register(&ehci_hcd_au1xxx_driver);
+}
+
+static void __exit ehci_hcd_au1xxx_cleanup (void)
+{
+ driver_unregister(&ehci_hcd_au1xxx_driver);
+}
+
+module_init (ehci_hcd_au1xxx_init);
+module_exit (ehci_hcd_au1xxx_cleanup);
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 29f52a4..2b431ef 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -40,6 +40,7 @@
#include <linux/interrupt.h>
#include <linux/reboot.h>
#include <linux/usb.h>
+#include <linux/usb_otg.h>
#include <linux/moduleparam.h>
#include <linux/dma-mapping.h>
@@ -124,6 +125,11 @@ static const char hcd_name [] = "ehci_hc
#define EHCI_ASYNC_JIFFIES (HZ/20) /* async idle timeout */
#define EHCI_SHRINK_JIFFIES (HZ/200) /* async qh unlink delay */
+#if (EHCI_SHRINK_JIFFIES < 1)
+#undef EHCI_SHRINK_JIFFIES
+#define EHCI_SHRINK_JIFFIES 1
+#endif
+
/* Initial IRQ latency: faster than hw default */
static int log2_irq_thresh = 0; // 0 to 6
module_param (log2_irq_thresh, int, S_IRUGO);
@@ -418,7 +424,7 @@ static int ehci_init(struct usb_hcd *hcd
u32 temp;
int retval;
u32 hcc_params;
-
+
spin_lock_init(&ehci->lock);
init_timer(&ehci->watchdog);
@@ -573,6 +579,66 @@ static int ehci_run (struct usb_hcd *hcd
/*-------------------------------------------------------------------------*/
+#if defined(CONFIG_USB_OTG_HIGHSPEED) && defined(CONFIG_USB_PORT_AMD5536OTG)
+
+static int ehci_start_otg (struct usb_hcd *hcd)
+{
+ struct ehci_hcd *ehci = hcd_to_ehci (hcd);
+
+ if (!hcd->self.otg_port) {
+ hcd->self.otg_port = USB_OTG_PORT;
+ ehci->power_budget = OTG_PWR_BUDGET;
+ }
+ if (usb_otg_get_transceiver) {
+ ehci->transceiver = usb_otg_get_transceiver();
+ if (ehci->transceiver) {
+ int status;
+
+ if (ehci->transceiver->host) {
+ ehci_err (ehci, "OTG already registered\n");
+ return -EBUSY;
+ }
+ ehci->transceiver->host = &hcd->self;
+ hcd->self.hand_over = 0;
+ status = ehci->transceiver->set_host(
+ ehci->transceiver, &hcd->self);
+
+ ehci_dbg (ehci, "init %s transceiver, status %d\n",
+ ehci->transceiver->label, status);
+
+ /* if (status)
+ put_device(ehci->transceiver->dev); */
+ return status;
+ }
+ else {
+ ehci_err (ehci, "can't find transceiver\n");
+ return -ENODEV;
+ }
+ }
+ else {
+ ehci_info (ehci, "OTG driver not loaded\n");
+ return 0;
+ }
+}
+
+static void ehci_stop_otg (struct usb_hcd *hcd)
+{
+ struct ehci_hcd *ehci = hcd_to_ehci (hcd);
+
+ ehci_dbg (ehci, "clean up %s transceiver\n",
+ ehci->transceiver->label);
+ if (ehci->transceiver) {
+ ehci->transceiver->host = NULL;
+ ehci->transceiver->set_host(ehci->transceiver, NULL);
+ }
+ ehci->transceiver = NULL;
+ ehci->power_budget = 0;
+ hcd->self.otg_port = 0;
+}
+#endif
+
+/*-------------------------------------------------------------------------*/
+
static irqreturn_t ehci_irq (struct usb_hcd *hcd, struct pt_regs *regs)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
@@ -884,20 +950,23 @@ static int ehci_get_frame (struct usb_hc
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
return (readl (&ehci->regs->frame_index) >> 3) % ehci->periodic_size;
+#if defined(CONFIG_USB_OTG_HIGHSPEED) && defined(CONFIG_USB_PORT_AMD5536OTG)
+ .start_otg = ehci_start_otg,
+ .stop_otg = ehci_stop_otg,
+#endif
}
/*-------------------------------------------------------------------------*/
#define DRIVER_INFO DRIVER_VERSION " " DRIVER_DESC
-
MODULE_DESCRIPTION (DRIVER_INFO);
MODULE_AUTHOR (DRIVER_AUTHOR);
MODULE_LICENSE ("GPL");
-#ifdef CONFIG_PCI
+#if defined(CONFIG_SOC_AU1X00)
+#include "ehci-au1xxx.c"
+#elif defined(CONFIG_PCI)
#include "ehci-pci.c"
-#endif
-
-#if !defined(CONFIG_PCI)
+#else
#error "missing bus glue for ehci-hcd"
#endif
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 82caf33..26e070d 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -201,6 +201,17 @@ static int check_reset_complete (
port_status |= PORT_OWNER;
port_status &= ~PORT_RWC_BITS;
writel (port_status, &ehci->regs->port_status [index]);
+
+#if defined(CONFIG_USB_OTG_HIGHSPEED) && defined(CONFIG_USB_PORT_AMD5536OTG)
+
+ if (ehci->transceiver &&
+ ((index + 1) == ehci_to_hcd(ehci)->self.otg_port) &&
+ (ehci->transceiver->companion)) {
+ ehci->transceiver->companion->hand_over = 1;
+ usb_bus_start_enum (ehci->transceiver->companion,
+ ehci->transceiver->companion->otg_port);
+ }
+#endif
} else
ehci_dbg (ehci, "port %d high speed\n", index + 1);
@@ -304,6 +315,59 @@ ehci_hub_descriptor (
/*-------------------------------------------------------------------------*/
+#ifdef CONFIG_USB_OTG_HIGHSPEED
+
+static int ehci_start_port_reset (struct usb_hcd *hcd, unsigned port)
+{
+ struct ehci_hcd *ehci = hcd_to_ehci (hcd);
+ u32 status;
+
+ if (!port)
+ return -EINVAL;
+ port--;
+
+ /* start port reset before HNP protocol times out */
+ status = readl (&ehci->regs->port_status [port]);
+ if (status & PORT_RESUME)
+ return -EINVAL;
+
+ if (!(status & PORT_CONNECT))
+ return -ENODEV;
+
+ status |= PORT_RESET;
+ status &= ~(PORT_PE | PORT_CSC); /* PORT_CSC for khubd notification */
+ ehci->reset_done [port] = jiffies + msecs_to_jiffies (50);
+ writel (status, &ehci->regs->port_status [port]);
+ return 0;
+}
+
+#ifdef CONFIG_USB_PORT_AMD5536OTG
+
+static void start_hnp (struct ehci_hcd *ehci)
+{
+ const unsigned port = ehci_to_hcd(ehci)->self.otg_port - 1;
+ unsigned long flags;
+ u32 status;
+
+ otg_start_hnp (ehci->transceiver);
+ local_irq_save (flags);
+ status = readl (&ehci->regs->port_status [port]);
+ if (!(status & PORT_OWNER) && (status & PORT_PE))
+ writel (status | PORT_SUSPEND, &ehci->regs->port_status [port]);
+ local_irq_restore (flags);
+}
+#endif
+
+static void start_hnp (struct ehci_hcd *ehci);
+
+#else
+
+#define ehci_start_port_reset NULL
+
+#endif
+
+/*-------------------------------------------------------------------------*/
+
#define PORT_WAKE_BITS (PORT_WKOC_E|PORT_WKDISC_E|PORT_WKCONN_E)
static int ehci_hub_control (
@@ -517,10 +581,20 @@ static int ehci_hub_control (
if ((temp & PORT_PE) == 0
|| (temp & PORT_RESET) != 0)
goto error;
+#ifdef CONFIG_USB_OTG_HIGHSPEED
+ if (hcd->self.otg_port == (wIndex + 1)
+ && hcd->self.b_hnp_enable)
+ start_hnp(ehci);
+ else {
+#endif
+
if (hcd->remote_wakeup)
temp |= PORT_WAKE_BITS;
writel (temp | PORT_SUSPEND,
&ehci->regs->port_status [wIndex]);
+#ifdef CONFIG_USB_OTG_HIGHSPEED
+ }
+#endif
break;
case USB_PORT_FEAT_POWER:
if (HCS_PPC (ehci->hcs_params))
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 18e257c..d762443 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -75,6 +75,14 @@ struct ehci_hcd { /* one per controlle
/* per root hub port */
unsigned long reset_done [EHCI_MAX_ROOT_PORTS];
+#ifdef CONFIG_USB_OTG_HIGHSPEED
+ /*
+ * OTG controller needs software interaction
+ */
+ struct otg_transceiver *transceiver;
+ unsigned power_budget;
+#endif
+
/* per-HC memory pools (could be per-bus, but ...) */
struct dma_pool *qh_pool; /* qh per active urb */
struct dma_pool *qtd_pool; /* one or more per qh */
diff --git a/drivers/usb/host/ohci-au1xxx.c b/drivers/usb/host/ohci-au1xxx.c
index 486202d..a5f2dfe 100644
--- a/drivers/usb/host/ohci-au1xxx.c
+++ b/drivers/usb/host/ohci-au1xxx.c
@@ -19,9 +19,10 @@
*/
#include <linux/platform_device.h>
-
#include <asm/mach-au1x00/au1000.h>
+#ifndef CONFIG_SOC_AU1200
+
#define USBH_ENABLE_BE (1<<0)
#define USBH_ENABLE_C (1<<1)
#define USBH_ENABLE_E (1<<2)
@@ -36,16 +37,46 @@
#error not byte order defined
#endif
+#else /* Au1200 */
+
+#define USB_HOST_CONFIG (USB_MSR_BASE + USB_MSR_MCFG)
+#define USB_MCFG_PFEN (1<<31)
+#define USB_MCFG_RDCOMB (1<<30)
+#define USB_MCFG_SSDEN (1<<23)
+#define USB_MCFG_OHCCLKEN (1<<16)
+#define USB_MCFG_UCAM (1<<7)
+#define USB_MCFG_OBMEN (1<<1)
+#define USB_MCFG_OMEMEN (1<<0)
+
+#define USBH_ENABLE_CE USB_MCFG_OHCCLKEN
+#ifdef CONFIG_DMA_COHERENT
+#define USBH_ENABLE_INIT (USB_MCFG_OHCCLKEN \
+ | USB_MCFG_PFEN | USB_MCFG_RDCOMB \
+ | USB_MCFG_SSDEN | USB_MCFG_UCAM \
+ | USB_MCFG_OBMEN | USB_MCFG_OMEMEN)
+#else
+#define USBH_ENABLE_INIT (USB_MCFG_OHCCLKEN \
+ | USB_MCFG_PFEN | USB_MCFG_RDCOMB \
+ | USB_MCFG_SSDEN \
+ | USB_MCFG_OBMEN | USB_MCFG_OMEMEN)
+#endif
+#define USBH_DISABLE (USB_MCFG_OBMEN | USB_MCFG_OMEMEN)
+
+#endif /* Au1200 */
+
extern int usb_disabled(void);
/*-------------------------------------------------------------------------*/
-static void au1xxx_start_hc(struct platform_device *dev)
+static void au1xxx_start_ohc(struct platform_device *dev)
{
printk(KERN_DEBUG __FILE__
": starting Au1xxx OHCI USB Controller\n");
/* enable host controller */
+
+#ifndef CONFIG_SOC_AU1200
+
au_writel(USBH_ENABLE_CE, USB_HOST_CONFIG);
udelay(1000);
au_writel(USBH_ENABLE_INIT, USB_HOST_CONFIG);
@@ -56,17 +87,46 @@ static void au1xxx_start_hc(struct platf
!(au_readl(USB_HOST_CONFIG) & USBH_ENABLE_RD))
udelay(1000);
+#else /* Au1200 */
+
+ /* write HW defaults again in case Yamon cleared them */
+ if (au_readl(USB_HOST_CONFIG) == 0) {
+ au_writel(0x00d02000, USB_HOST_CONFIG);
+ au_readl(USB_HOST_CONFIG);
+ udelay(1000);
+ }
+ au_writel(USBH_ENABLE_CE | au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG);
+ au_readl(USB_HOST_CONFIG);
+ udelay(1000);
+ au_writel(USBH_ENABLE_INIT | au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG);
+ au_readl(USB_HOST_CONFIG);
+ udelay(1000);
+
+#endif /* Au1200 */
+
printk(KERN_DEBUG __FILE__
": Clock to USB host has been enabled \n");
}
-static void au1xxx_stop_hc(struct platform_device *dev)
+static void au1xxx_stop_ohc(struct platform_device *dev)
{
printk(KERN_DEBUG __FILE__
": stopping Au1xxx OHCI USB Controller\n");
+#ifndef CONFIG_SOC_AU1200
+
/* Disable clock */
au_writel(readl((void *)USB_HOST_CONFIG) & ~USBH_ENABLE_CE, USB_HOST_CONFIG);
+
+#else /* Au1200 */
+
+ /* Disable mem */
+ au_writel(~USBH_DISABLE & au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG);
+ udelay(1000);
+ /* Disable clock */
+ au_writel(~USBH_ENABLE_CE & au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG);
+ au_readl(USB_HOST_CONFIG);
+#endif /* Au1200 */
}
@@ -85,14 +145,24 @@ static void au1xxx_stop_hc(struct platfo
* through the hotplug entry's driver_data.
*
*/
-int usb_hcd_au1xxx_probe (const struct hc_driver *driver,
+int usb_ohci_au1xxx_probe (const struct hc_driver *driver,
struct platform_device *dev)
{
int retval;
struct usb_hcd *hcd;
+#if defined(CONFIG_SOC_AU1200) && defined(CONFIG_DMA_COHERENT)
+
+ /* Au1200 AB USB does not support coherent memory */
+ if (!(read_c0_prid() & 0xff)) {
+ pr_info ("Au1200 ohci: !!! This is chip revision AB !!!\n");
+ pr_info (" !!! update your board or re-configure the kernel !!!\n");
+ return -ENODEV;
+ }
+#endif
+
if (dev->resource[1].flags != IORESOURCE_IRQ) {
- pr_debug ("resource[1] is not IORESOURCE_IRQ");
+ pr_debug ("resource[1] is not IORESOURCE_IRQ\n");
retval = -ENOMEM;
}
@@ -103,26 +173,26 @@ int usb_hcd_au1xxx_probe (const struct h
hcd->rsrc_len = dev->resource[0].end - dev->resource[0].start + 1;
if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) {
- pr_debug("request_mem_region failed");
+ pr_debug("request_mem_region failed\n");
retval = -EBUSY;
goto err1;
}
hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len);
if (!hcd->regs) {
- pr_debug("ioremap failed");
+ pr_debug("ioremap failed\n");
retval = -ENOMEM;
goto err2;
}
- au1xxx_start_hc(dev);
+ au1xxx_start_ohc(dev);
ohci_hcd_init(hcd_to_ohci(hcd));
- retval = usb_add_hcd(hcd, dev->resource[1].start, SA_INTERRUPT);
+ retval = usb_add_hcd(hcd, dev->resource[1].start, SA_INTERRUPT | SA_SHIRQ);
if (retval == 0)
return retval;
- au1xxx_stop_hc(dev);
+ au1xxx_stop_ohc(dev);
iounmap(hcd->regs);
err2:
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
@@ -145,10 +215,10 @@ int usb_hcd_au1xxx_probe (const struct h
* context, normally "rmmod", "apmd", or something similar.
*
*/
-void usb_hcd_au1xxx_remove (struct usb_hcd *hcd, struct platform_device *dev)
+void usb_ohci_au1xxx_remove (struct usb_hcd *hcd, struct platform_device *dev)
{
usb_remove_hcd(hcd);
- au1xxx_stop_hc(dev);
+ au1xxx_stop_ohc(dev);
iounmap(hcd->regs);
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
usb_put_hcd(hcd);
@@ -216,11 +286,15 @@ static const struct hc_driver ohci_au1xx
*/
.hub_status_data = ohci_hub_status_data,
.hub_control = ohci_hub_control,
-#ifdef CONFIG_PM
- .bus_suspend = ohci_bus_suspend,
- .bus_resume = ohci_bus_resume,
+#ifdef CONFIG_USB_SUSPEND
+ .hub_suspend = ohci_hub_suspend,
+ .hub_resume = ohci_hub_resume,
#endif
.start_port_reset = ohci_start_port_reset,
+#ifdef CONFIG_USB_OTG
+ .start_otg = ohci_start_otg,
+ .stop_otg = ohci_stop_otg,
+#endif
};
/*-------------------------------------------------------------------------*/
@@ -234,7 +308,7 @@ static int ohci_hcd_au1xxx_drv_probe(str
if (usb_disabled())
return -ENODEV;
- ret = usb_hcd_au1xxx_probe(&ohci_au1xxx_hc_driver, pdev);
+ ret = usb_ohci_au1xxx_probe(&ohci_au1xxx_hc_driver, pdev);
return ret;
}
@@ -242,7 +316,7 @@ static int ohci_hcd_au1xxx_drv_remove(st
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
- usb_hcd_au1xxx_remove(hcd, pdev);
+ usb_ohci_au1xxx_remove(hcd, pdev);
return 0;
}
/*TBD*/
@@ -287,3 +361,4 @@ static void __exit ohci_hcd_au1xxx_clean
module_init (ohci_hcd_au1xxx_init);
module_exit (ohci_hcd_au1xxx_cleanup);
+
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index b8efc6e..b610ea5 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -879,6 +879,79 @@ static int ohci_restart (struct ohci_hcd
/*-------------------------------------------------------------------------*/
+#if defined(CONFIG_USB_OTG) && (CONFIG_USB_PORT_AMD5536OTG)
+
+static int ohci_start_otg (struct usb_hcd *hcd)
+{
+ struct ohci_hcd *ohci = hcd_to_ohci (hcd);
+
+ if (!hcd->self.otg_port) {
+ hcd->self.otg_port = USB_OTG_PORT;
+ ohci->power_budget = OTG_PWR_BUDGET;
+ }
+ if (usb_otg_get_transceiver) {
+ ohci->transceiver = usb_otg_get_transceiver();
+ if (ohci->transceiver) {
+ int status;
+
+#ifdef CONFIG_USB_OTG_HIGHSPEED
+ if (ohci->transceiver->companion) {
+ ohci_err (ohci, "OTG already registered\n");
+ return -EBUSY;
+ }
+ ohci->transceiver->companion = &hcd->self;
+ hcd->self.hand_over = 0;
+#else
+ if (ohci->transceiver->host) {
+ ohci_err (ohci, "OTG already registered\n");
+ return -EBUSY;
+ }
+ ohci->transceiver->host = &hcd->self;
+#endif
+ status = ohci->transceiver->set_host(
+ ohci->transceiver, &hcd->self);
+
+ ohci_dbg(ohci, "init %s transceiver, status %d\n",
+ ohci->transceiver->label, status);
+
+ /* if (status)
+ put_device(ohci->transceiver->dev); */
+ return status;
+ }
+ else {
+ ohci_err (ohci, "can't find transceiver\n");
+ return -ENODEV;
+ }
+ }
+ else {
+ ohci_info (ohci, "OTG driver not loaded\n");
+ return 0;
+ }
+}
+
+static void ohci_stop_otg (struct usb_hcd *hcd)
+{
+ struct ohci_hcd *ohci = hcd_to_ohci (hcd);
+
+ if (ohci->transceiver) {
+ ohci_dbg (ohci, "clean up %s transceiver\n",
+ ohci->transceiver->label);
+#ifdef CONFIG_USB_OTG_HIGHSPEED
+ ohci->transceiver->companion = NULL;
+#else
+ ohci->transceiver->host = NULL;
+#endif
+ ohci->transceiver->set_host(ohci->transceiver, NULL);
+ ohci->transceiver = NULL;
+ ohci->power_budget = 0;
+ hcd->self.otg_port = 0;
+ }
+}
+
+#endif
+
+/*-------------------------------------------------------------------------*/
+
#define DRIVER_INFO DRIVER_VERSION " " DRIVER_DESC
MODULE_AUTHOR (DRIVER_AUTHOR);
diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
index 72e3b12..31a8a0d 100644
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -431,13 +431,31 @@ static int ohci_start_port_reset (struct
{
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
u32 status;
+ int usec = 500; /* 500 usec handshake time */
if (!port)
return -EINVAL;
port--;
/* start port reset before HNP protocol times out */
+#ifdef CONFIG_USB_OTG_HIGHSPEED
+
+ if (hcd->self.hand_over && (port + 1 == hcd->self.otg_port)) {
+ udelay (usec);
+ usec = 0;
+ status = ohci_readl (ohci, &ohci->regs->roothub.portstatus [port]);
+ }
+ else {
+#endif
status = ohci_readl(ohci, &ohci->regs->roothub.portstatus [port]);
+ while (usec && !(status & RH_PS_CCS)) {
+ status = ohci_readl (ohci, &ohci->regs->roothub.portstatus [port]);
+ usec--;
+ udelay(1);
+ }
+#ifdef CONFIG_USB_OTG_HIGHSPEED
+ }
+#endif
if (!(status & RH_PS_CCS))
return -ENODEV;
@@ -446,8 +464,29 @@ static int ohci_start_port_reset (struct
return 0;
}
+#ifdef CONFIG_USB_PORT_AMD5536OTG
+
+static void start_hnp (struct ohci_hcd *ohci)
+{
+ const unsigned port = ohci_to_hcd(ohci)->self.otg_port - 1;
+ unsigned long flags;
+ u32 status;
+
+ otg_start_hnp (ohci->transceiver);
+
+ local_irq_save (flags);
+ status = ohci_readl (ohci, &ohci->regs->roothub.portstatus [port]);
+ if (status & RH_PS_PES)
+ ohci_writel (ohci, RH_PS_PSS,
+ &ohci->regs->roothub.portstatus [port]);
+ local_irq_restore (flags);
+}
+#else
+
static void start_hnp(struct ohci_hcd *ohci);
+#endif
+
#else
#define ohci_start_port_reset NULL
@@ -482,10 +521,27 @@ static inline void root_port_reset (stru
u16 now = ohci_readl(ohci, &ohci->regs->fmnumber);
u16 reset_done = now + PORT_RESET_MSEC;
+#ifdef CONFIG_USB_OTG
+ struct usb_hcd *hcd = ohci_to_hcd (ohci);
+#endif
+
/* build a "continuous enough" reset signal, with up to
* 3msec gap between pulses. scheduler HZ==100 must work;
* this might need to be deadline-scheduled.
*/
+
+#ifdef CONFIG_USB_OTG
+#ifdef CONFIG_USB_OTG_HIGHSPEED
+ if (hcd->self.hand_over && (port + 1 == hcd->self.otg_port)) {
+ hcd->self.hand_over = 0;
+ reset_done = now + PORT_RESET_HW_MSEC - 1;
+ }
+ else
+#else
+ if (hcd->self.is_b_host)
+ reset_done = now + PORT_RESET_HW_MSEC - 1;
+#endif
+#endif
do {
/* spin until any current reset finishes */
for (;;) {
diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
index 1b09dde..54d3afa 100644
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -188,6 +188,10 @@ static const struct hc_driver ohci_pci_h
.bus_resume = ohci_bus_resume,
#endif
.start_port_reset = ohci_start_port_reset,
+#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG)
+ .start_otg = ohci_start_otg,
+ .stop_otg = ohci_stop_otg,
+#endif
};
/*-------------------------------------------------------------------------*/
diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h
index caacf14..b94717a 100644
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -371,6 +371,7 @@ struct ohci_hcd {
* other external transceivers should be software-transparent
*/
struct otg_transceiver *transceiver;
+ unsigned power_budget;
/*
* memory management for queue data structures
diff --git a/include/asm-mips/mach-mips/cpu-feature-overrides.h b/include/asm-mips/mach-mips/cpu-feature-overrides.h
index 9f92aed..e06af6c 100644
--- a/include/asm-mips/mach-mips/cpu-feature-overrides.h
+++ b/include/asm-mips/mach-mips/cpu-feature-overrides.h
@@ -29,7 +29,11 @@
/* #define cpu_has_prefetch ? */
#define cpu_has_mcheck 1
/* #define cpu_has_ejtag ? */
+#ifdef CONFIG_CPU_HAS_LLSC
#define cpu_has_llsc 1
+#else
+#define cpu_has_llsc 0
+#endif
/* #define cpu_has_vtag_icache ? */
/* #define cpu_has_dc_aliases ? */
/* #define cpu_has_ic_fills_f_dc ? */
diff --git a/include/linux/usb.h b/include/linux/usb.h
index d81b050..e71b584 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -270,6 +270,7 @@ struct usb_bus {
u8 otg_port; /* 0, or number of OTG/HNP port */
unsigned is_b_host:1; /* true during some HNP roleswitches */
unsigned b_hnp_enable:1; /* OTG: did A-Host enable HNP? */
+ unsigned hand_over:1; /* HS controller detected FS device */
int devnum_next; /* Next open device number in
* round-robin allocation */
@@ -1015,6 +1016,12 @@ extern int usb_clear_halt(struct usb_dev
extern int usb_reset_configuration(struct usb_device *dev);
extern int usb_set_interface(struct usb_device *dev, int ifnum, int alternate);
+#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG)
+extern struct otg_transceiver * (*usb_otg_get_transceiver)(void);
+extern int usb_host_register_otg (struct otg_transceiver * (*get_transceiver)(void));
+extern void usb_host_deregister_otg(void);
+#endif
+
/*
* timeouts, in milliseconds, used for sending/receiving control messages
* they typically complete within a few frames (msec) after they're issued
^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [linux-usb-devel] ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
2005-12-08 21:00 ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Jordan Crouse
@ 2005-12-10 5:13 ` David Brownell
2005-12-10 6:42 ` Pete Popov
2005-12-12 10:51 ` Bora Sahin
2006-01-03 14:25 ` Matej Kupljen
2 siblings, 1 reply; 37+ messages in thread
From: David Brownell @ 2005-12-10 5:13 UTC (permalink / raw)
To: linux-usb-devel; +Cc: Jordan Crouse, linux-mips, matthias.lenk
On Thursday 08 December 2005 1:00 pm, Jordan Crouse wrote:
> Ok, here we go. I give you the OHCI/EHCI host controller support for
> the Alchemy AU1200 processor. I'm sending this up, partly because I have
> it ready to go, but also because it seems that enough folks are getting their
> hands on AU1200 parts to make this a hot topic.
Interesting. This is actually a couple different things ... the OTG
related bits would IMO be good to split out from the EHCI ones, and
from the OHCI ones.
Maybe once 2.6.15 gets out you'd split these out a bit?
> Special thanks to Pete Popov and his merry band of kernel hackers for
> paving the way by pushing to seperate EHCI and PCI in the USB subsystem.
Actually that patch started with Matt Porter, although some earlier
non-mergeable versions came from ARC (now TDI). And splitting it out
turned up a bunch of problems, mostly now fixed.
> Note that the AU1200 does support UDC/OTG as well, but thats another patch
> for another day. :)
Actually you included a preview in this patch. Interesting ... that
makes three OTG implementations I've seen on Linux ... the second
highspeed one, too.
I think you shouldn't need that OTG_HIGHSPEED symbol, given there's
already USB_OTG and USB_GADGET_DUALSPEED, that's implicit. And in
fact, it'd be implicit inside EHCI given just USB_OTG!
That OTG stuff needs work yet. No <linux/usb.h> changes should be
needed, and I'm not sure what this "relaxed whitelist" is for. But
by the time those answers are apparent, I expect you'll have give
us mergeable patches for OHCI, EHCI, and the UDC. ;)
- Dave
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [linux-usb-devel] ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
2005-12-10 5:13 ` [linux-usb-devel] " David Brownell
@ 2005-12-10 6:42 ` Pete Popov
0 siblings, 0 replies; 37+ messages in thread
From: Pete Popov @ 2005-12-10 6:42 UTC (permalink / raw)
To: David Brownell
Cc: linux-usb-devel, Jordan Crouse,
'linux-mips@linux-mips.org', matthias.lenk
> > Special thanks to Pete Popov and his merry band of kernel hackers for
> > paving the way by pushing to seperate EHCI and PCI in the USB subsystem.
>
> Actually that patch started with Matt Porter, although some earlier
> non-mergeable versions came from ARC (now TDI). And splitting it out
> turned up a bunch of problems, mostly now fixed.
Matt Porter is included in the 'merry band' :) He's a partner at
Embedded Alley.
Pete
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
2005-12-08 21:00 ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Jordan Crouse
2005-12-10 5:13 ` [linux-usb-devel] " David Brownell
@ 2005-12-12 10:51 ` Bora Sahin
2006-01-03 14:25 ` Matej Kupljen
2 siblings, 0 replies; 37+ messages in thread
From: Bora Sahin @ 2005-12-12 10:51 UTC (permalink / raw)
To: Jordan Crouse; +Cc: linux-mips
Hi,
Thursday, December 8, 2005, 11:00:42 PM, you wrote:
Jordan> Ok, here we go. I give you the OHCI/EHCI host controller support for
Jordan> the Alchemy AU1200 processor. I'm sending this up, partly because I
Jordan> have it ready to go, but also because it seems that enough folks are
Jordan> getting their hands on AU1200 parts to make this a hot topic.
Especially, it's high time to me... :-)
Jordan> Special thanks to Pete Popov and his merry band of kernel hackers for
Jordan> paving the way by pushing to seperate EHCI and PCI in the USB subsystem.
Me to...
I have a few comments related to the OHCI part of it...
diff --git a/drivers/usb/host/ohci-au1xxx.c b/drivers/usb/host/ohci-au1xxx.c
+#else /* Au1200 */
+
+#define USB_HOST_CONFIG (USB_MSR_BASE + USB_MSR_MCFG)
+#define USB_MCFG_PFEN (1<<31)
+#define USB_MCFG_RDCOMB (1<<30)
+#define USB_MCFG_SSDEN (1<<23)
+#define USB_MCFG_OHCCLKEN (1<<16)
+#define USB_MCFG_UCAM (1<<7)
+#define USB_MCFG_OBMEN (1<<1)
+#define USB_MCFG_OMEMEN (1<<0)
Maybe, the place where to put those defines is
include/asm-mips/mach-au1x00/au1000.h? Because there are some similar defines in
that file, actually shift values. For consistency, are they used?..
+#define USBH_ENABLE_CE USB_MCFG_OHCCLKEN
+#ifdef CONFIG_DMA_COHERENT
+#define USBH_ENABLE_INIT (USB_MCFG_OHCCLKEN \
+ | USB_MCFG_PFEN | USB_MCFG_RDCOMB \
+ | USB_MCFG_SSDEN | USB_MCFG_UCAM \
Aha! What I was lacking in my patch was USB_MCFG_UCAM! For test, I added it to
my patch, and it worked! Reserved in the doc. So do USB_MCFG_PFEN and
USB_MCFG_RDCOMB. What's the meaning of that fields?
+#else /* Au1200 */
+
+ /* write HW defaults again in case Yamon cleared them */
+ if (au_readl(USB_HOST_CONFIG) == 0) {
+ au_writel(0x00d02000, USB_HOST_CONFIG);
+ au_readl(USB_HOST_CONFIG);
+ udelay(1000);
+ }
+ au_writel(USBH_ENABLE_CE | au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG);
+ au_readl(USB_HOST_CONFIG);
+ udelay(1000);
+ au_writel(USBH_ENABLE_INIT | au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG);
+ au_readl(USB_HOST_CONFIG);
+ udelay(1000);
Are au_readl() and udelay() necessary between the two au_writel()? Just for
curiosity, I tried it without them and as it seems, it worked!
--
Bora SAHIN
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
2005-12-08 21:00 ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Jordan Crouse
2005-12-10 5:13 ` [linux-usb-devel] " David Brownell
2005-12-12 10:51 ` Bora Sahin
@ 2006-01-03 14:25 ` Matej Kupljen
2006-01-03 15:54 ` Jordan Crouse
2 siblings, 1 reply; 37+ messages in thread
From: Matej Kupljen @ 2006-01-03 14:25 UTC (permalink / raw)
To: Jordan Crouse; +Cc: linux-mips, linux-usb-devel, matthias.lenk
Hi
> Ok, here we go. I give you the OHCI/EHCI host controller support for
> the Alchemy AU1200 processor. I'm sending this up, partly because I have
> it ready to go, but also because it seems that enough folks are getting their
> hands on AU1200 parts to make this a hot topic.
I tried you patch, and this is what I get on 2.6.16-rc5:
[4294668.576000] Creating 3 MTD partitions on "Db1200 Flash":
[4294668.581000] 0x00000000-0x03c00000 : "User FS"
[4294668.587000] 0x03c00000-0x03d00000 : "YAMON"
[4294668.593000] 0x03d00000-0x03fc0000 : "raw kernel"
[4294668.602000] CPU 0 Unable to handle kernel paging request at virtual
address 00000008, epc == 80350764, ra == 80350760
[4294668.613000] Oops[#1]:
[4294668.613000] Cpu 0
[4294668.613000] $ 0 : 00000000 1000fc00 8054a000 00000000
[4294668.613000] $ 4 : 8054b000 00000000 00000000 8107d530
[4294668.613000] $ 8 : 00000000 802a4030 8107d520 8053d57c
[4294668.613000] $12 : ffffffff ffffffff 00100100 00200200
[4294668.613000] $16 : 8053c0d0 8053c000 00001000 80460000
[4294668.613000] $20 : 8041dcb0 00000000 00000000 00000000
[4294668.613000] $24 : 00000008 00000000
[4294668.613000] $28 : 804f2000 804f3e58 00000000 80350760
[4294668.613000] Hi : 00000000
[4294668.613000] Lo : 00000000
[4294668.613000] epc : 80350764 ehci_init+0x190/0x2c0 Not tainted
[4294668.613000] ra : 80350760 ehci_init+0x18c/0x2c0
[4294668.613000] Status: 1000fc03 KERNEL EXL IE
[4294668.613000] Cause : 00800008
[4294668.613000] BadVA : 00000008
[4294668.613000] PrId : 04030201
[4294668.613000] Modules linked in:
[4294668.613000] Process swapper (pid: 1, threadinfo=804f2000,
task=804eec00)
[4294668.613000] Stack : 8013044c 8033e100 804f2000 804f3e88 00001000
80352018 1000fc03 000301ff
[4294668.613000] 8053c000 fffffff4 8045e138 803520bc 804f3e78
804689e0 804f3ef8 811bb5c0
[4294668.613000] 00000010 00000000 8045e138 8045e140 80471cfc
8045e204 00000000 803521e0
[4294668.613000] 804f3e88 810756a0 00000000 00000000 00000000
00000000 00000000 802e3cd0
[4294668.613000] 8045e18c 804f3f30 8045e18c 8040d780 8045e140
804c0000 80471cfc 802e40a0
[4294668.613000] ...
[4294668.613000] Call Trace:
[4294668.613000] [<8013044c>] __request_region+0x38/0xb4
[4294668.613000] [<8033e100>] usb_create_hcd+0x4c/0xc8
[4294668.613000] [<80352018>] usb_ehci_au1xxx_probe+0xc0/0x1f8
[4294668.613000] [<803520bc>] usb_ehci_au1xxx_probe+0x164/0x1f8
[4294668.613000] [<803521e0>] ehci_hcd_au1xxx_drv_probe+0x38/0x50
[4294668.613000] [<802e3cd0>] driver_probe_device+0x4c/0xe8
[4294668.613000] [<8040d780>] klist_next+0x40/0x70
[4294668.613000] [<802e40a0>] __driver_attach+0x178/0x1a0
[4294668.613000] [<802e3f28>] __driver_attach+0x0/0x1a0
[4294668.613000] [<802e3024>] next_device+0x10/0x28
[4294668.613000] [<802e3f28>] __driver_attach+0x0/0x1a0
[4294668.613000] [<802e3090>] bus_for_each_dev+0x54/0x90
[4294668.613000] [<8029e468>] kobject_register+0x4c/0x8c
[4294668.613000] [<802e374c>] bus_add_driver+0xa8/0x18c
[4294668.613000] [<8027bb80>] debugfs_create_dir+0x1c/0x28
[4294668.613000] [<802e47a4>] driver_register+0x40/0x50
[4294668.613000] [<80100510>] init+0xac/0x2dc
[4294668.613000] [<80105ee0>] kernel_thread_helper+0x10/0x18
[4294668.613000] [<80105ed0>] kernel_thread_helper+0x0/0x18
[4294668.613000]
[4294668.613000]
[4294668.613000] Code: 0c0a8fd0 00063080 8e030000 <8c660008> 7000003f
10400046 00061102 24020008 ae020028
[4294668.866000] Kernel panic - not syncing: Attempted to kill init!
Any ideas?
BR,
Matej
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
2006-01-03 14:25 ` Matej Kupljen
@ 2006-01-03 15:54 ` Jordan Crouse
2006-01-03 21:45 ` Matej Kupljen
2006-01-04 12:12 ` ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Matej Kupljen
0 siblings, 2 replies; 37+ messages in thread
From: Jordan Crouse @ 2006-01-03 15:54 UTC (permalink / raw)
To: Matej Kupljen; +Cc: linux-mips, linux-usb-devel, matthias.lenk
> I tried you patch, and this is what I get on 2.6.16-rc5:
Well, thats a fun one. I'm assuming you tried to boot with a device
plugged in. I'm a bit confused by the __reqest_region coming from
usb_create_hcd - I quickly glanced at the function, and I don't see anything
that would have called request_region / request_mem_region. However,
there *is* a request_mem_region call immediately after the usb_create_hcd
call in usb_ehci_au1xxx_probe, and I wonder that might be the guilty party.
Matthias, any thoughts?
Jordan
--
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
2006-01-03 15:54 ` Jordan Crouse
@ 2006-01-03 21:45 ` Matej Kupljen
2006-01-04 7:18 ` Matej Kupljen
2006-01-04 12:50 ` Sathesh Babu Edara
2006-01-04 12:12 ` ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Matej Kupljen
1 sibling, 2 replies; 37+ messages in thread
From: Matej Kupljen @ 2006-01-03 21:45 UTC (permalink / raw)
To: Jordan Crouse; +Cc: linux-mips, linux-usb-devel, matthias.lenk
Hi
> > I tried you patch, and this is what I get on 2.6.16-rc5:
I meant, 2.5.15-rc5 of course, and NOT 2.6.15-rc5. Sorry.
> Well, thats a fun one. I'm assuming you tried to boot with a device
> plugged in. I'm a bit confused by the __reqest_region coming from
> usb_create_hcd - I quickly glanced at the function, and I don't see anything
> that would have called request_region / request_mem_region. However,
> there *is* a request_mem_region call immediately after the usb_create_hcd
> call in usb_ehci_au1xxx_probe, and I wonder that might be the guilty party.
I set up my BDI and tried to debug this. This is what I can tell you,
and maybe you can then be able to help me:
I get past the request_mem_region and ioremap in ehci-au1xxx.c.
I get to line 144:
if ((retval = driver->reset (hcd)) < 0) {
now, driver->reset points to the
(gdb) p driver->reset
$6 = (int (*)(struct usb_hcd *)) 0x803505d4 <ehci_init>
I step into the call and I get to ehci_init in
drivers/usb/host/ehci-hcd.c.
If I continue, i get to the ehci_mem_init in the
drivers/usb/host/ehci-mem.c
On line:
228 memset (ehci->pshadow, 0, ehci->periodic_size * sizeof (void *));
If I do next in gdb, I end up in include/asm-mips/io.h, line
425 BUILDIO_MEM(l, u32)
(Well, I am lost here now)
Now if I disassemble at $pc:
(gdb) x/20i $pc
0x80350760 <ehci_init+396>: lw v1,0(s0)
0x80350764 <ehci_init+400>: lw a2,8(v1)
0x80350768 <ehci_init+404>: andi v0,a2,0x80
0x8035076c <ehci_init+408>: beqz v0,0x80350888 <ehci_init+692>
0x80350770 <ehci_init+412>: srl v0,a2,0x4
0x80350774 <ehci_init+416>: li v0,8
0x80350778 <ehci_init+420>: sw v0,40(s0)
0x8035077c <ehci_init+424>: lw v0,24(s0)
0x80350780 <ehci_init+428>: lw a1,16(s0)
0x80350784 <ehci_init+432>: li v1,-2
0x80350788 <ehci_init+436>: and v0,v0,v1
0x8035078c <ehci_init+440>: li v1,-1
0x80350790 <ehci_init+444>: sw v1,48(s0)
0x80350794 <ehci_init+448>: sw v0,24(s0)
0x80350798 <ehci_init+452>: sw zero,20(s0)
0x8035079c <ehci_init+456>: sw zero,72(a1)
0x803507a0 <ehci_init+460>: lw a0,16(s0)
0x803507a4 <ehci_init+464>: li v1,-32
0x803507a8 <ehci_init+468>: li a1,1
0x803507ac <ehci_init+472>: lw v0,68(a0)
(gdb) p $s0
$9 = 0x8053c0d0
(gdb) x/x $s0
0x8053c0d0: 0x00000000
So I guess, that the instruction at 0x80350764 is loading from location
0 and offset 8, which can be seen also in the original post:
[4294668.602000] CPU 0 Unable to handle kernel paging request at virtual
address 00000008, epc == 80350764, ra == 80350760
What is going on here?
Is this some stack corruption, because of all this strange jumps
over the source code (I know optimisation is turned on, but still).
I hope this can help someone, I still have a lot of learning
to do to figure this out.
BR,
Matej
--
Matej Kupljen <matej.kupljen@ultra.si>
Ultra d.o.o.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
2006-01-03 21:45 ` Matej Kupljen
@ 2006-01-04 7:18 ` Matej Kupljen
2006-01-04 12:50 ` Sathesh Babu Edara
1 sibling, 0 replies; 37+ messages in thread
From: Matej Kupljen @ 2006-01-04 7:18 UTC (permalink / raw)
To: Jordan Crouse; +Cc: linux-mips, linux-usb-devel, matthias.lenk
Hi
> > > I tried you patch, and this is what I get on 2.6.16-rc5:
>
> I meant, 2.5.15-rc5 of course, and NOT 2.6.15-rc5. Sorry.
Wov, I did it again :(
Now I said 2.5.15-rc5 :( :(
The version I am testing this on is:
2.6.15-rc5.
Sorry for all this.
BR,
Matej
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
2006-01-03 15:54 ` Jordan Crouse
2006-01-03 21:45 ` Matej Kupljen
@ 2006-01-04 12:12 ` Matej Kupljen
2006-01-04 12:32 ` Matthias Lenk
1 sibling, 1 reply; 37+ messages in thread
From: Matej Kupljen @ 2006-01-04 12:12 UTC (permalink / raw)
To: Jordan Crouse; +Cc: linux-mips, linux-usb-devel, matthias.lenk
Hi
(After some confusion about kernel version, I think I found the
problem, sorry about that).
I used binutils 2.15 and 2.16.1, but did not work.
The code in the ehci-hcd.c looks like this:
----------------------------------------------------------------------------
ehci->periodic_size = DEFAULT_I_TDPS;
if ((retval = ehci_mem_init(ehci, GFP_KERNEL)) < 0)
return retval;
/* controllers may cache some of the periodic schedule ... */
hcc_params = readl(&ehci->caps->hcc_params);
if (HCC_ISOC_CACHE(hcc_params)) // full frame cache
ehci->i_thresh = 8;
else // N microframes cached
ehci->i_thresh = 2 + HCC_ISOC_THRES(hcc_params);
----------------------------------------------------------------------------
The problem is *AFTER* the call to ehci_mem_init, where a read from
ehci->caps->hcc_params is attempted, but caps is NULL.
This can be seen by this assembly code form Insight:
----------------------------------------------------------------------------
0x80350758 jal 0x802a3f40 <memset>
0x8035075c sll a2,a2,0x2
0x80350760 lw v1,0(s0)
0x80350764 lw a2,8(v1)
s0 points to ehci
at offset 0 from ehci is caps
and at offset 8 from caps is hcc_params
----------------------------------------------------------------------------
Where should the caps be initialized?
The only place, where it is set in drivers/usb/ is in
drivers/usb/host/ehci-pci.c:
----------------------------------------------------------------------------
/* called during probe() after chip reset completes */
static int ehci_pci_setup(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
struct pci_dev *pdev =
to_pci_dev(hcd->self.controller);
u32 temp;
int retval;
ehci->caps = hcd->regs;
----------------------------------------------------------------------------
But the ehci-pci.c is not included in the compilation, because at the
end of ehci-hcd.c we find:
----------------------------------------------------------------------------
#if defined(CONFIG_SOC_AU1X00)
#include "ehci-au1xxx.c"
#elif defined(CONFIG_PCI)
#include "ehci-pci.c"
#else
#error "missing bus glue for ehci-hcd"
#endif
----------------------------------------------------------------------------
What should be done?
I hope this helps.
BR,
Matej
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
2006-01-04 12:12 ` ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Matej Kupljen
@ 2006-01-04 12:32 ` Matthias Lenk
2006-01-04 13:07 ` Matej Kupljen
0 siblings, 1 reply; 37+ messages in thread
From: Matthias Lenk @ 2006-01-04 12:32 UTC (permalink / raw)
To: Matej Kupljen; +Cc: Jordan Crouse, linux-mips, linux-usb-devel
Hi Matej ,
I looked into the issue and came to the same conclusions as you. Something
significant has changed from 2.6.15rc2 (what the patch was made for) to
2.6.15rc5. I added the initialization of the caps and regs fields of the ehci
structure to the probe function in ehci-au1xxx.c. The driver doesn't crash
anymore but does not work either.
I also tried the Au1xxx OHCI and it hangs while loading the module with rc7.
So it'll probably take some time to port the Au1200 EHCI and OHCI drivers to
2.6.15rc7 (again!).
Any hints on what has changed are appreciated.
Thanks,
Matthias
On Wednesday 04 January 2006 13:12, Matej Kupljen wrote:
> Hi
>
> (After some confusion about kernel version, I think I found the
> problem, sorry about that).
>
> I used binutils 2.15 and 2.16.1, but did not work.
>
> The code in the ehci-hcd.c looks like this:
> ---------------------------------------------------------------------------
>- ehci->periodic_size = DEFAULT_I_TDPS;
> if ((retval = ehci_mem_init(ehci, GFP_KERNEL)) < 0)
> return retval;
>
> /* controllers may cache some of the periodic schedule ... */
> hcc_params = readl(&ehci->caps->hcc_params);
> if (HCC_ISOC_CACHE(hcc_params)) // full frame cache
> ehci->i_thresh = 8;
> else // N microframes cached
> ehci->i_thresh = 2 + HCC_ISOC_THRES(hcc_params);
> ---------------------------------------------------------------------------
>-
>
> The problem is *AFTER* the call to ehci_mem_init, where a read from
> ehci->caps->hcc_params is attempted, but caps is NULL.
>
> This can be seen by this assembly code form Insight:
> ---------------------------------------------------------------------------
>- 0x80350758 jal 0x802a3f40 <memset>
> 0x8035075c sll a2,a2,0x2
> 0x80350760 lw v1,0(s0)
> 0x80350764 lw a2,8(v1)
>
> s0 points to ehci
> at offset 0 from ehci is caps
> and at offset 8 from caps is hcc_params
> ---------------------------------------------------------------------------
>-
>
> Where should the caps be initialized?
> The only place, where it is set in drivers/usb/ is in
> drivers/usb/host/ehci-pci.c:
> ---------------------------------------------------------------------------
>- /* called during probe() after chip reset completes */
> static int ehci_pci_setup(struct usb_hcd *hcd)
> {
> struct ehci_hcd *ehci = hcd_to_ehci(hcd);
> struct pci_dev *pdev =
> to_pci_dev(hcd->self.controller);
> u32 temp;
> int retval;
>
> ehci->caps = hcd->regs;
> ---------------------------------------------------------------------------
>- But the ehci-pci.c is not included in the compilation, because at the end
> of ehci-hcd.c we find:
> ---------------------------------------------------------------------------
>- #if defined(CONFIG_SOC_AU1X00)
> #include "ehci-au1xxx.c"
> #elif defined(CONFIG_PCI)
> #include "ehci-pci.c"
> #else
> #error "missing bus glue for ehci-hcd"
> #endif
> ---------------------------------------------------------------------------
>-
>
> What should be done?
> I hope this helps.
>
> BR,
> Matej
^ permalink raw reply [flat|nested] 37+ messages in thread
* (no subject)
@ 2006-01-04 12:50 ` Sathesh Babu Edara
0 siblings, 0 replies; 37+ messages in thread
From: Sathesh Babu Edara @ 2006-01-04 12:50 UTC (permalink / raw)
To: linux-mips-bounce, linux-mips
Hi,
We have ported linux-2.6.12 kernel onto MIPS processor (LX4189) and the
processor speed is 200Mhz.
By default Linux-2.6.12 kernel comes with HZ value 1000.Will this HZ value
cause an overhead on the 200MHZ CPU.Can someone advise me on whether going
back to HZ vaule of 100 like Linux-2.4 will reduce the overhead on this
CPU.What are the side effects this change can cause?.
Regards,
Sathesh
^ permalink raw reply [flat|nested] 37+ messages in thread
* (no subject)
@ 2006-01-04 12:50 ` Sathesh Babu Edara
0 siblings, 0 replies; 37+ messages in thread
From: Sathesh Babu Edara @ 2006-01-04 12:50 UTC (permalink / raw)
To: linux-mips-bounce, linux-mips
Hi,
We have ported linux-2.6.12 kernel onto MIPS processor (LX4189) and the
processor speed is 200Mhz.
By default Linux-2.6.12 kernel comes with HZ value 1000.Will this HZ value
cause an overhead on the 200MHZ CPU.Can someone advise me on whether going
back to HZ vaule of 100 like Linux-2.4 will reduce the overhead on this
CPU.What are the side effects this change can cause?.
Regards,
Sathesh
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re:
2006-01-04 12:50 ` Sathesh Babu Edara
(?)
@ 2006-01-04 13:06 ` Kevin D. Kissell
2006-01-09 4:54 ` Sathesh Babu Edara
2006-01-09 7:43 ` RE: Sathesh Babu Edara
-1 siblings, 2 replies; 37+ messages in thread
From: Kevin D. Kissell @ 2006-01-04 13:06 UTC (permalink / raw)
To: Sathesh Babu Edara; +Cc: linux-mips-bounce, linux-mips
Sathesh Babu Edara wrote:
>
>
> Hi,
> We have ported linux-2.6.12 kernel onto MIPS processor (LX4189) and the
> processor speed is 200Mhz.
> By default Linux-2.6.12 kernel comes with HZ value 1000.Will this HZ value
> cause an overhead on the 200MHZ CPU.Can someone advise me on whether going
> back to HZ vaule of 100 like Linux-2.4 will reduce the overhead on this
> CPU.What are the side effects this change can cause?.
The 1000Hz clock should not actually cause any problems with a 200MHz
CPU, but it will suck up an annoyingly high percentage of available
cycles. Backing off to 100Hz may cause some degradation of some
real-time/interactive response times, but the improved overall
performance will probably more than make up for it. I never build
with a HZ value greater than 100 these days, but then again, I'm
mostly running on FPGAs and other hardware emulators where the CPU
clock frequencies may be less than 1MHz, and are never more than 33MHz.
Note that a HZ value of less than 100 may cause some kernel macros
to generate divide-by-zero operations/exceptions.
Regards,
Kevin K.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
2006-01-04 12:32 ` Matthias Lenk
@ 2006-01-04 13:07 ` Matej Kupljen
2006-01-04 13:54 ` bora.sahin
0 siblings, 1 reply; 37+ messages in thread
From: Matej Kupljen @ 2006-01-04 13:07 UTC (permalink / raw)
To: matthias.lenk; +Cc: Jordan Crouse, linux-mips, linux-usb-devel
Hi
> I looked into the issue and came to the same conclusions as you. Something
> significant has changed from 2.6.15rc2 (what the patch was made for) to
> 2.6.15rc5. I added the initialization of the caps and regs fields of the ehci
> structure to the probe function in ehci-au1xxx.c. The driver doesn't crash
> anymore but does not work either.
Where did you put it?
I don't know much about USB, but by looking into the ehci-pci.c I added
this to the ehci-au1xxx.c, after ioremap of hcd->regs:
ehci = hcd_to_ehci(hcd);
ehci->caps = hcd->regs;
ehci->regs = hcd->regs + HC_LENGTH(readl(&ehci->caps->hc_capbase));
Is this O.K.?
Now, with this I get:
[4294668.620000] au1xxx-ehci au1xxx-ehci.0: Au1xxx EHCI
[4294668.626000] au1xxx-ehci au1xxx-ehci.0: new USB bus registered,
assigned bus number 1
[4294668.634000] au1xxx-ehci au1xxx-ehci.0: irq 29, io mem 0x14020200
[4294668.640000] au1xxx-ehci au1xxx-ehci.0: USB 0.0 started, EHCI 1.00,
driver 10 Dec 2004
[4294668.649000] hub 1-0:1.0: USB hub found
[4294668.653000] hub 1-0:1.0: 0 ports detected
[4294668.762000] au1xxx-ohci au1xxx-ohci.0: Au1xxx OHCI
[4294668.767000] au1xxx-ohci au1xxx-ohci.0: new USB bus registered,
assigned bus number 2
[4294668.775000] au1xxx-ohci au1xxx-ohci.0: irq 29, io mem 0x14020100
[4294678.361000] BUG: soft lockup detected on CPU#0!
[4294678.361000] Cpu 0
[4294678.361000] $ 0 : 00000000 1000fc01 807c856c 807c856c
[4294678.361000] $ 4 : 807c8570 80721710 00000000 b4020100
[4294678.361000] $ 8 : 80000000 802a4030 00000000 8045a000
[4294678.361000] $12 : 80721108 fffffffb ffffffff 0000000a
[4294678.361000] $16 : 807214d0 80721400 80721400 80470000
[4294678.361000] $20 : 00000002 804c0000 24000000 0000001d
[4294678.361000] $24 : 00000018 81281d51
[4294678.361000] $28 : 81280000 81281e28 00000000 80355484
[4294678.361000] Hi : 000301ff
[4294678.361000] Lo : fc85b000
[4294678.361000] epc : 80139c78 notifier_chain_register+0x18/0x54
Not tainted
[4294678.361000] ra : 80355484 ohci_au1xxx_start+0x644/0x678
[4294678.361000] Status: 1000fc03 KERNEL EXL IE
[4294678.361000] Cause : 00808000
[4294678.361000] PrId : 04030201
Well, a little further :(
> I also tried the Au1xxx OHCI and it hangs while loading the module with rc7.
> So it'll probably take some time to port the Au1200 EHCI and OHCI drivers to
> 2.6.15rc7 (again!).
I think Bora Sahin said he used OHCI successfully on 2.5.15-rc4.
Bora, can you confirm this?
> Any hints on what has changed are appreciated.
I disabled EHCI in .config and tried again. This is what I got:
[4294668.621000] au1xxx-ohci au1xxx-ohci.0: Au1xxx OHCI
[4294668.626000] au1xxx-ohci au1xxx-ohci.0: new USB bus registered,
assigned bus number 1
[4294668.635000] au1xxx-ohci au1xxx-ohci.0: irq 29, io mem 0x14020100
[4294668.725000] hub 1-0:1.0: USB hub found
[4294668.729000] hub 1-0:1.0: 2 ports detected
When I plug in USB 2.0 Flash key (with the vfat module lodaed):
/root # [4294868.810000] usb 1-1: new full speed USB device using
au1xxx-ohci and address 2
[4294877.045000] kobject_register failed for usbcore (-17)
[4294877.050000] Call Trace:
[4294877.053000] [<8029e490>] kobject_register+0x74/0x8c
[4294877.058000] [<8029e440>] kobject_register+0x24/0x8c
[4294877.063000] [<8014c070>] load_module+0xec4/0x1810
[4294877.068000] [<8014c04c>] load_module+0xea0/0x1810
[4294877.073000] [<80206ed4>] do_setlk+0x1cc/0x40c
[4294877.078000] [<801640f8>] vma_prio_tree_insert+0x28/0x5c
[4294877.084000] [<8016ae64>] __vma_link+0x34/0x80
[4294877.089000] [<801533d8>] generic_file_mmap+0x68/0x70
[4294877.094000] [<8016af40>] vma_link+0x90/0x160
[4294877.099000] [<8016aef0>] vma_link+0x40/0x160
[4294877.103000] [<8014cab4>] sys_init_module+0xd0/0x890
[4294877.108000] [<8010daac>] stack_done+0x20/0x40
[4294877.113000]
[4294878.449000] Initializing USB Mass Storage driver...
[4294878.508000] scsi0 : SCSI emulation for USB Mass Storage devices
[4294878.606000] usbcore: registered new driver usb-storage
[4294878.612000] USB Mass Storage support registered.
[4294883.623000] Vendor: Generic Model: STORAGE DEVICE Rev: 1.04
[4294883.630000] Type: Direct-Access ANSI SCSI
revision: 00
[4294883.913000] SCSI device sda: 256000 512-byte hdwr sectors (131 MB)
[4294883.928000] sda: Write Protect is on
[4294883.932000] sda: assuming drive cache: write through
[4294883.965000] SCSI device sda: 256000 512-byte hdwr sectors (131 MB)
[4294883.980000] sda: Write Protect is on
[4294883.984000] sda: assuming drive cache: write through
[4294883.989000] sda: sda1
[4294884.005000] sd 0:0:0:0: Attached scsi removable disk sda
[4294884.028000] sd 0:0:0:0: Attached scsi generic sg0 type 0
And I can mount /dev/sda1.
I'll try with only EHCI now, then I'll look into this
kobject_register.
BR,
Matej
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
2006-01-04 13:07 ` Matej Kupljen
@ 2006-01-04 13:54 ` bora.sahin
2006-01-04 14:17 ` Matej Kupljen
0 siblings, 1 reply; 37+ messages in thread
From: bora.sahin @ 2006-01-04 13:54 UTC (permalink / raw)
To: Matej Kupljen; +Cc: matthias.lenk, Jordan Crouse, linux-mips, linux-usb-devel
Hi,
> I think Bora Sahin said he used OHCI successfully on 2.5.15-rc4.
> Bora, can you confirm this?
Yes, it works both in my version of patch and Jordan's...
But my kernel version is
#define UTS_RELEASE "2.6.15-rc4-g2b269cc6"
not 2.5.15-rc4
--
Bora SAHIN
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI)
2006-01-04 13:54 ` bora.sahin
@ 2006-01-04 14:17 ` Matej Kupljen
0 siblings, 0 replies; 37+ messages in thread
From: Matej Kupljen @ 2006-01-04 14:17 UTC (permalink / raw)
To: bora.sahin; +Cc: matthias.lenk, Jordan Crouse, linux-mips, linux-usb-devel
Hi
> > I think Bora Sahin said he used OHCI successfully on 2.5.15-rc4.
> > Bora, can you confirm this?
>
> Yes, it works both in my version of patch and Jordan's...
>
> But my kernel version is
> #define UTS_RELEASE "2.6.15-rc4-g2b269cc6"
> not 2.5.15-rc4
Yes, I meant the right one: 2.6.15-rc4
(I don't know what is wrong with me and those kernel versions).
So, there was some change between rc4 and rc5, that
broke USB on Alchemey?
BR,
Matej
^ permalink raw reply [flat|nested] 37+ messages in thread
* LL and SC instruction simulation
@ 2006-01-09 4:54 ` Sathesh Babu Edara
0 siblings, 0 replies; 37+ messages in thread
From: Sathesh Babu Edara @ 2006-01-09 4:54 UTC (permalink / raw)
To: linux-mips-bounce, linux-mips
Hi,
We have ported linux-2.4.18 and linux-2-6.12 kernel (mips.org)onto MIPS
processor (CPU type lx4189).
We observed that on 2.4 kernel,ll and sc instruction exception handlers
hitting very often.
Where as on linux-2.6.12 this is not happening.
Can anybody have idea why this instructions are hitting on 2.4.18 kernel and
not on 2-6.12 kernel.
What is the significance of these instructions?.
Note :
For linux-2.4.18 : We use GCC version -3.3.4 binutils version -2.15 and
uClibc version -0.9.26
For linux-2.6.12 : We use GCC version -3.4.3 binutils version -2.15 and
uClibc version -0.9.28.
Thanks in advance.
Regards,
Sathesh
^ permalink raw reply [flat|nested] 37+ messages in thread
* LL and SC instruction simulation
@ 2006-01-09 4:54 ` Sathesh Babu Edara
0 siblings, 0 replies; 37+ messages in thread
From: Sathesh Babu Edara @ 2006-01-09 4:54 UTC (permalink / raw)
To: linux-mips-bounce, linux-mips
Hi,
We have ported linux-2.4.18 and linux-2-6.12 kernel (mips.org)onto MIPS
processor (CPU type lx4189).
We observed that on 2.4 kernel,ll and sc instruction exception handlers
hitting very often.
Where as on linux-2.6.12 this is not happening.
Can anybody have idea why this instructions are hitting on 2.4.18 kernel and
not on 2-6.12 kernel.
What is the significance of these instructions?.
Note :
For linux-2.4.18 : We use GCC version -3.3.4 binutils version -2.15 and
uClibc version -0.9.26
For linux-2.6.12 : We use GCC version -3.4.3 binutils version -2.15 and
uClibc version -0.9.28.
Thanks in advance.
Regards,
Sathesh
^ permalink raw reply [flat|nested] 37+ messages in thread
* LL and SC instruction simulation
@ 2006-01-09 5:19 ` Sathesh Babu Edara
0 siblings, 0 replies; 37+ messages in thread
From: Sathesh Babu Edara @ 2006-01-09 5:19 UTC (permalink / raw)
To: linux-mips-bounce, linux-mips
Hi,
We have ported linux-2.4.18 and linux-2-6.12 kernel (mips.org)onto MIPS
processor (CPU type lx4189).
We observed that on 2.4 kernel,ll and sc instruction exception handlers
hitting very often.
Where as on linux-2.6.12 this is not happening.
Can anybody have idea why this instructions are hitting on 2.4.18 kernel and
not on 2-6.12 kernel.
What is the significance of these instructions?.
Note :
For linux-2.4.18 : We use GCC version -3.3.4 binutils version -2.15 and
uClibc version -0.9.26 For linux-2.6.12 : We use GCC version -3.4.3 binutils
version -2.15 and uClibc version -0.9.28.
Thanks in advance.
Regards,
Sathesh
^ permalink raw reply [flat|nested] 37+ messages in thread
* LL and SC instruction simulation
@ 2006-01-09 5:19 ` Sathesh Babu Edara
0 siblings, 0 replies; 37+ messages in thread
From: Sathesh Babu Edara @ 2006-01-09 5:19 UTC (permalink / raw)
To: linux-mips-bounce, linux-mips
Hi,
We have ported linux-2.4.18 and linux-2-6.12 kernel (mips.org)onto MIPS
processor (CPU type lx4189).
We observed that on 2.4 kernel,ll and sc instruction exception handlers
hitting very often.
Where as on linux-2.6.12 this is not happening.
Can anybody have idea why this instructions are hitting on 2.4.18 kernel and
not on 2-6.12 kernel.
What is the significance of these instructions?.
Note :
For linux-2.4.18 : We use GCC version -3.3.4 binutils version -2.15 and
uClibc version -0.9.26 For linux-2.6.12 : We use GCC version -3.4.3 binutils
version -2.15 and uClibc version -0.9.28.
Thanks in advance.
Regards,
Sathesh
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE:
@ 2006-01-09 7:43 ` Sathesh Babu Edara
0 siblings, 0 replies; 37+ messages in thread
From: Sathesh Babu Edara @ 2006-01-09 7:43 UTC (permalink / raw)
To: 'Kevin D. Kissell', linux-mips-bounce, linux-mips
Hi,
Appreciate your response .
What is the ideal HZ value if the processor speed is 200Mhz?.
Regards,
Sathesh
-----Original Message-----
From: Kevin D. Kissell [mailto:kevink@mips.com]
Sent: Wednesday, January 04, 2006 6:37 PM
To: Sathesh Babu Edara
Cc: linux-mips-bounce@linux-mips.org; linux-mips@linux-mips.org
Subject: Re:
Sathesh Babu Edara wrote:
>
>
> Hi,
> We have ported linux-2.6.12 kernel onto MIPS processor (LX4189) and
> the processor speed is 200Mhz.
> By default Linux-2.6.12 kernel comes with HZ value 1000.Will this HZ
> value cause an overhead on the 200MHZ CPU.Can someone advise me on
> whether going back to HZ vaule of 100 like Linux-2.4 will reduce the
> overhead on this CPU.What are the side effects this change can cause?.
The 1000Hz clock should not actually cause any problems with a 200MHz CPU,
but it will suck up an annoyingly high percentage of available cycles.
Backing off to 100Hz may cause some degradation of some
real-time/interactive response times, but the improved overall performance
will probably more than make up for it. I never build with a HZ value
greater than 100 these days, but then again, I'm mostly running on FPGAs and
other hardware emulators where the CPU clock frequencies may be less than
1MHz, and are never more than 33MHz.
Note that a HZ value of less than 100 may cause some kernel macros to
generate divide-by-zero operations/exceptions.
Regards,
Kevin K.
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE:
@ 2006-01-09 7:43 ` Sathesh Babu Edara
0 siblings, 0 replies; 37+ messages in thread
From: Sathesh Babu Edara @ 2006-01-09 7:43 UTC (permalink / raw)
To: 'Kevin D. Kissell', linux-mips-bounce, linux-mips
Hi,
Appreciate your response .
What is the ideal HZ value if the processor speed is 200Mhz?.
Regards,
Sathesh
-----Original Message-----
From: Kevin D. Kissell [mailto:kevink@mips.com]
Sent: Wednesday, January 04, 2006 6:37 PM
To: Sathesh Babu Edara
Cc: linux-mips-bounce@linux-mips.org; linux-mips@linux-mips.org
Subject: Re:
Sathesh Babu Edara wrote:
>
>
> Hi,
> We have ported linux-2.6.12 kernel onto MIPS processor (LX4189) and
> the processor speed is 200Mhz.
> By default Linux-2.6.12 kernel comes with HZ value 1000.Will this HZ
> value cause an overhead on the 200MHZ CPU.Can someone advise me on
> whether going back to HZ vaule of 100 like Linux-2.4 will reduce the
> overhead on this CPU.What are the side effects this change can cause?.
The 1000Hz clock should not actually cause any problems with a 200MHz CPU,
but it will suck up an annoyingly high percentage of available cycles.
Backing off to 100Hz may cause some degradation of some
real-time/interactive response times, but the improved overall performance
will probably more than make up for it. I never build with a HZ value
greater than 100 these days, but then again, I'm mostly running on FPGAs and
other hardware emulators where the CPU clock frequencies may be less than
1MHz, and are never more than 33MHz.
Note that a HZ value of less than 100 may cause some kernel macros to
generate divide-by-zero operations/exceptions.
Regards,
Kevin K.
^ permalink raw reply [flat|nested] 37+ messages in thread
* LL and SC instruction simulation
@ 2006-01-09 7:49 ` Sathesh Babu Edara
0 siblings, 0 replies; 37+ messages in thread
From: Sathesh Babu Edara @ 2006-01-09 7:49 UTC (permalink / raw)
To: linux-mips-bounce, linux-mips
Hi,
We have ported linux-2.4.18 and linux-2-6.12 kernel (mips.org)onto MIPS
processor (CPU type lx4189).
We observed that on 2.4 kernel,ll and sc instruction exception handlers
hitting very often.
Where as on linux-2.6.12 this is not happening.
Can anybody have idea why this instructions are hitting on 2.4.18 kernel and
not on 2-6.12 kernel.
What is the significance of these instructions?.
Note :
For linux-2.4.18 : We use GCC version -3.3.4 binutils version -2.15 and
uClibc version -0.9.26 For linux-2.6.12 : We use GCC version -3.4.3 binutils
version -2.15 and uClibc version -0.9.28.
Thanks in advance.
Regards,
Sathesh
^ permalink raw reply [flat|nested] 37+ messages in thread
* LL and SC instruction simulation
@ 2006-01-09 7:49 ` Sathesh Babu Edara
0 siblings, 0 replies; 37+ messages in thread
From: Sathesh Babu Edara @ 2006-01-09 7:49 UTC (permalink / raw)
To: linux-mips-bounce, linux-mips
Hi,
We have ported linux-2.4.18 and linux-2-6.12 kernel (mips.org)onto MIPS
processor (CPU type lx4189).
We observed that on 2.4 kernel,ll and sc instruction exception handlers
hitting very often.
Where as on linux-2.6.12 this is not happening.
Can anybody have idea why this instructions are hitting on 2.4.18 kernel and
not on 2-6.12 kernel.
What is the significance of these instructions?.
Note :
For linux-2.4.18 : We use GCC version -3.3.4 binutils version -2.15 and
uClibc version -0.9.26 For linux-2.6.12 : We use GCC version -3.4.3 binutils
version -2.15 and uClibc version -0.9.28.
Thanks in advance.
Regards,
Sathesh
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re:
@ 2006-01-09 9:00 ` Kevin D. Kissell
0 siblings, 0 replies; 37+ messages in thread
From: Kevin D. Kissell @ 2006-01-09 9:00 UTC (permalink / raw)
To: Sathesh Babu Edara, linux-mips-bounce, linux-mips
There is no "ideal" value for a given processor frequency.
The lower the value, the less interrupt processing overhead,
but the slower the response time to events that are detected
or serviced during clock interrupts. 1000 HZ *may* be a sensible
value (I have my doubts, personally) for 2+ GHz PC processors,
but it's excessive (IMHO) for a 200MHz processor and unworkable
for a 20MHz CPU. I think that 100HZ is still a reasonable value
for an embedded RISC CPU, but the "ideal" value is going to
be a function of the application.
Regards,
Kevin K.
----- Original Message -----
From: "Sathesh Babu Edara" <satheshbabu.edara@analog.com>
To: "'Kevin D. Kissell'" <kevink@mips.com>; <linux-mips-bounce@linux-mips.org>; <linux-mips@linux-mips.org>
Sent: Monday, January 09, 2006 8:43 AM
Subject: RE:
>
> Hi,
> Appreciate your response .
>
> What is the ideal HZ value if the processor speed is 200Mhz?.
>
> Regards,
> Sathesh
> -----Original Message-----
> From: Kevin D. Kissell [mailto:kevink@mips.com]
> Sent: Wednesday, January 04, 2006 6:37 PM
> To: Sathesh Babu Edara
> Cc: linux-mips-bounce@linux-mips.org; linux-mips@linux-mips.org
> Subject: Re:
>
> Sathesh Babu Edara wrote:
> >
> >
> > Hi,
> > We have ported linux-2.6.12 kernel onto MIPS processor (LX4189) and
> > the processor speed is 200Mhz.
> > By default Linux-2.6.12 kernel comes with HZ value 1000.Will this HZ
> > value cause an overhead on the 200MHZ CPU.Can someone advise me on
> > whether going back to HZ vaule of 100 like Linux-2.4 will reduce the
> > overhead on this CPU.What are the side effects this change can cause?.
>
> The 1000Hz clock should not actually cause any problems with a 200MHz CPU,
> but it will suck up an annoyingly high percentage of available cycles.
> Backing off to 100Hz may cause some degradation of some
> real-time/interactive response times, but the improved overall performance
> will probably more than make up for it. I never build with a HZ value
> greater than 100 these days, but then again, I'm mostly running on FPGAs and
> other hardware emulators where the CPU clock frequencies may be less than
> 1MHz, and are never more than 33MHz.
> Note that a HZ value of less than 100 may cause some kernel macros to
> generate divide-by-zero operations/exceptions.
>
> Regards,
>
> Kevin K.
>
>
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re:
@ 2006-01-09 9:00 ` Kevin D. Kissell
0 siblings, 0 replies; 37+ messages in thread
From: Kevin D. Kissell @ 2006-01-09 9:00 UTC (permalink / raw)
To: Sathesh Babu Edara, linux-mips-bounce, linux-mips
There is no "ideal" value for a given processor frequency.
The lower the value, the less interrupt processing overhead,
but the slower the response time to events that are detected
or serviced during clock interrupts. 1000 HZ *may* be a sensible
value (I have my doubts, personally) for 2+ GHz PC processors,
but it's excessive (IMHO) for a 200MHz processor and unworkable
for a 20MHz CPU. I think that 100HZ is still a reasonable value
for an embedded RISC CPU, but the "ideal" value is going to
be a function of the application.
Regards,
Kevin K.
----- Original Message -----
From: "Sathesh Babu Edara" <satheshbabu.edara@analog.com>
To: "'Kevin D. Kissell'" <kevink@mips.com>; <linux-mips-bounce@linux-mips.org>; <linux-mips@linux-mips.org>
Sent: Monday, January 09, 2006 8:43 AM
Subject: RE:
>
> Hi,
> Appreciate your response .
>
> What is the ideal HZ value if the processor speed is 200Mhz?.
>
> Regards,
> Sathesh
> -----Original Message-----
> From: Kevin D. Kissell [mailto:kevink@mips.com]
> Sent: Wednesday, January 04, 2006 6:37 PM
> To: Sathesh Babu Edara
> Cc: linux-mips-bounce@linux-mips.org; linux-mips@linux-mips.org
> Subject: Re:
>
> Sathesh Babu Edara wrote:
> >
> >
> > Hi,
> > We have ported linux-2.6.12 kernel onto MIPS processor (LX4189) and
> > the processor speed is 200Mhz.
> > By default Linux-2.6.12 kernel comes with HZ value 1000.Will this HZ
> > value cause an overhead on the 200MHZ CPU.Can someone advise me on
> > whether going back to HZ vaule of 100 like Linux-2.4 will reduce the
> > overhead on this CPU.What are the side effects this change can cause?.
>
> The 1000Hz clock should not actually cause any problems with a 200MHz CPU,
> but it will suck up an annoyingly high percentage of available cycles.
> Backing off to 100Hz may cause some degradation of some
> real-time/interactive response times, but the improved overall performance
> will probably more than make up for it. I never build with a HZ value
> greater than 100 these days, but then again, I'm mostly running on FPGAs and
> other hardware emulators where the CPU clock frequencies may be less than
> 1MHz, and are never more than 33MHz.
> Note that a HZ value of less than 100 may cause some kernel macros to
> generate divide-by-zero operations/exceptions.
>
> Regards,
>
> Kevin K.
>
>
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: LL and SC instruction simulation
2006-01-09 7:49 ` Sathesh Babu Edara
(?)
@ 2006-01-09 14:54 ` Ralf Baechle
2006-01-09 15:17 ` Kevin D. Kissell
-1 siblings, 1 reply; 37+ messages in thread
From: Ralf Baechle @ 2006-01-09 14:54 UTC (permalink / raw)
To: Sathesh Babu Edara; +Cc: linux-mips-bounce, linux-mips
On Mon, Jan 09, 2006 at 01:19:46PM +0530, Sathesh Babu Edara wrote:
> We have ported linux-2.4.18 and linux-2-6.12 kernel (mips.org)onto MIPS
> processor (CPU type lx4189).
>
> We observed that on 2.4 kernel,ll and sc instruction exception handlers
> hitting very often.
> Where as on linux-2.6.12 this is not happening.
> Can anybody have idea why this instructions are hitting on 2.4.18 kernel and
> not on 2-6.12 kernel.
Only ll/sc instructions in application software can be emulated, so it
would seem your application is behaving different on 2.4 and 2.6 kernels.
> What is the significance of these instructions?.
All sorts of atomic operations. I suggest you read up on them in See MIPS
Run or short of that in the MIPS32/64 specification.
Ralf
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: LL and SC instruction simulation
@ 2006-01-09 15:17 ` Kevin D. Kissell
0 siblings, 0 replies; 37+ messages in thread
From: Kevin D. Kissell @ 2006-01-09 15:17 UTC (permalink / raw)
To: Ralf Baechle, Sathesh Babu Edara; +Cc: linux-mips-bounce, linux-mips
Ralf writes:
> On Mon, Jan 09, 2006 at 01:19:46PM +0530, Sathesh Babu Edara wrote:
>
> > We have ported linux-2.4.18 and linux-2-6.12 kernel (mips.org)onto MIPS
> > processor (CPU type lx4189).
> >
> > We observed that on 2.4 kernel,ll and sc instruction exception handlers
> > hitting very often.
> > Where as on linux-2.6.12 this is not happening.
>
> > Can anybody have idea why this instructions are hitting on 2.4.18 kernel and
> > not on 2-6.12 kernel.
>
> Only ll/sc instructions in application software can be emulated, so it
> would seem your application is behaving different on 2.4 and 2.6 kernels.
Is there an interface where 2.6 might be telling library code to use system calls
instead LL/SC, where the 2.4 kernel didn't?
Regards,
Kevin K.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: LL and SC instruction simulation
@ 2006-01-09 15:17 ` Kevin D. Kissell
0 siblings, 0 replies; 37+ messages in thread
From: Kevin D. Kissell @ 2006-01-09 15:17 UTC (permalink / raw)
To: Ralf Baechle, Sathesh Babu Edara; +Cc: linux-mips-bounce, linux-mips
Ralf writes:
> On Mon, Jan 09, 2006 at 01:19:46PM +0530, Sathesh Babu Edara wrote:
>
> > We have ported linux-2.4.18 and linux-2-6.12 kernel (mips.org)onto MIPS
> > processor (CPU type lx4189).
> >
> > We observed that on 2.4 kernel,ll and sc instruction exception handlers
> > hitting very often.
> > Where as on linux-2.6.12 this is not happening.
>
> > Can anybody have idea why this instructions are hitting on 2.4.18 kernel and
> > not on 2-6.12 kernel.
>
> Only ll/sc instructions in application software can be emulated, so it
> would seem your application is behaving different on 2.4 and 2.6 kernels.
Is there an interface where 2.6 might be telling library code to use system calls
instead LL/SC, where the 2.4 kernel didn't?
Regards,
Kevin K.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: LL and SC instruction simulation
2006-01-09 15:17 ` Kevin D. Kissell
(?)
@ 2006-01-09 15:21 ` Ralf Baechle
2006-01-09 15:30 ` Ralf Baechle
-1 siblings, 1 reply; 37+ messages in thread
From: Ralf Baechle @ 2006-01-09 15:21 UTC (permalink / raw)
To: Kevin D. Kissell; +Cc: Sathesh Babu Edara, linux-mips-bounce, linux-mips
On Mon, Jan 09, 2006 at 04:17:50PM +0100, Kevin D. Kissell wrote:
> > Only ll/sc instructions in application software can be emulated, so it
> > would seem your application is behaving different on 2.4 and 2.6 kernels.
>
> Is there an interface where 2.6 might be telling library code to use system calls
> instead LL/SC, where the 2.4 kernel didn't?
No.
Ralf
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: LL and SC instruction simulation
2006-01-09 15:21 ` Ralf Baechle
@ 2006-01-09 15:30 ` Ralf Baechle
2006-01-09 15:47 ` Kevin D. Kissell
0 siblings, 1 reply; 37+ messages in thread
From: Ralf Baechle @ 2006-01-09 15:30 UTC (permalink / raw)
To: Kevin D. Kissell; +Cc: Sathesh Babu Edara, linux-mips-bounce, linux-mips
On Mon, Jan 09, 2006 at 03:21:48PM +0000, Ralf Baechle wrote:
> > > Only ll/sc instructions in application software can be emulated, so it
> > > would seem your application is behaving different on 2.4 and 2.6 kernels.
> >
> > Is there an interface where 2.6 might be telling library code to use system calls
> > instead LL/SC, where the 2.4 kernel didn't?
>
> No.
And I think it's not really worth it. MIPS II did introduce ll/sc in
1991 and it was becoming widely available with MIPS III and some pseudo-
MIPS II R3000 variants also in the embedded markets and MIPS32/MIPS64
were based on that. So ll/sc-less processors are a very small part of
the market of Linux/MIPS these days, not really worth to optimize for.
Ralf
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: LL and SC instruction simulation
@ 2006-01-09 15:47 ` Kevin D. Kissell
0 siblings, 0 replies; 37+ messages in thread
From: Kevin D. Kissell @ 2006-01-09 15:47 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Sathesh Babu Edara, linux-mips-bounce, linux-mips
> > > Is there an interface where 2.6 might be telling library code to use system calls
> > > instead LL/SC, where the 2.4 kernel didn't?
> >
> > No.
>
> And I think it's not really worth it. MIPS II did introduce ll/sc in
> 1991 and it was becoming widely available with MIPS III and some pseudo-
> MIPS II R3000 variants also in the embedded markets and MIPS32/MIPS64
> were based on that. So ll/sc-less processors are a very small part of
> the market of Linux/MIPS these days, not really worth to optimize for.
Hmm. I can think of at least one *very* high volume MIPS Linux platform still
manufactured by a very large Japanese electronics company where LL/SC
either isn't implemented or doesn't work...
Regards,
Kevin K.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: LL and SC instruction simulation
@ 2006-01-09 15:47 ` Kevin D. Kissell
0 siblings, 0 replies; 37+ messages in thread
From: Kevin D. Kissell @ 2006-01-09 15:47 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Sathesh Babu Edara, linux-mips-bounce, linux-mips
> > > Is there an interface where 2.6 might be telling library code to use system calls
> > > instead LL/SC, where the 2.4 kernel didn't?
> >
> > No.
>
> And I think it's not really worth it. MIPS II did introduce ll/sc in
> 1991 and it was becoming widely available with MIPS III and some pseudo-
> MIPS II R3000 variants also in the embedded markets and MIPS32/MIPS64
> were based on that. So ll/sc-less processors are a very small part of
> the market of Linux/MIPS these days, not really worth to optimize for.
Hmm. I can think of at least one *very* high volume MIPS Linux platform still
manufactured by a very large Japanese electronics company where LL/SC
either isn't implemented or doesn't work...
Regards,
Kevin K.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: LL and SC instruction simulation
2006-01-09 15:47 ` Kevin D. Kissell
(?)
@ 2006-01-09 15:51 ` Ralf Baechle
-1 siblings, 0 replies; 37+ messages in thread
From: Ralf Baechle @ 2006-01-09 15:51 UTC (permalink / raw)
To: Kevin D. Kissell; +Cc: Sathesh Babu Edara, linux-mips
On Mon, Jan 09, 2006 at 04:47:01PM +0100, Kevin D. Kissell wrote:
> Hmm. I can think of at least one *very* high volume MIPS Linux platform still
> manufactured by a very large Japanese electronics company where LL/SC
> either isn't implemented or doesn't work...
The user community of that platform of that four letter vendor still
hasn't managed to upgrade their kernels to something that would even be
remotely contemporary, so any 2.6 questions don't apply ...
Ralf
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [processor frequency]
2006-01-09 9:00 ` Re: Kevin D. Kissell
(?)
@ 2006-01-09 21:23 ` Wolfgang Denk
2006-01-09 21:53 ` Kevin D. Kissell
-1 siblings, 1 reply; 37+ messages in thread
From: Wolfgang Denk @ 2006-01-09 21:23 UTC (permalink / raw)
To: Kevin D. Kissell; +Cc: Sathesh Babu Edara, linux-mips
In message <005a01c614fb$2fe76b00$10eca8c0@grendel> you wrote:
> There is no "ideal" value for a given processor frequency.
> The lower the value, the less interrupt processing overhead,
> but the slower the response time to events that are detected
> or serviced during clock interrupts. 1000 HZ *may* be a sensible
> value (I have my doubts, personally) for 2+ GHz PC processors,
> but it's excessive (IMHO) for a 200MHz processor and unworkable
> for a 20MHz CPU. I think that 100HZ is still a reasonable value
> for an embedded RISC CPU, but the "ideal" value is going to
> be a function of the application.
We did some tests of the performance impact of 100 vs. 1000 Hz clock
frequency on low end systems (50 MHz PowerPC); for details please see
http://www.denx.de/wiki/view/Know/Clock100vs1000Hz
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Our missions are peaceful -- not for conquest. When we do battle, it
is only because we have no choice.
-- Kirk, "The Squire of Gothos", stardate 2124.5
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [processor frequency]
2006-01-09 21:23 ` [processor frequency] Wolfgang Denk
@ 2006-01-09 21:53 ` Kevin D. Kissell
2006-01-09 23:01 ` Wolfgang Denk
0 siblings, 1 reply; 37+ messages in thread
From: Kevin D. Kissell @ 2006-01-09 21:53 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Sathesh Babu Edara, linux-mips
Wolfgang Denk wrote:
> In message <005a01c614fb$2fe76b00$10eca8c0@grendel> you wrote:
>> There is no "ideal" value for a given processor frequency.
>> The lower the value, the less interrupt processing overhead,
>> but the slower the response time to events that are detected
>> or serviced during clock interrupts. 1000 HZ *may* be a sensible
>> value (I have my doubts, personally) for 2+ GHz PC processors,
>> but it's excessive (IMHO) for a 200MHz processor and unworkable
>> for a 20MHz CPU. I think that 100HZ is still a reasonable value
>> for an embedded RISC CPU, but the "ideal" value is going to
>> be a function of the application.
>
> We did some tests of the performance impact of 100 vs. 1000 Hz clock
> frequency on low end systems (50 MHz PowerPC); for details please see
> http://www.denx.de/wiki/view/Know/Clock100vs1000Hz
My own results, on an SMP 2.6 kernel (as opposed to the uniprocessor
2.4 kernel used for the experiments reported) have been rather different.
Certainly the degradations I observed were far worse than the 5-10% reported
in the document you cite. I'll try to repeat your experiment when I get
the time.
BTW, I'm puzzled by the "context switch" benchmark test results. By what
mechanism - or by what definition of "context switch" - can having more
frequent interrupts make context switches happen more quickly? It seems
to me that those results must be due to a systematic measurement error
being added/removed.
Regards,
Kevin K
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [processor frequency]
2006-01-09 21:53 ` Kevin D. Kissell
@ 2006-01-09 23:01 ` Wolfgang Denk
0 siblings, 0 replies; 37+ messages in thread
From: Wolfgang Denk @ 2006-01-09 23:01 UTC (permalink / raw)
To: Kevin D. Kissell; +Cc: Sathesh Babu Edara, linux-mips
In message <43C2DB61.7090704@mips.com> you wrote:
>
> BTW, I'm puzzled by the "context switch" benchmark test results. By what
> mechanism - or by what definition of "context switch" - can having more
> frequent interrupts make context switches happen more quickly? It seems
> to me that those results must be due to a systematic measurement error
> being added/removed.
I have to admit that I don't have a good explanation for this either.
It's what I got with (repeated) measurements. Cache (flush) issues
might play a role here - but without closer analysis this is just
speculation.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If you can't beat it or corrupt it, you pretend it was your idea in
the first place. - Terry Pratchett, _Guards! Guards!_
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2006-01-09 22:59 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-08 21:00 ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Jordan Crouse
2005-12-10 5:13 ` [linux-usb-devel] " David Brownell
2005-12-10 6:42 ` Pete Popov
2005-12-12 10:51 ` Bora Sahin
2006-01-03 14:25 ` Matej Kupljen
2006-01-03 15:54 ` Jordan Crouse
2006-01-03 21:45 ` Matej Kupljen
2006-01-04 7:18 ` Matej Kupljen
2006-01-04 12:50 ` Sathesh Babu Edara
2006-01-04 12:50 ` Sathesh Babu Edara
2006-01-04 13:06 ` Kevin D. Kissell
2006-01-09 4:54 ` LL and SC instruction simulation Sathesh Babu Edara
2006-01-09 4:54 ` Sathesh Babu Edara
2006-01-09 7:43 ` Sathesh Babu Edara
2006-01-09 7:43 ` RE: Sathesh Babu Edara
2006-01-09 7:49 ` LL and SC instruction simulation Sathesh Babu Edara
2006-01-09 7:49 ` Sathesh Babu Edara
2006-01-09 14:54 ` Ralf Baechle
2006-01-09 15:17 ` Kevin D. Kissell
2006-01-09 15:17 ` Kevin D. Kissell
2006-01-09 15:21 ` Ralf Baechle
2006-01-09 15:30 ` Ralf Baechle
2006-01-09 15:47 ` Kevin D. Kissell
2006-01-09 15:47 ` Kevin D. Kissell
2006-01-09 15:51 ` Ralf Baechle
2006-01-09 9:00 ` Kevin D. Kissell
2006-01-09 9:00 ` Re: Kevin D. Kissell
2006-01-09 21:23 ` [processor frequency] Wolfgang Denk
2006-01-09 21:53 ` Kevin D. Kissell
2006-01-09 23:01 ` Wolfgang Denk
2006-01-04 12:12 ` ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Matej Kupljen
2006-01-04 12:32 ` Matthias Lenk
2006-01-04 13:07 ` Matej Kupljen
2006-01-04 13:54 ` bora.sahin
2006-01-04 14:17 ` Matej Kupljen
-- strict thread matches above, loose matches on Subject: below --
2006-01-09 5:19 LL and SC instruction simulation Sathesh Babu Edara
2006-01-09 5:19 ` Sathesh Babu Edara
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.