[patch v4 3/4] USB: add Cypress c67x00 OTG controller HCD driver
This patch adds HCD support for the Cypress c67x00 family of devices.
Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
drivers/usb/Makefile |2
drivers/usb/c67x00/Makefile| 11
drivers/usb/c67x00/c67x00-drv.c| 13
drivers/usb/c67x00/c67x00-hcd.c| 409
drivers/usb/c67x00/c67x00-hcd.h| 152
drivers/usb/c67x00/c67x00-ll-hpi.c | 75 ++
drivers/usb/c67x00/c67x00-sched.c | 1193 +
drivers/usb/c67x00/c67x00.h|9
drivers/usb/host/Kconfig | 12
9 files changed, 1876 insertions(+)
Index: linux-2.6/drivers/usb/c67x00/c67x00-hcd.c
===
--- /dev/null
+++ linux-2.6/drivers/usb/c67x00/c67x00-hcd.c
@@ -0,0 +1,409 @@
+/*
+ * c67x00-hcd.c: Cypress C67X00 USB Host Controller Driver
+ *
+ * Copyright (C) 2006-2008 Barco N.V.
+ *Derived from the Cypress cy7c67200/300 ezusb linux driver and
+ *based on multiple host controller drivers inside the linux kernel.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA.
+ */
+
+#include
+#include
+#include
+
+#include "c67x00.h"
+#include "c67x00-hcd.h"
+
+/* --
+ * Root Hub Support
+ */
+
+static __u8 c67x00_hub_des[] = {
+ 0x09, /* __u8 bLength; */
+ 0x29, /* __u8 bDescriptorType; Hub-descriptor */
+ 0x02, /* __u8 bNbrPorts; */
+ 0x00, /* __u16 wHubCharacteristics; */
+ 0x00, /* (per-port OC, no power switching) */
+ 0x32, /* __u8 bPwrOn2pwrGood; 2ms */
+ 0x00, /* __u8 bHubContrCurrent; 0 mA */
+ 0x00, /* __u8 DeviceRemovable; ** 7 Ports max ** */
+ 0xff, /* __u8 PortPwrCtrlMask; ** 7 ports max ** */
+};
+
+static void c67x00_hub_reset_host_port(struct c67x00_sie *sie, int port)
+{
+ struct c67x00_hcd *c67x00 = sie->private_data;
+ unsigned long flags;
+
+ c67x00_ll_husb_reset(sie, port);
+
+ spin_lock_irqsave(&c67x00->lock, flags);
+ c67x00_ll_husb_reset_port(sie, port);
+ spin_unlock_irqrestore(&c67x00->lock, flags);
+
+ c67x00_ll_set_husb_eot(sie->dev, DEFAULT_EOT);
+}
+
+static int c67x00_hub_status_data(struct usb_hcd *hcd, char *buf)
+{
+ struct c67x00_hcd *c67x00 = hcd_to_c67x00_hcd(hcd);
+ struct c67x00_sie *sie = c67x00->sie;
+ u16 status;
+ int i;
+
+ *buf = 0;
+ status = c67x00_ll_usb_get_status(sie);
+ for (i = 0; i < C67X00_PORTS; i++)
+ if (status & PORT_CONNECT_CHANGE(i))
+ *buf |= (1 << i);
+
+ /* bit 0 denotes hub change, b1..n port change */
+ *buf <<= 1;
+
+ return !!*buf;
+}
+
+static int c67x00_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
+ u16 wIndex, char *buf, u16 wLength)
+{
+ struct c67x00_hcd *c67x00 = hcd_to_c67x00_hcd(hcd);
+ struct c67x00_sie *sie = c67x00->sie;
+ u16 status, usb_status;
+ int len = 0;
+ unsigned int port = wIndex-1;
+ u16 wPortChange, wPortStatus;
+
+ switch (typeReq) {
+
+ case GetHubStatus:
+ *(__le32 *) buf = cpu_to_le32(0);
+ len = 4;/* hub power */
+ break;
+
+ case GetPortStatus:
+ if (wIndex > C67X00_PORTS)
+ return -EPIPE;
+
+ status = c67x00_ll_usb_get_status(sie);
+ usb_status = c67x00_ll_get_usb_ctl(sie);
+
+ wPortChange = 0;
+ if (status & PORT_CONNECT_CHANGE(port))
+ wPortChange |= USB_PORT_STAT_C_CONNECTION;
+
+ wPortStatus = USB_PORT_STAT_POWER;
+ if (!(status & PORT_SE0_STATUS(port)))
+ wPortStatus |= USB_PORT_STAT_CONNECTION;
+ if (usb_status & LOW_SPEED_PORT(port)) {
+ wPortStatus |= USB_PORT_STAT_LOW_SPEED;
+ c67x00->low_speed_ports |= (1 << port);
+ } else
+ c67x00->low_speed_ports &= ~(1 << port);
[patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed USB controllers. This patch series implements a HCD driver and shows the work-in-progress status of a gadget driver. I believe patch 1..3 are ready, and I would like to see queued up for 2.6.25. Changes since v3: - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, .. - The dummy platform_device's created per serial engine are gone. - Gadget driver (WIP) Comments are very much appreciated. -- Bye, Peter Korsgaard - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch v4 1/4] USB: add Cypress c67x00 low level interface code
This patch adds the low level support code for the Cypress c67x00 family of OTG controllers. The low level code is responsible for register access and implements the software protocol for communicating with the 16bit microcontroller inside the c67x00 device. Communication is done over the HPI interface (16bit SRAM-like parallel bus). Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]> --- drivers/usb/c67x00/c67x00-ll-hpi.c | 426 + drivers/usb/c67x00/c67x00.h| 289 + 2 files changed, 715 insertions(+) Index: linux-2.6/drivers/usb/c67x00/c67x00.h === --- /dev/null +++ linux-2.6/drivers/usb/c67x00/c67x00.h @@ -0,0 +1,289 @@ +/* + * c67x00.h: Cypress C67X00 USB register and field definitions + * + * Copyright (C) 2006-2008 Barco N.V. + *Derived from the Cypress cy7c67200/300 ezusb linux driver and + *based on multiple host controller drivers inside the linux kernel. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA. + */ + +#ifndef _USB_C67X00_H +#define _USB_C67X00_H + +#include +#include +#include +#include + +/* - + * Cypress C67x00 register definitions + */ + +/* Hardware Revision Register */ +#define HW_REV_REG 0xC004 + +/* General USB registers */ +/* = */ + +/* USB Control Register */ +#define USB_CTL_REG(x) ((x) ? 0xC0AA : 0xC08A) + +#define LOW_SPEED_PORT(x) ((x) ? 0x0800 : 0x0400) +#define HOST_MODE 0x0200 +#define PORT_RES_EN(x) ((x) ? 0x0100 : 0x0080) +#define SOF_EOP_EN(x) ((x) ? 0x0002 : 0x0001) + +/* USB status register - Notice it has different content in hcd/udc mode */ +#define USB_STAT_REG(x)((x) ? 0xC0B0 : 0xC090) + +#define EP0_IRQ_FLG0x0001 +#define EP1_IRQ_FLG0x0002 +#define EP2_IRQ_FLG0x0004 +#define EP3_IRQ_FLG0x0008 +#define EP4_IRQ_FLG0x0010 +#define EP5_IRQ_FLG0x0020 +#define EP6_IRQ_FLG0x0040 +#define EP7_IRQ_FLG0x0080 +#define RESET_IRQ_FLG 0x0100 +#define SOF_EOP_IRQ_FLG0x0200 +#define ID_IRQ_FLG 0x4000 +#define VBUS_IRQ_FLG 0x8000 + +/* USB Host only registers */ +/* === */ + +/* Host n Control Register */ +#define HOST_CTL_REG(x)((x) ? 0xC0A0 : 0xC080) + +#define PREAMBLE_EN0x0080 /* Preamble enable */ +#define SEQ_SEL0x0040 /* Data Toggle Sequence Bit Select */ +#define ISO_EN 0x0010 /* Isochronous enable */ +#define ARM_EN 0x0001 /* Arm operation */ + +/* Host n Interrupt Enable Register */ +#define HOST_IRQ_EN_REG(x) ((x) ? 0xC0AC : 0xC08C) + +#define SOF_EOP_IRQ_EN 0x0200 /* SOF/EOP Interrupt Enable */ +#define SOF_EOP_TMOUT_IRQ_EN 0x0800 /* SOF/EOP Timeout Interrupt Enable */ +#define ID_IRQ_EN 0x4000 /* ID interrupt enable */ +#define VBUS_IRQ_EN0x8000 /* VBUS interrupt enable */ +#define DONE_IRQ_EN0x0001 /* Done Interrupt Enable */ + +/* USB status register */ +#define HOST_STAT_MASK 0x02FD +#define PORT_CONNECT_CHANGE(x) ((x) ? 0x0020 : 0x0010) +#define PORT_SE0_STATUS(x) ((x) ? 0x0008 : 0x0004) + +/* Host Frame Register */ +#define HOST_FRAME_REG(x) ((x) ? 0xC0B6 : 0xC096) + +#define HOST_FRAME_MASK0x07FF + +/* USB Peripheral only registers */ +/* = */ + +/* Device n Port Sel reg */ +#define DEVICE_N_PORT_SEL(x) ((x) ? 0xC0A4 : 0xC084) + +/* Device n Interrupt Enable Register */ +#define DEVICE_N_IRQ_EN_REG(x) ((x) ? 0xC0AC : 0xC08C) + +#define DEVICE_N_ENDPOINT_N_CTL_REG(dev, ep) ((dev) \ +? (0x0280 + (ep << 4)) \ +: (0x0200 + (ep << 4))) +#define DEVICE_N_ENDPOINT_N_STAT_REG(dev, ep) ((dev) \ +? (0x0286 + (ep << 4)) \ +: (0x0206 + (ep << 4))) + +#define DEVICE_N_ADDRESS(dev) ((dev) ? (0xC0
[patch v4 4/4] USB: add Cypress c67x00 OTG controller gadget driver
This patch adds USB gadget support for the Cypress c67x00 family of devices.
This is work in progress and not ready to be committed yet. I'm posting this
to show how it fits with the rest of the driver and to collect feedback.
The driver works good enought to use g_serial, but there are still issues
to be solved. The biggest issue is that endpoint 0 is currently handled by
the BIOS inside the c67x00, so the gadget stack never sees the data.
The BIOS also has other deficiencies, E.G. see the patching done in
c67x00_ll_susb_init().
---
drivers/usb/Kconfig|2
drivers/usb/Makefile |2
drivers/usb/c67x00/Kconfig | 21
drivers/usb/c67x00/Makefile|7
drivers/usb/c67x00/c67x00-drv.c| 11
drivers/usb/c67x00/c67x00-ll-hpi.c | 184 +++
drivers/usb/c67x00/c67x00-udc.c| 905 +
drivers/usb/c67x00/c67x00-udc.h| 50 ++
drivers/usb/c67x00/c67x00.h| 18
drivers/usb/gadget/Kconfig |7
drivers/usb/gadget/gadget_chips.h |8
drivers/usb/host/Kconfig | 12
12 files changed, 1212 insertions(+), 15 deletions(-)
Index: linux-2.6/drivers/usb/c67x00/c67x00-udc.c
===
--- /dev/null
+++ linux-2.6/drivers/usb/c67x00/c67x00-udc.c
@@ -0,0 +1,905 @@
+/*
+ * c67x00-udc.c: Cypress C67X00 USB device controller
+ *
+ * Copyright (C) 2006-2008 Barco N.V.
+ *Derived from the Cypress cy7c67200/300 ezusb linux driver and
+ *based on multiple device controller drivers inside the linux kernel.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "c67x00.h"
+#include "c67x00-udc.h"
+
+/* Defined in DEVICE n ENDPOINT STATUS REGISTERS */
+#define OVERFLOW_FLG 0x0800 /* Receive overflow */
+#define UNDERFLOW_FLG 0x0400 /* Receive underflow */
+#define OUT_EXCEPTION_FLG 0x0200 /* OUT received when armed for IN */
+#define IN_EXCEPTION_FLG 0x0100 /* IN received when armed for OUT */
+#define STALL_FLG 0x0080 /* Stall sent */
+#define NAK_FLG0x0040 /* NAK sent */
+#define LENGTH_EXCEPT_FLG 0x0020 /* Overflow or Underflow occured */
+#define SETUP_FLG 0x0010 /* SETUP packet received */
+#define SEQ_STAT 0x0008 /* Last Data Toggle Sequence bit sent
+ or received */
+#define TIMEOUT_FLG0x0004 /* Last transmission timed out */
+#define ERROR_FLG 0x0002 /* CRC Err detected in last
+ reception*/
+#define ACK_FLG0x0001 /* Last transaction ACK'D (sent
+ or received) */
+
+/* Defined in DEVICE n ENDPOINT CONTROL REGISTERS */
+#define DIR_SEL_IN 0x0004 /* Last transmission timed out */
+#define EP_ENABLE 0x0002 /* Enable Endpoint */
+
+
+
+struct c67x00_request {
+ struct usb_request req;
+ struct list_head queue;
+};
+
+
+
+struct c67x00_udc_ep {
+ struct usb_ep ep;
+ struct c67x00_udc *udc;
+
+ struct list_head queue;
+ int ep_num;
+ int is_ep_in;
+ int enable;
+ int stopped;
+ int start_io;
+};
+
+#define C67X00_MAX_NB_END_POINTS 8
+
+struct c67x00_udc {
+ spinlock_t lock;
+ struct c67x00_sie *sie;
+ struct usb_gadget gadget;
+ struct usb_gadget_driver *driver;
+ struct c67x00_udc_ep ep[C67X00_MAX_NB_END_POINTS];
+ struct work_struct io_work;
+ int config_nr;
+ /* The highest string descriptor entry
+ (used to retrieve descriptors from gadget driver) */
+ int top_str_id;
+ u16 string_desc_addr;
+};
+
+const static unsigned char get_descriptor_device[] = {
+ USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE,
+ USB_REQ_GET_DESCRIPTOR,
+ 0x00,
+ USB_DT_DEVICE,
+ 0x00,
+ 0x00,
+ 0x12,
+ 0x00
+};
+
+const static unsigned char get_descriptor_config[] = {
+ USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE,
+ USB_REQ_GET_DESCRIPTOR,
+ 0x00,
+ USB_DT_CONFIG,
+ 0x00,
+ 0x00,
+
[patch v4 2/4] USB: add Cypress c67x00 OTG controller core driver
This patch add the core driver for the c67x00 USB OTG controller. The core
driver is responsible for the platform bus binding and creating either
USB HCD or USB Gadget instances for each of the serial interface engines
on the chip.
This driver does not directly implement the HCD or gadget behaviours; it
just controls access to the chip.
Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
MAINTAINERS |6 +
drivers/usb/c67x00/c67x00-drv.c | 236
include/linux/usb/c67x00.h | 48
3 files changed, 290 insertions(+)
Index: linux-2.6/drivers/usb/c67x00/c67x00-drv.c
===
--- /dev/null
+++ linux-2.6/drivers/usb/c67x00/c67x00-drv.c
@@ -0,0 +1,236 @@
+/*
+ * c67x00-drv.c: Cypress C67X00 USB Common infrastructure
+ *
+ * Copyright (C) 2006-2008 Barco N.V.
+ *Derived from the Cypress cy7c67200/300 ezusb linux driver and
+ *based on multiple host controller drivers inside the linux kernel.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA.
+ */
+
+/*
+ * This file implements the common infrastructure for using the c67x00.
+ * It is both the link between the platform configuration and subdrivers and
+ * the link between the common hardware parts and the subdrivers (e.g.
+ * interrupt handling).
+ *
+ * The c67x00 has 2 SIE's (serial interface engine) wich can be configured
+ * to be host, device or OTG (with some limitations, E.G. only SIE1 can be
OTG).
+ *
+ * Depending on the platform configuration, the SIE's are created and
+ * the corresponding subdriver is initialized (c67x00_probe_sie).
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "c67x00.h"
+
+static void c67x00_probe_sie(struct c67x00_sie *sie,
+struct c67x00_device *dev, int sie_num)
+{
+ spin_lock_init(&sie->lock);
+ sie->dev = dev;
+ sie->sie_num = sie_num;
+ sie->mode = c67x00_sie_config(dev->pdata->sie_config, sie_num);
+
+ switch (sie->mode) {
+ case C67X00_SIE_UNUSED:
+ dev_info(sie_dev(sie),
+"Not using SIE %d as requested\n", sie->sie_num);
+ break;
+
+ default:
+ dev_err(sie_dev(sie),
+ "Unsupported configuration: 0x%x for SIE %d\n",
+ sie->mode, sie->sie_num);
+ break;
+ }
+}
+
+static void c67x00_remove_sie(struct c67x00_sie *sie)
+{
+}
+
+
+static irqreturn_t c67x00_irq(int irq, void *__dev)
+{
+ struct c67x00_device *c67x00 = __dev;
+ struct c67x00_sie *sie;
+ u16 msg, int_status;
+ int i, count = 8;
+
+ int_status = c67x00_ll_hpi_status(c67x00);
+ if (!int_status)
+ return IRQ_NONE;
+
+ while (int_status != 0 && (count-- >= 0)) {
+ c67x00_ll_irq(c67x00, int_status);
+ for (i = 0; i < C67X00_SIES; i++) {
+ sie = &c67x00->sie[i];
+ msg = 0;
+ if (int_status & SIEMSG_FLG(i)) {
+ msg = c67x00_ll_get_siemsg(sie);
+ /* clear register to allow next message */
+ c67x00_ll_set_siemsg(sie, 0);
+ }
+ if (sie->irq)
+ sie->irq(sie, int_status, msg);
+ }
+ int_status = c67x00_ll_hpi_status(c67x00);
+ }
+
+ if (int_status)
+ dev_warn(&c67x00->pdev->dev, "Not all interrupts handled! "
+"status = 0x%04x\n", int_status);
+
+ return IRQ_HANDLED;
+}
+
+/* - */
+
+static int __devinit c67x00_drv_probe(struct platform_device *pdev)
+{
+ struct c67x00_device *c67x00;
+ struct c67x00_platform_data *pdata;
+ struct resource *res, *res2;
+ int ret, i;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+
+ res2 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!res2)
+ return -ENODEV;
+
+ pdata = pdev->dev.platform_data;
+
Query EHCI suspend/resume
I have a general query on EHCI manual suspend/resume behavior. For EHCI HCD, On doing a manual suspend of a device using sysfs power/level, what happens of the already submitted URBs? are the URBs completed with whatever data has been sent? Or URB context is maintained and are restarted on a RESUME? - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query EHCI suspend/resume
Am Montag, 21. Januar 2008 13:21:01 schrieb Pandita, Vikram: > > I have a general query on EHCI manual suspend/resume behavior. > > For EHCI HCD, On doing a manual suspend of a device using sysfs power/level, > what happens of the already submitted URBs? > > are the URBs completed with whatever data has been sent? Or > URB context is maintained and are restarted on a RESUME? The driver's suspend() method is called. It has to deal with outstanding URBs, either waiting briefly for them or canceling them. Likewise a driver is responsible for resubmitting URBs upon resume(). This behavior is independent of the HCD used. HTH Oliver - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Query EHCI suspend/resume
Hi Oliver >Sent: Monday, January 21, 2008 6:18 PM >> I have a general query on EHCI manual suspend/resume behavior. >> >> For EHCI HCD, On doing a manual suspend of a device using sysfs power/level, >> what happens of the >already submitted URBs? >> >> are the URBs completed with whatever data has been sent? Or >> URB context is maintained and are restarted on a RESUME? > >The driver's suspend() method is called. It has to deal with outstanding >URBs, either waiting briefly for them or canceling them. Likewise a driver >is responsible for resubmitting URBs upon resume(). > >This behavior is independent of the HCD used. For the case where struct hc_driver ehci_hc_driver.bus_suspend = ehci_bus_suspend() (mine is an EHCI hcd) I can see that ehci_bus_suspend() just halts the EHCI hcd, without deleting the qh or qtds? Is that right? And ehci_bus_resume() again starts the EHCI enabling the qhs. Does that mean if nothing is done to URBs in Class driver suspend function, the old URBs should continue to work on RESUME? > > HTH > Oliver - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query EHCI suspend/resume
Am Montag, 21. Januar 2008 13:53:38 schrieb Pandita, Vikram: > Hi Oliver > > >Sent: Monday, January 21, 2008 6:18 PM > >> I have a general query on EHCI manual suspend/resume behavior. > >> > >> For EHCI HCD, On doing a manual suspend of a device using sysfs > >> power/level, what happens of the > >already submitted URBs? > >> > >> are the URBs completed with whatever data has been sent? Or > >> URB context is maintained and are restarted on a RESUME? > > > >The driver's suspend() method is called. It has to deal with outstanding > >URBs, either waiting briefly for them or canceling them. Likewise a driver > >is responsible for resubmitting URBs upon resume(). > > > >This behavior is independent of the HCD used. > > For the case where struct hc_driver ehci_hc_driver.bus_suspend = > ehci_bus_suspend() (mine is an EHCI hcd) > > I can see that ehci_bus_suspend() just halts the EHCI hcd, without deleting > the qh or qtds? Is that right? And ehci_bus_resume() again starts the EHCI > enabling the qhs. > > Does that mean if nothing is done to URBs in Class driver suspend function, > the old URBs should continue to work on RESUME? The bus will not be suspend unless all devices on the bus are suspended. While all devices on the bus are suspend no URBs can be in flight. In theory IIRC halting EHCI should have the effect you describe, but it should never happen. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Query EHCI suspend/resume
Hi Oliver >Sent: Monday, January 21, 2008 6:46 PM >> >> I have a general query on EHCI manual suspend/resume behavior. >> >> >> >> For EHCI HCD, On doing a manual suspend of a device using sysfs >> >> power/level, what happens of the >> >already submitted URBs? >> >> >> >> are the URBs completed with whatever data has been sent? Or >> >> URB context is maintained and are restarted on a RESUME? >> > >> >The driver's suspend() method is called. It has to deal with outstanding >> >URBs, either waiting briefly for them or canceling them. Likewise a driver >> >is responsible for resubmitting URBs upon resume(). >> > >> >This behavior is independent of the HCD used. >> >> For the case where struct hc_driver ehci_hc_driver.bus_suspend = >> ehci_bus_suspend() (mine is an >EHCI hcd) >> >> I can see that ehci_bus_suspend() just halts the EHCI hcd, without deleting >> the qh or qtds? Is that >right? And ehci_bus_resume() again starts the EHCI enabling the qhs. >> >> Does that mean if nothing is done to URBs in Class driver suspend function, >> the old URBs should >continue to work on RESUME? > >The bus will not be suspend unless all devices on the bus are suspended. While I think this behavior may happen for Autosuspend mode. However my case is Manual mode and I understand that anytime the bus could be forcefully suspended. In that case if there are pending URBs, will they stop and restart on a RESUME? >all devices on the bus are suspend no URBs can be in flight. >In theory IIRC halting EHCI should have the effect you describe, but it should >never happen. > > Regards > Oliver - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query EHCI suspend/resume
> >The bus will not be suspend unless all devices on the bus are suspended.
> >While
>
> I think this behavior may happen for Autosuspend mode.
> However my case is Manual mode and I understand that anytime the bus could be
> forcefully suspended.
> In that case if there are pending URBs, will they stop and restart on a
> RESUME?
static int hub_suspend(struct usb_interface *intf, pm_message_t msg)
{
struct usb_hub *hub = usb_get_intfdata (intf);
struct usb_device *hdev = hub->hdev;
unsignedport1;
/* fail if children aren't already suspended */
for (port1 = 1; port1 <= hdev->maxchild; port1++) {
struct usb_device *udev;
udev = hdev->children [port1-1];
if (udev && udev->can_submit) {
if (!hdev->auto_pm)
dev_dbg(&intf->dev, "port %d nyet suspended\n",
port1);
return -EBUSY;
}
}
You will get into the code path that returns -EBUSY and the suspend will
fail.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]make sure usb serial drivers don't flush to logically disconnected devices
If disconnect() is called for a logical disconnect, no more IO must be
done after disconnect() returns, or the old and new drivers may conflict.
This patch avoids this by using the flag and lock introduced by the earlier
patch for the mos7720 driver.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
2.6.25 material.
Regards
Oliver
--- linux-2.6.24-serial_intfdata/drivers/usb/serial/whiteheat.c.alt
2008-01-21 15:12:38.0 +0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/whiteheat.c 2008-01-21
15:12:45.0 +0100
@@ -659,11 +659,14 @@ static void whiteheat_close(struct usb_s
struct list_head *tmp2;
dbg("%s - port %d", __FUNCTION__, port->number);
-
+
+ mutex_lock(&port->serial->disc_mutex);
/* filp is NULL when called from usb_serial_disconnect */
- if (filp && (tty_hung_up_p(filp))) {
+ if ((filp && (tty_hung_up_p(filp))) || port->serial->disconnected) {
+ mutex_unlock(&port->serial->disc_mutex);
return;
}
+ mutex_unlock(&port->serial->disc_mutex);
port->tty->closing = 1;
--- linux-2.6.24-serial_intfdata/drivers/usb/serial/mct_u232.c.alt
2008-01-21 16:43:21.0 +0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/mct_u232.c 2008-01-21
16:43:38.0 +0100
@@ -482,21 +482,22 @@ error:
static void mct_u232_close (struct usb_serial_port *port, struct file *filp)
{
unsigned int c_cflag;
- unsigned long flags;
unsigned int control_state;
struct mct_u232_private *priv = usb_get_serial_port_data(port);
dbg("%s port %d", __FUNCTION__, port->number);
if (port->tty) {
c_cflag = port->tty->termios->c_cflag;
- if (c_cflag & HUPCL) {
- /* drop DTR and RTS */
- spin_lock_irqsave(&priv->lock, flags);
- priv->control_state &= ~(TIOCM_DTR | TIOCM_RTS);
- control_state = priv->control_state;
- spin_unlock_irqrestore(&priv->lock, flags);
- mct_u232_set_modem_ctrl(port->serial, control_state);
+ mutex_lock(&port->serial->disc_mutex);
+ if (c_cflag & HUPCL && !port->serial->disconnected) {
+ /* drop DTR and RTS */
+ spin_lock_irq(&priv->lock);
+ priv->control_state &= ~(TIOCM_DTR | TIOCM_RTS);
+ control_state = priv->control_state;
+ spin_unlock_irq(&priv->lock);
+ mct_u232_set_modem_ctrl(port->serial, control_state);
}
+ mutex_unlock(&port->serial->disc_mutex);
}
--- linux-2.6.24-serial_intfdata/drivers/usb/serial/option.c.alt
2008-01-21 16:38:44.0 +0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/option.c2008-01-21
16:38:53.0 +0100
@@ -640,7 +640,10 @@ static void option_close(struct usb_seri
portdata->dtr_state = 0;
if (serial->dev) {
- option_send_setup(port);
+ mutex_lock(&serial->disc_mutex);
+ if (!serial->disconnected)
+ option_send_setup(port);
+ mutex_unlock(&serial->disc_mutex);
/* Stop reading/writing urbs */
for (i = 0; i < N_IN_URB; i++)
--- linux-2.6.24-serial_intfdata/drivers/usb/serial/sierra.c.alt
2008-01-21 15:50:45.0 +0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/sierra.c2008-01-21
15:50:50.0 +0100
@@ -561,7 +561,10 @@ static void sierra_close(struct usb_seri
portdata->dtr_state = 0;
if (serial->dev) {
- sierra_send_setup(port);
+ mutex_lock(&serial->disc_mutex);
+ if (!serial->disconnected)
+ sierra_send_setup(port);
+ mutex_unlock(&serial->disc_mutex);
/* Stop reading/writing urbs */
for (i = 0; i < N_IN_URB; i++)
--- linux-2.6.24-serial_intfdata/drivers/usb/serial/visor.c.alt 2008-01-21
15:21:03.0 +0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/visor.c 2008-01-21
15:21:09.0 +0100
@@ -349,16 +349,20 @@ static void visor_close (struct usb_seri
usb_kill_urb(port->read_urb);
usb_kill_urb(port->interrupt_in_urb);
- /* Try to send shutdown message, if the device is gone, this will just
fail. */
- transfer_buffer = kmalloc (0x12, GFP_KERNEL);
- if (transfer_buffer) {
- usb_control_msg (port->serial->dev,
-usb_rcvctrlpipe(port->serial->dev, 0),
-VISOR_CLOSE_NOTIFICATION, 0xc2,
-0x, 0x,
-transfer_buffer, 0x12, 300);
- kfree (transfer_buffer);
+ mutex_lock(&port->serial->disc_mutex);
+
Re: Periodic USB failure
On Sun, 20 Jan 2008, Jon Smirl wrote: > On 1/20/08, David Brownell <[EMAIL PROTECTED]> wrote: > > > > > > Sorry ... I thought he had posted lcpci showing a NEC controller > > > > with EHCI *and* OHCI. > > > > > > It is a NEC controller with both. But I have 1.0 hub plugged in with > > > three 1.0 devices in it. The 1.0 hub causes the OHCI controller in > > > the NEC to be used. > > > > > > I have had even worse luck trying to get three USB audio devices > > > working on 2.0. That NEC chip is a single-TT EHCI implementation. > > > > Actually it's a NEC chip with a zero-TT implementation. ;) > > > > I forget why our high speed root hubs lie about having a TT. > > They probably don't need to do that, except for the ones that > > don't have companion controllers. Like the silicon using the > > IP from ARC, Mentor, and so on. As far as I can tell, there's no reason at all for the root hubs to lie about having a TT. Although then the code in hcd.c:rh_call_control() would have to be expanded to handle the ARC/Mentor/etc. class of controllers. It wouldn't be hard to do. > I tried this setup a while ago on a single-TT 2.0 hub. It would seem > that 4.2Mb of audio data wouldn't fill up a 480Mb channel. The 480-Mb bandwidth between the computer and the hub doesn't matter. What matters is the 12-Mb single-channel bandwidth between the hub and the devices. With multiple TTs it would be 12-Mb multiple-channel and the constraints would be looser. However it certainly is true that even a 12-Mb single channel shouldn't be overloaded by 4.2 Mb of audio data. And in reality it isn't, as can be seen from the fact that your USB-1.1 hub works almost all of the time. The difficulty lies in scheduling the split transactions that fill and empty the TT; that's where there may be room for improvement. > But that's > when I learned about single-TT hubs, the audio would drop out because > of scheduling problems. I tried some of the scheduling patches which > helped but didn't fix it 100%. There's a thread about it in archives > somewhere. I think you were helping, it was about nine months ago. I don't know if there have been any changes to the scheduling code since then. IIRC your earlier tests were made at about the same time the most recent set of improvements were added. > Someone suggested that I switch to a 1.0 hub. I've been using the 1.0 > for the last nine months. The only problem is that it drops all of the > devices about once every 20 hours. That's not a scheduling problem; it appears to be a firmware problem in the hub. Hard to say for certain without the debugging log. > I'll giving up on building a new kernel for the slug, there are way > too many manual steps involved. > http://www.nslu2-linux.org/wiki/Debian/BuildImage > It's just taking too long. I'll ask on the NSLU2 ground maybe someone > will point me at an automated x86 build environment. Why not forget about the slug for a while, and instead dedicate a regular desktop PC to testing for a couple of days? > > Disconnecting isn't what I'd call a PNP issue. > > I think of PNP as being able to plug in three 1.0 audio devices and > have it work on the first try without going through three different > hubs (1.0, 2.0 single-tt, 2.0 multi-tt) to find one that works > reliably. This is a matter of definitions. Is faulty hardware a PNP issue? I'd say it isn't, because faulty hardware can cause problems in any environment -- whether PNP or not. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
On 1/21/08, Peter Korsgaard <[EMAIL PROTECTED]> wrote: > The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed > USB controllers. This patch series implements a HCD driver and shows the > work-in-progress status of a gadget driver. > > I believe patch 1..3 are ready, and I would like to see queued up for 2.6.25. > > Changes since v3: > - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, .. > - The dummy platform_device's created per serial engine are gone. > - Gadget driver (WIP) Can you please post/publish the diff between v3 and this series? Thanks, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9790] New: strange USB related problem
On Mon, 21 Jan 2008 10:23:48 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9790 > >Summary: strange USB related problem >Product: Drivers >Version: 2.5 > KernelVersion: 2.6.23 and above > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: USB > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Latest working kernel version: 2.6.22.12 > > Earliest failing kernel version: 2.6.23.9 Regression... > Distribution: Gentoo > > Hardware Environment: > > ... > > Problem Description: > > First of all, I am sorry for the stupid bug title. Perhaps, you can suggest > Bus > the better one :). > > I use Nikon Coolscan V film scanner to scan the negative films. > > 002 Device 005: ID 04b8:0110 Seiko Epson Corp. Perfection 1650 > > The software is Vuescan (http://www.hamrick.com). This is closed source, > commercial product. I need this since I need infrared cleaning :(. This > software > uses libusb library to access the scanner. > > So, after upgrade from 2.6.20 to 2.6.23 the strange things become occur. > After scanning approx 30-35 frames (one frame is approximately 150Mb of data) > vuescan freezes (precisely, it goes into interruptible sleep). This can > happen > while scanning, and also is can happen while image processing (when the > software > does not talk with the scanner). Strace shows that the last system call is > msync(..,MS_ASYNC). After that another processes marked as 'D' appear, and > after some time the system becomes unresponsible. To prevent, it is possible > kill X server. After that there are no processes marked as 'D' and the system > seems to be absolutely normal. But, it is not the case. After some time > 'D'-processes begin to appear again and the system become more or less > unresponsible. So the system becomes completely broken and I need to reboot. I > compiled the kernel with all possible debug options, but this error is not > accompanies by any kernel message :(. With 2.6.23 this is absolutely > reproducible result. But to reproduce I need approx 2 hours (this is scanning > time) :( > > I also have tested 2.6.22 and 2.6.24. > > 2.6.22 seems to be not broken. > With 2.6.24-rc8 the situation becomes worse: the system completely freezes > after several scans. When things are stuck in D state, please hit ALT-SYSRQ-W or type "echo w > /proc/sysrq-trigger" and then send us (via reply-to-all to this email) the resulting dmesg output, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
On Monday 21 January 2008, Peter Korsgaard wrote: > The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed > USB controllers. This patch series implements a HCD driver and shows the > work-in-progress status of a gadget driver. > > I believe patch 1..3 are ready, and I would like to see queued up for 2.6.25. > > Changes since v3: > - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, .. > - The dummy platform_device's created per serial engine are gone. > - Gadget driver (WIP) > > Comments are very much appreciated. How does this relate to the "v3" patches posted 8-Jan by Grant Likely? Is that the "v3" you were referring to? It's confusing to see two different people submit two sets of patches for the same driver, without any evident coordination... - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
On 1/21/08, David Brownell <[EMAIL PROTECTED]> wrote: > On Monday 21 January 2008, Peter Korsgaard wrote: > > The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed > > USB controllers. This patch series implements a HCD driver and shows the > > work-in-progress status of a gadget driver. > > > > I believe patch 1..3 are ready, and I would like to see queued up for > > 2.6.25. > > > > Changes since v3: > > - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, .. > > - The dummy platform_device's created per serial engine are gone. > > - Gadget driver (WIP) > > > > Comments are very much appreciated. > > How does this relate to the "v3" patches posted 8-Jan by Grant Likely? > Is that the "v3" you were referring to? My v1, v2 and v3 postings were based on Peter's work from about a year ago. I picked up the driver because Peter didn't have any time to work on it. Peter told me last week that this series merges the v3 patches with work that he's done recently now that he has some time to do so again. However, I don't know what the diff is between v3 and this new series. I've also not done a full review, so I cannot make any comment at this time. Personally, I'd prefer to see the v3 series picked up now (as I believe all outstanding comments from the list have been addressed) and have new patches build on top of that, but that's just my preference. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
> "Grant" == Grant Likely <[EMAIL PROTECTED]> writes: Hi, >> Changes since v3: >> - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, .. >> - The dummy platform_device's created per serial engine are gone. >> - Gadget driver (WIP) Grant> Can you please post/publish the diff between v3 and this series? Sure, http://peter.korsgaard.com/c67x00-v3-v4.patch (not posting as it's more than 100k) -- Bye, Peter Korsgaard - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
On Monday 21 January 2008, Peter Korsgaard wrote: > Sure, http://peter.korsgaard.com/c67x00-v3-v4.patch (not posting as > it's more than 100k) I like this bit: > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3832,6 +3832,12 @@ L: linux-usb@vger.kernel.org > S: Maintained > W: http://www.kroah.com/linux-usb/ > > +USB CYPRESS C67X00 DRIVER > +P: Peter Korsgaard > +M: [EMAIL PROTECTED] > +L: linux-usb@vger.kernel.org > +S: Maintained > + > USB DAVICOM DM9601 DRIVER > P: Peter Korsgaard > M: [EMAIL PROTECTED] :) Grant, please let us know if you see anything to object to in this "v4" patch (parts 1..3 only). At a quick glance, I didn't see any ... other than stuff associated with peripheral mode support, which isn't yet proposed for merging. So for the moment it looks like v4 is the one to review (and maybe merge). - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
On 1/21/08, David Brownell <[EMAIL PROTECTED]> wrote: > On Monday 21 January 2008, Peter Korsgaard wrote: > > Sure, http://peter.korsgaard.com/c67x00-v3-v4.patch (not posting as > > it's more than 100k) > > I like this bit: > > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -3832,6 +3832,12 @@ L: linux-usb@vger.kernel.org > > S: Maintained > > W: http://www.kroah.com/linux-usb/ > > > > +USB CYPRESS C67X00 DRIVER > > +P: Peter Korsgaard > > +M: [EMAIL PROTECTED] > > +L: linux-usb@vger.kernel.org > > +S: Maintained > > + > > USB DAVICOM DM9601 DRIVER > > P: Peter Korsgaard > > M: [EMAIL PROTECTED] > > :) > > Grant, please let us know if you see anything to object to in > this "v4" patch (parts 1..3 only). At a quick glance, I didn't > see any ... other than stuff associated with peripheral mode > support, which isn't yet proposed for merging. So for the > moment it looks like v4 is the one to review (and maybe merge). np. Hopefully in the next day or so I'll get to spend some quality time with this diff. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
"reset high speed USB device" with a disk
Hi My external USB disk has never been 100% reliable, but since recently it seems to be causing USB resets more often than before. Therefore a couple questions: 1. Is it dying? should I look for a replacement? 2. Before, if such a reset happened when the disk was mounted it definitely meant SCSI errors, most probably, a disconnect. Now (2.6.22 Debian kernel) these resets seem to be handled transparently - no SCSI or fs errors, just a delay in data transfer and then it just continues. Is it indeed a (relatively) new feature? How normal is it? And how reliable is the recovery? Well, I presume it should be reliable since there are no SCSI / fs errors, but... In short - shall I worry or shall I not?:-) Thanks Guennadi --- Guennadi Liakhovetski - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
> "David" == David Brownell <[EMAIL PROTECTED]> writes: Hi, David> How does this relate to the "v3" patches posted 8-Jan by Grant Likely? David> Is that the "v3" you were referring to? Yes - Sorry, I should have been more clear about that. David> It's confusing to see two different people submit two sets of David> patches for the same driver, without any evident David> coordination... True. The story behind it is that I posted the original patch series back in Spring '06, but real life got in way of me following up on pushing it to mainline (some development was still done on it, and we've shipped it in products). Then Grant picked it up (which I'm grateful for) and posted his v1..v3 series. I have now taken his v3 series and merged it with my development. -- Bye, Peter Korsgaard - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
> "Grant" == Grant Likely <[EMAIL PROTECTED]> writes: Hi, Grant> My v1, v2 and v3 postings were based on Peter's work from about a year Grant> ago. I picked up the driver because Peter didn't have any time to Grant> work on it. Ack. Grant> Peter told me last week that this series merges the v3 patches with Grant> work that he's done recently now that he has some time to do so again. Grant> However, I don't know what the diff is between v3 and this new Grant> series. I've also not done a full review, so I cannot make any Grant> comment at this time. I would be grateful if you would find a bit of time to skim over it - I'll post a diff between v3 and v4-without-the-gadget-part in a moment. Grant> Personally, I'd prefer to see the v3 series picked up now (as I Grant> believe all outstanding comments from the list have been addressed) Grant> and have new patches build on top of that, but that's just my Grant> preference. That's understandable; I would ofcause prefer to see v4 selected instead to get the cleanups and fixes and because the in-progress gadget work is based on it. But anyway, that's details - Most of all I would like to see c67x00 support in mainline, one way or another. Most of the work has been sitting on my hard drive gathering dust since spring 2006. -- Bye, Peter Korsgaard - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Export suspend statistics
This patch exports two statistics to userspace:
/sys/bus/usb/device/.../power/connected_duration
/sys/bus/usb/device/.../power/active_duration
connected_duration is the total time (in msec) that the device has
been connected. active_duration is the total time the device has not
been suspended. With these two statistics, tools like PowerTOP can
calculate the percentage time that a device is active, i.e. not
suspended or auto-suspended.
Users can also use the active_duration to check if a device is actually
autosuspended. Currently, they can set power/level to auto and
power/autosuspend to a positive timeout, but there's no way to know from
userspace if a device was actually autosuspended without looking at the
dmesg output. These statistics will be useful in creating an automated
userspace script to test autosuspend for USB devices.
Signed-off-by: Sarah Sharp <[EMAIL PROTECTED]>
---
drivers/usb/core/hub.c | 10 -
drivers/usb/core/sysfs.c | 49 ++
drivers/usb/core/usb.c |2 +
include/linux/usb.h |3 ++
4 files changed, 63 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index b04d232..ea93842 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1027,8 +1027,10 @@ static void recursively_mark_NOTATTACHED(struct
usb_device *udev)
if (udev->children[i])
recursively_mark_NOTATTACHED(udev->children[i]);
}
- if (udev->state == USB_STATE_SUSPENDED)
+ if (udev->state == USB_STATE_SUSPENDED) {
udev->discon_suspended = 1;
+ udev->active_duration -= jiffies;
+ }
udev->state = USB_STATE_NOTATTACHED;
}
@@ -1077,6 +1079,12 @@ void usb_set_device_state(struct usb_device *udev,
else
device_init_wakeup(&udev->dev, 0);
}
+ if (udev->state == USB_STATE_SUSPENDED &&
+ new_state != USB_STATE_SUSPENDED)
+ udev->active_duration -= jiffies;
+ else if (new_state == USB_STATE_SUSPENDED &&
+ udev->state != USB_STATE_SUSPENDED)
+ udev->active_duration += jiffies;
udev->state = new_state;
} else
recursively_mark_NOTATTACHED(udev);
diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index 32bd130..021b1d3 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -249,6 +249,41 @@ static void remove_persist_attributes(struct device *dev)
#ifdef CONFIG_USB_SUSPEND
static ssize_t
+show_connected_duration(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct usb_device *udev = to_usb_device(dev);
+
+ return sprintf(buf, "%u\n",
+ jiffies_to_msecs(jiffies - udev->connect_time));
+}
+
+static DEVICE_ATTR(connected_duration, S_IRUGO, show_connected_duration, NULL);
+
+/*
+ * If the device is resumed, the last time the device was suspended has
+ * been pre-subtracted from active_duration. We add the current time to
+ * get the duration that the device was actually active.
+ *
+ * If the device is suspended, the active_duration is up-to-date.
+ */
+static ssize_t
+show_active_duration(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct usb_device *udev = to_usb_device(dev);
+ int duration;
+
+ if (udev->state != USB_STATE_SUSPENDED)
+ duration = jiffies_to_msecs(jiffies + udev->active_duration);
+ else
+ duration = jiffies_to_msecs(udev->active_duration);
+ return sprintf(buf, "%u\n", duration);
+}
+
+static DEVICE_ATTR(active_duration, S_IRUGO, show_active_duration, NULL);
+
+static ssize_t
show_autosuspend(struct device *dev, struct device_attribute *attr, char *buf)
{
struct usb_device *udev = to_usb_device(dev);
@@ -365,6 +400,14 @@ static int add_power_attributes(struct device *dev)
rc = sysfs_add_file_to_group(&dev->kobj,
&dev_attr_level.attr,
power_group);
+ if (rc == 0)
+ rc = sysfs_add_file_to_group(&dev->kobj,
+ &dev_attr_connected_duration.attr,
+ power_group);
+ if (rc == 0)
+ rc = sysfs_add_file_to_group(&dev->kobj,
+ &dev_attr_active_duration.attr,
+ power_group);
}
return rc;
}
@@ -372,6 +415,12 @@ static int add_power_attributes(struct device *dev)
static void remove_power_attributes(struct device *dev)
{
sysfs_remove_file_from_group(&dev->kobj,
+ &dev_attr_active_duration.attr,
+
[PATCH v2] Add documentation for USB suspend statistics.
This documents two newly created files: /sys/bus/usb/device/.../power/connected_duration /sys/bus/usb/device/.../power/active_duration Documentation was placed in Documentation/ABI/testing, since that's where the documentation is for the other USB sysfs power files. Signed-off-by: Sarah Sharp <[EMAIL PROTECTED]> --- Documentation/ABI/testing/sysfs-bus-usb | 33 +++ 1 files changed, 33 insertions(+), 0 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index 9734577..11a3c16 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -52,3 +52,36 @@ Description: facility is inherently dangerous, it is disabled by default for all devices except hubs. For more information, see Documentation/usb/persist.txt. + +What: /sys/bus/usb/device/.../power/connected_duration +Date: January 2008 +KernelVersion: 2.6.25 +Contact: Sarah Sharp <[EMAIL PROTECTED]> +Description: + If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file + is present. When read, it returns the total time (in msec) + that the USB device has been connected to the machine. This + file is read-only. +Users: + PowerTOP <[EMAIL PROTECTED]> + http://www.lesswatts.org/projects/powertop/ + +What: /sys/bus/usb/device/.../power/active_duration +Date: January 2008 +KernelVersion: 2.6.25 +Contact: Sarah Sharp <[EMAIL PROTECTED]> +Description: + If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file + is present. When read, it returns the total time (in msec) + that the USB device has been active, i.e. not in a suspended + state. This file is read-only. + + Tools can use this file and the connected_duration file to + compute the percentage of time that a device has been active. + For example, + echo $((100 * `cat active_duration` / `cat connected_duration`)) + will give an integer percentage. Note that this does not + account for counter wrap. +Users: + PowerTOP <[EMAIL PROTECTED]> + http://www.lesswatts.org/projects/powertop/ -- 1.5.2.5 - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Export suspend statistics.
Greg, Arjan wants the suspend statistics exported to userspace in msec, rather than jiffies. I'll send the two updated patches shortly. I grabbed the statistics patch from your tree before modifying. Sarah - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9790] New: strange USB related problem
This is with gentoo 2.6.23 kernel: Sched Debug Version: v0.05-v20, 2.6.23-gentoo-r5 #2 now at 9040171717158 nsecs cpu#0, 1869.895 MHz .nr_running: 3 .load : 5169 .ls.delta_fair : 664772323 .ls.delta_exec : 4091541087 .nr_switches : 10544602 .nr_load_updates : 4325482 .nr_uninterruptible: 4294961682 .jiffies : 8740172 .next_balance : 8740166 .curr->pid : 0 .clock : 4324829045057 .idle_clock: 0 .prev_clock_raw: 9066780320360 .clock_warps : 0 .clock_overflows : 4715123 .clock_deep_idle_events: 0 .clock_max_delta : 999848 .cpu_load[0] : 0 .cpu_load[1] : 0 .cpu_load[2] : 0 .cpu_load[3] : 0 .cpu_load[4] : 0 cfs_rq .fair_clock: 1056766578052 .exec_clock: 1060302060293 .wait_runtime : 0 .wait_runtime_overruns : 0 .wait_runtime_underruns: 0 .sleeper_bonus : 10510116 .wait_runtime_rq_sum : 40047342 runnable tasks: task PIDtree-key delta waiting switches priosum-execsum-wait sum-sleepwait-overrun wait-underrun -- events/0 9 1056753454054 -13123998 4000 17253 115 0 0 0 0 0 hald-addon-keyb 10512 1056726578052 -4000 4000 6512 120 0 0 0 0 0 X 12835 1056806530710 39952658 -39952658 1337718 120 0 0 0 0 0 cpu#1, 1869.895 MHz .nr_running: 1 .load : 1024 .ls.delta_fair : 1024090210 .ls.delta_exec : 653910632 .nr_switches : 8659200 .nr_load_updates : 4150215 .nr_uninterruptible: 5620 .jiffies : 8740172 .next_balance : 8740246 .curr->pid : 10053 .clock : 4149587041612 .idle_clock: 0 .prev_clock_raw: 9066779873123 .clock_warps : 0 .clock_overflows : 4345713 .clock_deep_idle_events: 0 .clock_max_delta : 999848 .cpu_load[0] : 1024 .cpu_load[1] : 522 .cpu_load[2] : 331 .cpu_load[3] : 262 .cpu_load[4] : 226 cfs_rq .fair_clock: 949189481552 .exec_clock: 948539490194 .wait_runtime : 0 .wait_runtime_overruns : 0 .wait_runtime_underruns: 0 .sleeper_bonus : 3994179 .wait_runtime_rq_sum : 4000 runnable tasks: task PIDtree-key delta waiting switches priosum-execsum-wait sum-sleepwait-overrun wait-underrun -- R syslog-ng 10053949149481552 -4000 4000 1209 120 0 0 0 0 0 SysRq : Show Blocked State taskPC stack pid father syslog-ng D c066ce00 5848 10053 1 dfa75c00 0046 c066ce00 c066ce00 0282 dfa75be0 c046c0f9 dfdb7780 c066ce00 c2071080 dfbe2c70 00857e29 0282 dfa75c10 00857e29 dfa75c70 dfa75c38 c0469d66 0046 c058a120 d8adfdc4 ceb5dc10 00857e29 Call Trace: [] schedule_timeout+0x46/0x90 [] io_schedule_timeout+0x1e/0x30 [] congestion_wait+0x7b/0xa0 [] balance_dirty_pages+0xae/0x170 [] balance_dirty_pages_ratelimited_nr+0x97/0xb0 [] generic_file_buffered_write+0x2b0/0x660 [] __generic_file_aio_write_nolock+0x247/0x560 [] generic_file_aio_write+0x5a/0xd0 [] ext3_file_write+0x2d/0xc0 [] do_sync_write+0xc7/0x120 [] vfs_write+0x160/0x170 [] sys_write+0x3d/0x70 [] sysenter_past_esp+0x5f/0x99 === mono D c066ce00 6464 13500 1 e08bbdb4 00200046 c066ce00 c066ce00 00200282 e08bbd94 c046c0f9 df8fe780 c066ce00 c2071080 d6e12000 00857e29 00200282 e08bbdc4 00857e29 e08bbe24 e08bbdec c0469d66 00
multiple devices for one USB interface - possible?
Hi! I'm currently writing a USB driver and wonder if I just hit a limitation of the USB framework of Linux. I'm using usb_register_dev() to create USB character devices under /dev. As far as I can see it however one can only create one device for the same USB interface, correct? Here's what I'd like to do: USB Device +--- USB Interface 1 +--- Endpoint 1 (in/out) -> /dev/foo_a (character device) +--- Endpoint 2 (in/out) -> /dev/foo_b (character device) And I tried it this way: In the probe function implementation I use usb_set_intfdata() to store the data structures I need and call usb_register_dev() to create the character devices. In the open function imlementation of the character devices I then use: interface = usb_find_interface(&foo_driver, iminor(inode)); foo_device_data = usb_get_intfdata(interface); to get that mandatory custom data for work in the read(), write() function implementations. Now this works fine for just one character device, but not for more than one character device for same USB interface, since struct usb_interface only stores a scalar minor number instead of a list of minors. So is this indeed a limitation or am I just missing something? Is there a simple workaround or would I need to implement a complete driver class and then use device_create() ? Thanks for any comments! CU Christian - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "reset high speed USB device" with a disk
On Mon, 21 Jan 2008, Guennadi Liakhovetski wrote: > Hi > > My external USB disk has never been 100% reliable, but since recently it > seems to be causing USB resets more often than before. Therefore a couple > questions: > > 1. Is it dying? should I look for a replacement? Maybe. It depends on what is causing the resets. > 2. Before, if such a reset happened when the disk was mounted it > definitely meant SCSI errors, most probably, a disconnect. Now (2.6.22 > Debian kernel) these resets seem to be handled transparently - no SCSI or > fs errors, just a delay in data transfer and then it just continues. Is it > indeed a (relatively) new feature? New since about 2.6.10. :-) > How normal is it? On a well-working system it isn't normal at all. Resets like that are a sign of something wrong. It could be at the electrical level (cable connections or power levels), firmware level, media level (read/write errors), or possibly elsewhere. > And how reliable is > the recovery? Well, I presume it should be reliable since there are no > SCSI / fs errors, but... For certain classes of errors it is quite reliable. For others it doesn't help at all. For example, if the drive's firmware has crashed then a reset isn't likely to help. > In short - shall I worry or shall I not?:-) Since the errors have been increasing in frequency, you probably should worry. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
