RE: [PATCH v7 00/11] usb: musb: adding multi instance support
On Mon, Aug 06, 2012 at 01:22:53, Daniel Mack wrote: On 03.08.2012 17:48, Hiremath, Vaibhav wrote: On Fri, Aug 03, 2012 at 17:11:38, Daniel Mack wrote: On 03.08.2012 11:07, Hiremath, Vaibhav wrote: I have just pushed the code (V7 which Ravi submitted), so can you please try with below branch? https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging-usb Thanks for doing this, but I'm unfortunately getting tons of merge conflicts when I try to put this on top of 3.6-rc1. Still pondering which way around is the easiest to get this solved. OTOH, I wonder whether your staging branches would need to rebased sooner or later anyway? I have already pushed branch based on v3.6-rc1 (boot tested), https://github.com/hvaibhav/am335x-linux/tree/am335x-linux-next-master Sorry, I don't get it yet. Your am335x-linux-next-master can be merged into v3.6-rc1 without problems, but it doesn't contain Ravi's patches. And am335x-upstream-staging-usb doesn't apply on top of either am335x-linux-next-master or v3.6-rc1. Maybe I just miss a detail here. Could you again explain which branch will you publish for merging in the 3.7 merge window, and what are its dependencies? Daniel, Every developer is supposed to submit the patches on top of their maintainer's repository, which may or may not be in-sync with latest linux- next or Linus's tree at given time OR their could be some extra dependency from framework. For example, linux-omap is still not updated to v3.6-rc1, but I have to use linux-omap/master for all patch submissions. It becomes extra work for each developers to maintain branch for both, one against their maintainer HEAD and one against linux-next/master. So I am just pushing the branch which is being tested/validated (on BeagleBone) before submitting patches to the list. I hope this clarifies all your confusion. Thanks, Vaibhav Thanks for your work, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] can: kvaser_usb: Add support for Kvaser CAN/USB devices
On Monday 06 August 2012 07:21:29 Olivier Sobrie wrote: This driver provides support for several Kvaser CAN/USB devices. Such kind of devices supports up to three can network interfaces. It has been tested with a Kvaser USB Leaf Light (one network interface) connected to a pch_can interface. The firmware version of the Kvaser device was 2.5.205. +static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb, + struct net_device *netdev) +{ + struct kvaser_usb_net_priv *priv = netdev_priv(netdev); + struct kvaser_usb *dev = priv-dev; + struct net_device_stats *stats = netdev-stats; + struct can_frame *cf = (struct can_frame *)skb-data; + struct kvaser_usb_tx_urb_context *context = NULL; + struct urb *urb; + void *buf; + struct kvaser_msg *msg; + int i, err; + int ret = NETDEV_TX_OK; + + if (can_dropped_invalid_skb(netdev, skb)) + return NETDEV_TX_OK; + + urb = usb_alloc_urb(0, GFP_ATOMIC); + if (!urb) { + netdev_err(netdev, No memory left for URBs\n); + stats-tx_dropped++; + dev_kfree_skb(skb); + return NETDEV_TX_OK; + } + + buf = usb_alloc_coherent(dev-udev, sizeof(struct kvaser_msg), + GFP_ATOMIC, urb-transfer_dma); usb_alloc_coherent() as a rule only makes sense if you reuse the buffer and in some cases not even then. Please use a simple kmalloc() + if (!buf) { + netdev_err(netdev, No memory left for USB buffer\n); + stats-tx_dropped++; + dev_kfree_skb(skb); + goto nobufmem; + } + + msg = (struct kvaser_msg *)buf; + msg-len = MSG_HEADER_LEN + sizeof(struct kvaser_msg_tx_can); + msg-u.tx_can.flags = 0; + msg-u.tx_can.channel = priv-channel; + + if (cf-can_id CAN_EFF_FLAG) { + msg-id = CMD_TX_EXT_MESSAGE; + msg-u.tx_can.msg[0] = (cf-can_id 24) 0x1f; + msg-u.tx_can.msg[1] = (cf-can_id 18) 0x3f; + msg-u.tx_can.msg[2] = (cf-can_id 14) 0x0f; + msg-u.tx_can.msg[3] = (cf-can_id 6) 0xff; + msg-u.tx_can.msg[4] = cf-can_id 0x3f; + } else { + msg-id = CMD_TX_STD_MESSAGE; + msg-u.tx_can.msg[0] = (cf-can_id 6) 0x1f; + msg-u.tx_can.msg[1] = cf-can_id 0x3f; + } + + msg-u.tx_can.msg[5] = cf-can_dlc; + memcpy(msg-u.tx_can.msg[6], cf-data, cf-can_dlc); + + if (cf-can_id CAN_RTR_FLAG) + msg-u.tx_can.flags |= MSG_FLAG_REMOTE_FRAME; + + for (i = 0; i ARRAY_SIZE(priv-tx_contexts); i++) { + if (priv-tx_contexts[i].echo_index == MAX_TX_URBS) { + context = priv-tx_contexts[i]; + break; + } + } + + if (!context) { + netdev_warn(netdev, cannot find free context\n); + ret = NETDEV_TX_BUSY; + goto releasebuf; + } + + context-priv = priv; + context-echo_index = i; + context-dlc = cf-can_dlc; + + msg-u.tx_can.tid = context-echo_index; + + usb_fill_bulk_urb(urb, dev-udev, + usb_sndbulkpipe(dev-udev, + dev-bulk_out-bEndpointAddress), + buf, msg-len, + kvaser_usb_write_bulk_callback, context); + urb-transfer_flags |= URB_NO_TRANSFER_DMA_MAP; + usb_anchor_urb(urb, priv-tx_submitted); + + can_put_echo_skb(skb, netdev, context-echo_index); + + atomic_inc(priv-active_tx_urbs); + + if (atomic_read(priv-active_tx_urbs) = MAX_TX_URBS) + netif_stop_queue(netdev); + + err = usb_submit_urb(urb, GFP_ATOMIC); + if (unlikely(err)) { + can_free_echo_skb(netdev, context-echo_index); + + atomic_dec(priv-active_tx_urbs); + usb_unanchor_urb(urb); + + stats-tx_dropped++; + + if (err == -ENODEV) + netif_device_detach(netdev); + else + netdev_warn(netdev, Failed tx_urb %d\n, err); + + goto releasebuf; + } + + netdev-trans_start = jiffies; + + usb_free_urb(urb); + + return NETDEV_TX_OK; + +releasebuf: + usb_free_coherent(dev-udev, sizeof(struct kvaser_msg), + buf, urb-transfer_dma); +nobufmem: + usb_free_urb(urb); + return ret; +} +static int kvaser_usb_init_one(struct usb_interface *intf, +const struct usb_device_id *id, int channel) +{ + struct kvaser_usb *dev = usb_get_intfdata(intf); + struct net_device *netdev; + struct kvaser_usb_net_priv *priv; + int i, err; + + netdev = alloc_candev(sizeof(*priv), MAX_TX_URBS); + if (!netdev) { + dev_err(intf-dev, Cannot alloc candev\n); + return
Re: [PATCH 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
Hi Heiko, On Mon, Aug 6, 2012 at 3:24 AM, Heiko Stübner he...@sntech.de wrote: Hi Praveen, Am Mittwoch, 1. August 2012, 15:05:47 schrieb Praveen Paneri: This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. Looks cool. Thanks From what I've seen the phy controllers on newer Samsung SoCs are still somewhat similar to the one on my s3c2416/2450 machines. So hopefully at some point after the driver has settled, I'll find the time to add support for these to the phy driver. Yes! that's great. Out of curiosity, what does the sec in sec_usbphy for? Its Samsung Electronics Co. :) Praveen Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de Heiko --- .../devicetree/bindings/usb/samsung-usbphy.txt |9 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/sec_usbphy.c | 354 drivers/usb/phy/sec_usbphy.h | 48 +++ include/linux/platform_data/s3c-hsotg.h|5 + 6 files changed, 425 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/sec_usbphy.c create mode 100644 drivers/usb/phy/sec_usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..fefd9c8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,9 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index e7cf84f..abbebe2 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -15,3 +15,11 @@ config USB_ISP1301 To compile this driver as a module, choose M here: the module will be called isp1301. + +config SEC_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index eca095b..6bb66f0 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -5,3 +5,4 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG obj-$(CONFIG_USB_ISP1301)+= isp1301.o +obj-$(CONFIG_SEC_USBPHY) += sec_usbphy.o diff --git a/drivers/usb/phy/sec_usbphy.c b/drivers/usb/phy/sec_usbphy.c new file mode 100644 index 000..33119eb --- /dev/null +++ b/drivers/usb/phy/sec_usbphy.c @@ -0,0 +1,354 @@ +/* linux/drivers/usb/phy/sec_usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. +*/ + +#include linux/module.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/delay.h +#include linux/err.h +#include linux/io.h +#include linux/of.h +#include linux/usb/otg.h +#include linux/platform_data/s3c-hsotg.h + +#include sec_usbphy.h + +enum sec_cpu_type { + TYPE_S3C64XX, + TYPE_EXYNOS4210, +}; + +/* + * struct sec_usbphy - transceiver driver state + * @phy: transceiver structure + * @plat: platform data + * @dev: The parent device supplied to the probe function + * @clk: usb phy clock + * @regs: usb phy register memory base + * @cpu_type: machine identifier + */ +struct sec_usbphy { + struct usb_phy phy; + struct s3c_usbphy_plat *plat; + struct device *dev; + struct clk *clk; + void __iomem*regs; + int cpu_type; +}; + +#define phy_to_sec(x)container_of((x),
Re: [PATCH 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
Hi Praveen, On 8/6/12, Praveen Paneri p.pan...@samsung.com wrote: Hi Heiko, On Mon, Aug 6, 2012 at 3:24 AM, Heiko Stübner he...@sntech.de wrote: Hi Praveen, Am Mittwoch, 1. August 2012, 15:05:47 schrieb Praveen Paneri: This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. Looks cool. Thanks From what I've seen the phy controllers on newer Samsung SoCs are still somewhat similar to the one on my s3c2416/2450 machines. So hopefully at some point after the driver has settled, I'll find the time to add support for these to the phy driver. Yes! that's great. Out of curiosity, what does the sec in sec_usbphy for? Its Samsung Electronics Co. :) I'm also prefer to use 'samsung' or 'exynos'. Since I didn't see the 'sec' prefix for samsung drivers. Thank you, Kyungmin Park Praveen Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de Heiko --- .../devicetree/bindings/usb/samsung-usbphy.txt |9 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/sec_usbphy.c | 354 drivers/usb/phy/sec_usbphy.h | 48 +++ include/linux/platform_data/s3c-hsotg.h|5 + 6 files changed, 425 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/sec_usbphy.c create mode 100644 drivers/usb/phy/sec_usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..fefd9c8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,9 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index e7cf84f..abbebe2 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -15,3 +15,11 @@ config USB_ISP1301 To compile this driver as a module, choose M here: the module will be called isp1301. + +config SEC_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index eca095b..6bb66f0 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -5,3 +5,4 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG obj-$(CONFIG_USB_ISP1301)+= isp1301.o +obj-$(CONFIG_SEC_USBPHY) += sec_usbphy.o diff --git a/drivers/usb/phy/sec_usbphy.c b/drivers/usb/phy/sec_usbphy.c new file mode 100644 index 000..33119eb --- /dev/null +++ b/drivers/usb/phy/sec_usbphy.c @@ -0,0 +1,354 @@ +/* linux/drivers/usb/phy/sec_usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. +*/ + +#include linux/module.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/delay.h +#include linux/err.h +#include linux/io.h +#include linux/of.h +#include linux/usb/otg.h +#include linux/platform_data/s3c-hsotg.h + +#include sec_usbphy.h + +enum sec_cpu_type { + TYPE_S3C64XX, + TYPE_EXYNOS4210, +}; + +/* + * struct sec_usbphy - transceiver driver state + * @phy: transceiver structure + * @plat: platform data + * @dev: The parent device supplied to the probe function + * @clk: usb phy clock + * @regs: usb phy register memory base + * @cpu_type: machine identifier + */ +struct sec_usbphy { + struct usb_phy phy; + struct s3c_usbphy_plat *plat; +
Re: [RFC][PATCH 1/4 v3] usb: host: ehci-platform: BUG_ON() to WARN_ON() on probe
On Sun, Aug 05, 2012 at 06:51:34PM -0700, kuninori.morimoto...@renesas.com wrote: We should avoid using BUG_ON() in drivers. This patch switch to use WARN_ON() from BUG_ON(), and avoid NULL pointer access by new macro. Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com --- v2 - v3 - BUG_ON - WARN_ON drivers/usb/host/ehci-platform.c | 18 ++ 1 files changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c index 4b1d896..db27dfe 100644 --- a/drivers/usb/host/ehci-platform.c +++ b/drivers/usb/host/ehci-platform.c @@ -21,6 +21,8 @@ #include linux/platform_device.h #include linux/usb/ehci_pdriver.h +#define ehci_pdata_get(pdata, x) ((pdata) ? (pdata)-x : 0) + FWIW, I think that an inline function would be a slight improvement over a macro here. Likewise for the 2nd patch of this series. static int ehci_platform_reset(struct usb_hcd *hcd) { struct platform_device *pdev = to_platform_device(hcd-self.controller); @@ -28,19 +30,19 @@ static int ehci_platform_reset(struct usb_hcd *hcd) struct ehci_hcd *ehci = hcd_to_ehci(hcd); int retval; - hcd-has_tt = pdata-has_tt; - ehci-has_synopsys_hc_bug = pdata-has_synopsys_hc_bug; - ehci-big_endian_desc = pdata-big_endian_desc; - ehci-big_endian_mmio = pdata-big_endian_mmio; + hcd-has_tt = ehci_pdata_get(pdata, has_tt); + ehci-has_synopsys_hc_bug = ehci_pdata_get(pdata, has_synopsys_hc_bug); + ehci-big_endian_desc = ehci_pdata_get(pdata, big_endian_desc); + ehci-big_endian_mmio = ehci_pdata_get(pdata, big_endian_mmio); - ehci-caps = hcd-regs + pdata-caps_offset; + ehci-caps = hcd-regs + ehci_pdata_get(pdata, caps_offset); retval = ehci_setup(hcd); if (retval) return retval; - if (pdata-port_power_on) + if (ehci_pdata_get(pdata, port_power_on)) ehci_port_power(ehci, 1); - if (pdata-port_power_off) + if (ehci_pdata_get(pdata, port_power_off)) ehci_port_power(ehci, 0); return 0; @@ -85,7 +87,7 @@ static int __devinit ehci_platform_probe(struct platform_device *dev) int irq; int err = -ENOMEM; - BUG_ON(!dev-dev.platform_data); + WARN_ON(!dev-dev.platform_data); if (usb_disabled()) return -ENODEV; -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/4 v3] usb: host: ehci-platform: BUG_ON() to WARN_ON() on probe
Hi Simon Thank you for checking patch +#define ehci_pdata_get(pdata, x) ((pdata) ? (pdata)-x : 0) + FWIW, I think that an inline function would be a slight improvement over a macro here. Likewise for the 2nd patch of this series. All these patches have this kind of macros. I needs maintainer's opinion. If he said it should be inline, I'm happy to send v4 patches. Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
Hi, On Fri, Aug 03, 2012 at 08:01:44PM +0530, ABRAHAM, KISHON VIJAY wrote: + return 0; +} + +#ifdef CONFIG_PM_RUNTIME + +static int omap_usb2_runtime_suspend(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct omap_usb *phy = platform_get_drvdata(pdev); + + clk_disable(phy-wkupclk); weird. I would expect the wakeup clock to be enabled on suspend and disabled on resume. Isn't this causing any unbalanced disable warnings ? Even I was expecting the wakeup clock to be enabled on suspend but if we have this enabled coreaon domain is never gated and core does not hit low power state. btw Why do think this is unbalanced? because you never do a clk_enable() on probe(), so on your first suspend, you will disable the clock without having enabled it before, no? Unless pm_runtime forces a runtime_resume() when you call pm_runtime_enable()... +static int omap_usb2_runtime_resume(struct device *dev) +{ + u32 ret = 0; + struct platform_device *pdev = to_platform_device(dev); + struct omap_usb *phy = platform_get_drvdata(pdev); + + ret = clk_enable(phy-wkupclk); + if (ret 0) + dev_err(phy-dev, Failed to enable wkupclk %d\n, ret); + + return ret; +} + +static const struct dev_pm_ops omap_usb2_pm_ops = { + SET_RUNTIME_PM_OPS(omap_usb2_runtime_suspend, omap_usb2_runtime_resume, + NULL) only runtime ? What about static suspend ? We need this to work also after a traditional echo mem /sys/power/state ;-) The static suspend case is handled by users of this phy using set_suspend hooks. I'm not sure if that's too wise, what if your user enabled USB, but for whatever reason loaded only the phy driver and not musb or dwc3. It will fail, right ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 00/11] omap: musb: Add device tree support
Hi, On Mon, Jul 30, 2012 at 02:39:49PM +0530, Kishon Vijay Abraham I wrote: This patch series adds device tree support for MUSB and device tree support for all the related modules to get MUSB working in OMAP platform. A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. musb core is _NOT_ yet converted to support device tree support as it would need lot of driver re-design because of its enormous use of function pointers. That will be in _TO DO_ list. Changes from v5: minor cleanups like checking for return value in get_sync and few changes in the documentation has been done. Changes from v4: duplicate getting of 'mode' property is removed in omap-musb glue. Changes from v3: remove the address in the node name of usb_otg_hs since the usb_otg_hs node doesn't have a reg property. Thanks Ajay Gupta for finding this. Changes from v2: Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080 Changes from v1: * Fixed Rajendra Nayak comments (regulator naming, compatible naming of musb and other minor cleanups.) * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of ocp2scp, the documentation is updated accordingly. Changes from RFC: Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. Writing to control module register is now handled in otg driver itself. Once the system control module driver get upstreamed, I'll send a patch to make use of API's in control module driver to write to control module register. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv This patch series depends on [PATCH 0/2] omap: add ocp2scp as a bus driver Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP and OMAP3 beagle. Kishon Vijay Abraham I (11): drivers: usb: otg: add a new driver for omap usb2 phy arm/dts: omap: Add omap-usb2 dt data drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 arm: omap: hwmod: add a new addr space in otg for writing to control module drivers: usb: twl6030: Add dt support for twl6030 usb arm/dts: Add twl6030-usb data drivers: usb: twl4030: Add device tree support for twl4030 usb arm/dts: Add twl4030-usb data drivers: usb: musb: Add device tree support for omap musb glue arm/dts: omap: Add usb_otg and glue data arm: omap: phy: remove unused functions from omap-phy-internal.c When you send your next series, can you please split the stuff based on their dependencies or at least note here what depends on what ? I mean, I cannot take the DT patches without an Acked-by Grant and Tony, but the drivers themselves I could take queue them since they're already in good shape ;-) Maybe just start the series with patches without dependencies on one another, and the rest of the series would be ones that need to go together, or something. That'll help me ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 00/11] omap: musb: Add device tree support
On Mon, Aug 6, 2012 at 2:22 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Jul 30, 2012 at 02:39:49PM +0530, Kishon Vijay Abraham I wrote: This patch series adds device tree support for MUSB and device tree support for all the related modules to get MUSB working in OMAP platform. A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. musb core is _NOT_ yet converted to support device tree support as it would need lot of driver re-design because of its enormous use of function pointers. That will be in _TO DO_ list. Changes from v5: minor cleanups like checking for return value in get_sync and few changes in the documentation has been done. Changes from v4: duplicate getting of 'mode' property is removed in omap-musb glue. Changes from v3: remove the address in the node name of usb_otg_hs since the usb_otg_hs node doesn't have a reg property. Thanks Ajay Gupta for finding this. Changes from v2: Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080 Changes from v1: * Fixed Rajendra Nayak comments (regulator naming, compatible naming of musb and other minor cleanups.) * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of ocp2scp, the documentation is updated accordingly. Changes from RFC: Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. Writing to control module register is now handled in otg driver itself. Once the system control module driver get upstreamed, I'll send a patch to make use of API's in control module driver to write to control module register. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv This patch series depends on [PATCH 0/2] omap: add ocp2scp as a bus driver Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP and OMAP3 beagle. Kishon Vijay Abraham I (11): drivers: usb: otg: add a new driver for omap usb2 phy arm/dts: omap: Add omap-usb2 dt data drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 arm: omap: hwmod: add a new addr space in otg for writing to control module drivers: usb: twl6030: Add dt support for twl6030 usb arm/dts: Add twl6030-usb data drivers: usb: twl4030: Add device tree support for twl4030 usb arm/dts: Add twl4030-usb data drivers: usb: musb: Add device tree support for omap musb glue arm/dts: omap: Add usb_otg and glue data arm: omap: phy: remove unused functions from omap-phy-internal.c When you send your next series, can you please split the stuff based on their dependencies or at least note here what depends on what ? I mean, I cannot take the DT patches without an Acked-by Grant and Tony, but the drivers themselves I could take queue them since they're already in good shape ;-) Maybe just start the series with patches without dependencies on one another, and the rest of the series would be ones that need to go together, or something. That'll help me ;-) Ok Felipe. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
Am Montag, 6. August 2012, 10:23:52 schrieb Kyungmin Park: Hi Praveen, On 8/6/12, Praveen Paneri p.pan...@samsung.com wrote: Hi Heiko, On Mon, Aug 6, 2012 at 3:24 AM, Heiko Stübner he...@sntech.de wrote: Hi Praveen, Am Mittwoch, 1. August 2012, 15:05:47 schrieb Praveen Paneri: This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. Looks cool. Thanks From what I've seen the phy controllers on newer Samsung SoCs are still somewhat similar to the one on my s3c2416/2450 machines. So hopefully at some point after the driver has settled, I'll find the time to add support for these to the phy driver. Yes! that's great. Out of curiosity, what does the sec in sec_usbphy for? Its Samsung Electronics Co. :) I'm also prefer to use 'samsung' or 'exynos'. Since I didn't see the 'sec' prefix for samsung drivers. I'd second that. All new generic samsung drivers look like this (i.e. gpio- samsung, pwm-samsung). Just checked the datasheets again. This general phy type is used in some form down to the S3C2443, so I'd prefer something with samsung in the name :-) Heiko Thank you, Kyungmin Park Praveen Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de Heiko --- .../devicetree/bindings/usb/samsung-usbphy.txt |9 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/sec_usbphy.c | 354 drivers/usb/phy/sec_usbphy.h 48 +++ include/linux/platform_data/s3c-hsotg.h|5 + 6 files changed, 425 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/sec_usbphy.c create mode 100644 drivers/usb/phy/sec_usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..fefd9c8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,9 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index e7cf84f..abbebe2 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -15,3 +15,11 @@ config USB_ISP1301 To compile this driver as a module, choose M here: the module will be called isp1301. + +config SEC_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index eca095b..6bb66f0 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -5,3 +5,4 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG obj-$(CONFIG_USB_ISP1301)+= isp1301.o +obj-$(CONFIG_SEC_USBPHY) += sec_usbphy.o diff --git a/drivers/usb/phy/sec_usbphy.c b/drivers/usb/phy/sec_usbphy.c new file mode 100644 index 000..33119eb --- /dev/null +++ b/drivers/usb/phy/sec_usbphy.c @@ -0,0 +1,354 @@ +/* linux/drivers/usb/phy/sec_usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. +*/ + +#include linux/module.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/delay.h +#include linux/err.h +#include linux/io.h +#include linux/of.h +#include linux/usb/otg.h +#include
Re: [PATCH v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
Hi Felipe, On Mon, Aug 6, 2012 at 2:19 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Fri, Aug 03, 2012 at 08:01:44PM +0530, ABRAHAM, KISHON VIJAY wrote: + return 0; +} + +#ifdef CONFIG_PM_RUNTIME + +static int omap_usb2_runtime_suspend(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct omap_usb *phy = platform_get_drvdata(pdev); + + clk_disable(phy-wkupclk); weird. I would expect the wakeup clock to be enabled on suspend and disabled on resume. Isn't this causing any unbalanced disable warnings ? Even I was expecting the wakeup clock to be enabled on suspend but if we have this enabled coreaon domain is never gated and core does not hit low power state. btw Why do think this is unbalanced? because you never do a clk_enable() on probe(), so on your first suspend, you will disable the clock without having enabled it before, no? Unless pm_runtime forces a runtime_resume() when you call pm_runtime_enable()... +static int omap_usb2_runtime_resume(struct device *dev) +{ + u32 ret = 0; + struct platform_device *pdev = to_platform_device(dev); + struct omap_usb *phy = platform_get_drvdata(pdev); + + ret = clk_enable(phy-wkupclk); + if (ret 0) + dev_err(phy-dev, Failed to enable wkupclk %d\n, ret); + + return ret; +} + +static const struct dev_pm_ops omap_usb2_pm_ops = { + SET_RUNTIME_PM_OPS(omap_usb2_runtime_suspend, omap_usb2_runtime_resume, + NULL) only runtime ? What about static suspend ? We need this to work also after a traditional echo mem /sys/power/state ;-) The static suspend case is handled by users of this phy using set_suspend hooks. I'm not sure if that's too wise, what if your user enabled USB, but for whatever reason loaded only the phy driver and not musb or dwc3. It will fail, right ? The enabling and disabling of phy is solely governed by usb controller driver (musb/dwc3). So if you dont have musb/dwc3 loaded, the phy will be for sure disabled. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: ftdi_sio: Quiet sparse noise about using plain integer was NULL pointer
Pointers should not be compared to plain integers. Quiets the sparse warning: warning: Using plain integer as NULL pointer Signed-off-by: Ying Xue ying@windriver.com --- drivers/usb/serial/ftdi_sio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index bc912e5..70688cb 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -2106,7 +2106,7 @@ static void ftdi_set_termios(struct tty_struct *tty, cflag = termios-c_cflag; - if (old_termios == 0) + if (!old_termios) goto no_skip; if (old_termios-c_cflag == termios-c_cflag -- 1.6.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
On Mon, Aug 06, 2012 at 03:14:42PM +0530, ABRAHAM, KISHON VIJAY wrote: +static int omap_usb2_runtime_resume(struct device *dev) +{ + u32 ret = 0; + struct platform_device *pdev = to_platform_device(dev); + struct omap_usb *phy = platform_get_drvdata(pdev); + + ret = clk_enable(phy-wkupclk); + if (ret 0) + dev_err(phy-dev, Failed to enable wkupclk %d\n, ret); + + return ret; +} + +static const struct dev_pm_ops omap_usb2_pm_ops = { + SET_RUNTIME_PM_OPS(omap_usb2_runtime_suspend, omap_usb2_runtime_resume, + NULL) only runtime ? What about static suspend ? We need this to work also after a traditional echo mem /sys/power/state ;-) The static suspend case is handled by users of this phy using set_suspend hooks. I'm not sure if that's too wise, what if your user enabled USB, but for whatever reason loaded only the phy driver and not musb or dwc3. It will fail, right ? The enabling and disabling of phy is solely governed by usb controller driver (musb/dwc3). So if you dont have musb/dwc3 loaded, the phy will be for sure disabled. fair enough... that's ok then ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
Hi, On Mon, Aug 6, 2012 at 2:53 PM, Heiko Stübner he...@sntech.de wrote: Am Montag, 6. August 2012, 10:23:52 schrieb Kyungmin Park: Hi Praveen, On 8/6/12, Praveen Paneri p.pan...@samsung.com wrote: Hi Heiko, On Mon, Aug 6, 2012 at 3:24 AM, Heiko Stübner he...@sntech.de wrote: Hi Praveen, Am Mittwoch, 1. August 2012, 15:05:47 schrieb Praveen Paneri: This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. Looks cool. Thanks From what I've seen the phy controllers on newer Samsung SoCs are still somewhat similar to the one on my s3c2416/2450 machines. So hopefully at some point after the driver has settled, I'll find the time to add support for these to the phy driver. Yes! that's great. Out of curiosity, what does the sec in sec_usbphy for? Its Samsung Electronics Co. :) I'm also prefer to use 'samsung' or 'exynos'. Since I didn't see the 'sec' prefix for samsung drivers. I'd second that. All new generic samsung drivers look like this (i.e. gpio- samsung, pwm-samsung). Just checked the datasheets again. This general phy type is used in some form down to the S3C2443, so I'd prefer something with samsung in the name :-) Yes! That makes sense. I will change the name to samsung_usbphy Praveen Heiko Thank you, Kyungmin Park Praveen Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de Heiko --- .../devicetree/bindings/usb/samsung-usbphy.txt |9 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/sec_usbphy.c | 354 drivers/usb/phy/sec_usbphy.h 48 +++ include/linux/platform_data/s3c-hsotg.h|5 + 6 files changed, 425 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/sec_usbphy.c create mode 100644 drivers/usb/phy/sec_usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..fefd9c8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,9 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index e7cf84f..abbebe2 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -15,3 +15,11 @@ config USB_ISP1301 To compile this driver as a module, choose M here: the module will be called isp1301. + +config SEC_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index eca095b..6bb66f0 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -5,3 +5,4 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG obj-$(CONFIG_USB_ISP1301)+= isp1301.o +obj-$(CONFIG_SEC_USBPHY) += sec_usbphy.o diff --git a/drivers/usb/phy/sec_usbphy.c b/drivers/usb/phy/sec_usbphy.c new file mode 100644 index 000..33119eb --- /dev/null +++ b/drivers/usb/phy/sec_usbphy.c @@ -0,0 +1,354 @@ +/* linux/drivers/usb/phy/sec_usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. +*/ + +#include linux/module.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/delay.h
[PATCH] usb/dwc3: Correct DEPCFG for Config Action Modify
From: Pratyush ANAND pratyush.an...@st.com We need to issue DEPCFG (with Config Action Set to Modify) as per specification. Even if we do not respect this , it works in normal cases. But, I have observed one failure in very peculiar situation. If cpu clock is very slow and execution of connection done ISR takes long time (may be around 150 mS), then one will never be able to complete even first setup request. Setup bytes is received, but IN data for get device descriptor is never observed on wire. dwc3 always keeps on waiting for first data transfer complete event. It can easily be reproduced even when working with high cpu clock by deliberately putting delay around 150-200 mS at the start of connection done handler. Current patch corrects the error. Signed-off-by: Pratyush Anand pratyush.an...@st.com --- drivers/usb/dwc3/core.h |1 + drivers/usb/dwc3/gadget.c |9 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 133ed5a..e5b6496 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -489,6 +489,7 @@ enum dwc3_link_state { }; enum dwc3_device_state { + DWC3_ATTACHED_STATE, DWC3_DEFAULT_STATE, DWC3_ADDRESS_STATE, DWC3_CONFIGURED_STATE, diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index f6ba644..3926095 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -473,6 +473,9 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, struct dwc3_ep *dep, dep-interval = 1 (desc-bInterval - 1); } + if (dwc-dev_state != DWC3_ATTACHED_STATE) + params.param0 |= DWC3_DEPCFG_ACTION_MODIFY; + return dwc3_send_gadget_ep_cmd(dwc, dep-number, DWC3_DEPCMD_SETEPCONFIG, params); } @@ -1551,6 +1554,9 @@ static int dwc3_gadget_start(struct usb_gadget *g, /* Start with SuperSpeed Default */ dwc3_gadget_ep0_desc.wMaxPacketSize = cpu_to_le16(512); + /* At Start - Attached State */ + dwc-dev_state = DWC3_ATTACHED_STATE; + dep = dwc-eps[0]; ret = __dwc3_gadget_ep_enable(dep, dwc3_gadget_ep0_desc, NULL); if (ret) { @@ -1976,6 +1982,9 @@ static void dwc3_gadget_disconnect_interrupt(struct dwc3 *dwc) dwc-gadget.speed = USB_SPEED_UNKNOWN; dwc-setup_packet_pending = false; + + /* At Disconnect - Attached State */ + dwc-dev_state = DWC3_ATTACHED_STATE; } static void dwc3_gadget_usb3_phy_suspend(struct dwc3 *dwc, int suspend) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] Kernel panic when try s3c-hsotg.c with kernel 3.5
I got a kernel panic when try hsotg of ok6410 which is based on s3c6410: cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters Unable to handle kernel NULL pointer dereference at virtual address 0100 pgd = c0004000 [0100] *pgd= Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0Not tainted (3.5.0 #9) PC is at s3c_hsotg_handle_outdone+0x44/0x158 LR is at s3c_hsotg_irq+0x75c/0x804 pc : [c023e7fc]lr : [c024061c]psr: 6193 sp : c782fd20 ip : 0029 fp : c13a1460 r10: r9 : 0008 r8 : 00d0 r7 : c13a1400 r6 : 0002 r5 : r4 : 00060002 r3 : 00d0 r2 : r1 : 00080200 r0 : c13a1400 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 00c5387d Table: 50004008 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc782e268) Stack: (0xc782fd20 to 0xc783) fd20: c13a1460 c0200f64 00060002 0002 c13a1400 0010 fd40: c024061c 00060002 0002 0008 c782fda0 c139a5c0 fd60: c139a5c0 005a c04cc52c c04cc594 c04ea5fe c00565c0 fd80: c04cc52c c139a5c0 c04cc57c c04eb328 fda0: c04cc55c c04eb324 c04c44c0 c0056768 c04cc52c c04cc57c c0058d64 fdc0: 005a c04d7dd8 c005617c 005a c000efbc c04eb350 0001 fde0: c782fe08 c000853c c036c540 6013 c782fe3c c04cc57c c04cc55c fe00: 6013 c000dd80 c04cc57c c782c000 0001 6013 c04cc52c fe20: c139a5c0 005a c04cc57c c04cc55c 6013 c04c44c0 f601 c782fe50 fe40: c036c53c c036c540 6013 c023fec0 c00574c8 c008b2dc fe60: c023fec0 c13a1400 005a c139a5c0 c04cc52c c0057960 fe80: 005a c13a1400 c04c44b8 c051d238 c049b0ec c03688fc fea0: c7853e60 c13a1400 c7804f80 c04c44f4 6013 c7855a80 fec0: c04e1bb4 c04c44c0 c04c44c0 c04e1bb4 c04e1bb4 c051d238 c049b0ec fee0: c04eb040 c020588c c04c44c0 c0204524 c04c44c0 c04c44f4 c04e1bb4 c02046ac ff00: c13a01e0 c0204738 c782ff18 c04e1bb4 c0202e30 c7803878 c7823700 ff20: c04dd1d0 c040b8d4 c04e1bb4 c04e1bb4 c04dd1d0 c0203600 c040b8d4 c01b8568 ff40: c04e1bb4 0007 c04eb040 c782e000 c04a65e0 c0204ce8 ff60: c04a65d4 0007 c04eb040 c782e000 c0008628 c04c7ea0 ff80: 009c c0625cf9 c0037178 0006 0006 c0461b84 c042cee8 ffa0: c04c7ea0 c04abdd4 c04a65d4 0007 c04eb040 009c c04841b0 c04a65e0 ffc0: c048430c 0006 0006 c04841b0 c048421c ffe0: c000f08c 0013 c000f08c [c023e7fc] (s3c_hsotg_handle_outdone+0x44/0x158) from [c024061c] (s3c_hsotg_irq+0x75c/0x804) [c024061c] (s3c_hsotg_irq+0x75c/0x804) from [c00565c0] (handle_irq_event_percpu+0x50/0x1bc) [c00565c0] (handle_irq_event_percpu+0x50/0x1bc) from [c0056768] (handle_irq_event+0x3c/0x5c) [c0056768] (handle_irq_event+0x3c/0x5c) from [c0058d64] (handle_level_irq+0x8c/0x118) [c0058d64] (handle_level_irq+0x8c/0x118) from [c005617c] (generic_handle_irq+0x38/0x44) [c005617c] (generic_handle_irq+0x38/0x44) from [c000efbc] (handle_IRQ+0x30/0x84) [c000efbc] (handle_IRQ+0x30/0x84) from [c000853c] (vic_handle_irq+0x68/0xa8) [c000853c] (vic_handle_irq+0x68/0xa8) from [c000dd80] (__irq_svc+0x40/0x60) Exception stack(0xc782fe08 to 0xc782fe50) fe00: c04cc57c c782c000 0001 6013 c04cc52c fe20: c139a5c0 005a c04cc57c c04cc55c 6013 c04c44c0 f601 c782fe50 fe40: c036c53c c036c540 6013 [c000dd80] (__irq_svc+0x40/0x60) from [c036c540] (_raw_spin_unlock_irqrestore+0x10/0x14) [c036c540] (_raw_spin_unlock_irqrestore+0x10/0x14) from [c00574c8] (__setup_irq+0x178/0x3f8) [c00574c8] (__setup_irq+0x178/0x3f8) from [c0057960] (request_threaded_irq+0xc4/0x12c) [c0057960] (request_threaded_irq+0xc4/0x12c) from [c03688fc] (s3c_hsotg_probe+0x14c/0x700) [c03688fc] (s3c_hsotg_probe+0x14c/0x700) from [c020588c] (platform_drv_probe+0x18/0x1c) [c020588c] (platform_drv_probe+0x18/0x1c) from [c0204524] (driver_probe_device+0x78/0x200) [c0204524] (driver_probe_device+0x78/0x200) from [c0204738] (__driver_attach+0x8c/0x90) [c0204738] (__driver_attach+0x8c/0x90) from [c0202e30] (bus_for_each_dev+0x60/0x8c) [c0202e30] (bus_for_each_dev+0x60/0x8c) from [c0203600] (bus_add_driver+0xac/0x250) [c0203600] (bus_add_driver+0xac/0x250) from [c0204ce8] (driver_register+0x58/0x130) [c0204ce8] (driver_register+0x58/0x130) from [c0008628] (do_one_initcall+0x34/0x17c) [c0008628] (do_one_initcall+0x34/0x17c) from [c048430c] (kernel_init+0xf0/0x1bc) [c048430c] (kernel_init+0xf0/0x1bc) from [c000f08c] (kernel_thread_exit+0x0/0x8) Code: e0433106 e0833006 e1a03183 e0828003 (e5984030) ---[ end trace 2ea4e574318ecf99 ]--- Kernel panic - not syncing: Fatal exception in interrupt --- When I try locate the
Re: [BUG] Kernel panic when try s3c-hsotg.c with kernel 3.5
Hi, On Mon, Aug 06, 2012 at 06:12:05PM +0800, Peiyong Feng wrote: I got a kernel panic when try hsotg of ok6410 which is based on s3c6410: cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters Unable to handle kernel NULL pointer dereference at virtual address 0100 pgd = c0004000 [0100] *pgd= Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0Not tainted (3.5.0 #9) PC is at s3c_hsotg_handle_outdone+0x44/0x158 LR is at s3c_hsotg_irq+0x75c/0x804 pc : [c023e7fc]lr : [c024061c]psr: 6193 sp : c782fd20 ip : 0029 fp : c13a1460 r10: r9 : 0008 r8 : 00d0 r7 : c13a1400 r6 : 0002 r5 : r4 : 00060002 r3 : 00d0 r2 : r1 : 00080200 r0 : c13a1400 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 00c5387d Table: 50004008 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc782e268) Stack: (0xc782fd20 to 0xc783) fd20: c13a1460 c0200f64 00060002 0002 c13a1400 0010 fd40: c024061c 00060002 0002 0008 c782fda0 c139a5c0 fd60: c139a5c0 005a c04cc52c c04cc594 c04ea5fe c00565c0 fd80: c04cc52c c139a5c0 c04cc57c c04eb328 fda0: c04cc55c c04eb324 c04c44c0 c0056768 c04cc52c c04cc57c c0058d64 fdc0: 005a c04d7dd8 c005617c 005a c000efbc c04eb350 0001 fde0: c782fe08 c000853c c036c540 6013 c782fe3c c04cc57c c04cc55c fe00: 6013 c000dd80 c04cc57c c782c000 0001 6013 c04cc52c fe20: c139a5c0 005a c04cc57c c04cc55c 6013 c04c44c0 f601 c782fe50 fe40: c036c53c c036c540 6013 c023fec0 c00574c8 c008b2dc fe60: c023fec0 c13a1400 005a c139a5c0 c04cc52c c0057960 fe80: 005a c13a1400 c04c44b8 c051d238 c049b0ec c03688fc fea0: c7853e60 c13a1400 c7804f80 c04c44f4 6013 c7855a80 fec0: c04e1bb4 c04c44c0 c04c44c0 c04e1bb4 c04e1bb4 c051d238 c049b0ec fee0: c04eb040 c020588c c04c44c0 c0204524 c04c44c0 c04c44f4 c04e1bb4 c02046ac ff00: c13a01e0 c0204738 c782ff18 c04e1bb4 c0202e30 c7803878 c7823700 ff20: c04dd1d0 c040b8d4 c04e1bb4 c04e1bb4 c04dd1d0 c0203600 c040b8d4 c01b8568 ff40: c04e1bb4 0007 c04eb040 c782e000 c04a65e0 c0204ce8 ff60: c04a65d4 0007 c04eb040 c782e000 c0008628 c04c7ea0 ff80: 009c c0625cf9 c0037178 0006 0006 c0461b84 c042cee8 ffa0: c04c7ea0 c04abdd4 c04a65d4 0007 c04eb040 009c c04841b0 c04a65e0 ffc0: c048430c 0006 0006 c04841b0 c048421c ffe0: c000f08c 0013 c000f08c [c023e7fc] (s3c_hsotg_handle_outdone+0x44/0x158) from [c024061c] (s3c_hsotg_irq+0x75c/0x804) [c024061c] (s3c_hsotg_irq+0x75c/0x804) from [c00565c0] (handle_irq_event_percpu+0x50/0x1bc) [c00565c0] (handle_irq_event_percpu+0x50/0x1bc) from [c0056768] (handle_irq_event+0x3c/0x5c) [c0056768] (handle_irq_event+0x3c/0x5c) from [c0058d64] (handle_level_irq+0x8c/0x118) [c0058d64] (handle_level_irq+0x8c/0x118) from [c005617c] (generic_handle_irq+0x38/0x44) [c005617c] (generic_handle_irq+0x38/0x44) from [c000efbc] (handle_IRQ+0x30/0x84) [c000efbc] (handle_IRQ+0x30/0x84) from [c000853c] (vic_handle_irq+0x68/0xa8) [c000853c] (vic_handle_irq+0x68/0xa8) from [c000dd80] (__irq_svc+0x40/0x60) Exception stack(0xc782fe08 to 0xc782fe50) fe00: c04cc57c c782c000 0001 6013 c04cc52c fe20: c139a5c0 005a c04cc57c c04cc55c 6013 c04c44c0 f601 c782fe50 fe40: c036c53c c036c540 6013 [c000dd80] (__irq_svc+0x40/0x60) from [c036c540] (_raw_spin_unlock_irqrestore+0x10/0x14) [c036c540] (_raw_spin_unlock_irqrestore+0x10/0x14) from [c00574c8] (__setup_irq+0x178/0x3f8) [c00574c8] (__setup_irq+0x178/0x3f8) from [c0057960] (request_threaded_irq+0xc4/0x12c) [c0057960] (request_threaded_irq+0xc4/0x12c) from [c03688fc] (s3c_hsotg_probe+0x14c/0x700) [c03688fc] (s3c_hsotg_probe+0x14c/0x700) from [c020588c] (platform_drv_probe+0x18/0x1c) [c020588c] (platform_drv_probe+0x18/0x1c) from [c0204524] (driver_probe_device+0x78/0x200) [c0204524] (driver_probe_device+0x78/0x200) from [c0204738] (__driver_attach+0x8c/0x90) [c0204738] (__driver_attach+0x8c/0x90) from [c0202e30] (bus_for_each_dev+0x60/0x8c) [c0202e30] (bus_for_each_dev+0x60/0x8c) from [c0203600] (bus_add_driver+0xac/0x250) [c0203600] (bus_add_driver+0xac/0x250) from [c0204ce8] (driver_register+0x58/0x130) [c0204ce8] (driver_register+0x58/0x130) from [c0008628] (do_one_initcall+0x34/0x17c) [c0008628] (do_one_initcall+0x34/0x17c) from [c048430c] (kernel_init+0xf0/0x1bc) [c048430c] (kernel_init+0xf0/0x1bc) from [c000f08c] (kernel_thread_exit+0x0/0x8) Code: e0433106 e0833006 e1a03183 e0828003 (e5984030) ---[ end trace 2ea4e574318ecf99 ]---
[PATCH v3 2/2] arm/dts: omap4: Add ocp2scp data
Add ocp2scp data node in omap4 device tree file. Acked-by: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/boot/dts/omap4.dtsi |8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 04cbbcb..8a780b2 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -295,5 +295,13 @@ interrupt-parent = gic; ti,hwmods = dmic; }; + + ocp2scp { + compatible = ti,omap-ocp2scp; + #address-cells = 1; + #size-cells = 1; + ranges; + ti,hwmods = ocp2scp_usb_phy; + }; }; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] omap: add ocp2scp as a bus driver
This patch series is done as a preparatory step for adding phy drivers for dwc3 and musb. This series adds a new driver for ocp2scp (only dt) to which phy drivers are connected. Since currently there is no generic way to create a child device along with doing a pm_runtime_enable (the exact requirement for ocp2scp), I'm creating a separate driver for ocp2scp. Changes from v2: Fixed Felipe's comments to avoid using arch_initcall and make dependent drivers return -EPROBE_DEFER case this isn't ready yet. Changes from v1: Fixed Sergei's comments to remove the address in the node name of ocp2scp since the ocp2scp node doesn't have a reg property. Changes from [RFC PATCH v2 0/2] omap: add ocp2scp as a misc driver: Created a new folder drivers/bus and moved ocp2scp driver from misc to drivers/bus. This patch was developed and tested on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git Kishon Vijay Abraham I (2): drivers: bus: add a new driver for omap-ocp2scp arm/dts: omap4: Add ocp2scp data .../devicetree/bindings/bus/omap-ocp2scp.txt | 10 +++ arch/arm/boot/dts/omap4.dtsi |8 ++ drivers/Kconfig|2 + drivers/Makefile |2 + drivers/bus/Kconfig| 15 drivers/bus/Makefile |5 ++ drivers/bus/omap-ocp2scp.c | 88 7 files changed, 130 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt create mode 100644 drivers/bus/Kconfig create mode 100644 drivers/bus/Makefile create mode 100644 drivers/bus/omap-ocp2scp.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] drivers: bus: add a new driver for omap-ocp2scp
Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of creating all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY is connected to ocp2scp. This also includes device tree support for ocp2scp driver and the documentation with device tree binding information is updated. Acked-by: Felipe Balbi ba...@ti.com Acked-by: Arnd Bergmann a...@arndb.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- .../devicetree/bindings/bus/omap-ocp2scp.txt | 10 +++ drivers/Kconfig|2 + drivers/Makefile |2 + drivers/bus/Kconfig| 15 drivers/bus/Makefile |5 ++ drivers/bus/omap-ocp2scp.c | 88 6 files changed, 122 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt create mode 100644 drivers/bus/Kconfig create mode 100644 drivers/bus/Makefile create mode 100644 drivers/bus/omap-ocp2scp.c diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt new file mode 100644 index 000..d2fe064 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt @@ -0,0 +1,10 @@ +* OMAP OCP2SCP - ocp interface to scp interface + +properties: +- compatible : Should be ti,omap-ocp2scp +- #address-cells, #size-cells : Must be present if the device has sub-nodes +- ranges : the child address space are mapped 1:1 onto the parent address space +- ti,hwmods : must be ocp2scp_usb_phy + +Sub-nodes: +All the devices connected to ocp2scp are described using sub-node to ocp2scp diff --git a/drivers/Kconfig b/drivers/Kconfig index ece958d..324e958 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -2,6 +2,8 @@ menu Device Drivers source drivers/base/Kconfig +source drivers/bus/Kconfig + source drivers/connector/Kconfig source drivers/mtd/Kconfig diff --git a/drivers/Makefile b/drivers/Makefile index 5b42184..f8cdeeb 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -5,6 +5,8 @@ # Rewritten to use lists instead of if-statements. # +obj-y += bus/ + # GPIO must come after pinctrl as gpios may need to mux pins etc obj-y += pinctrl/ obj-y += gpio/ diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig new file mode 100644 index 000..6270415 --- /dev/null +++ b/drivers/bus/Kconfig @@ -0,0 +1,15 @@ +# +# Bus Devices +# + +menu Bus devices + +config OMAP_OCP2SCP + tristate OMAP OCP2SCP DRIVER + help + Driver to enable ocp2scp module which transforms ocp interface + protocol to scp protocol. In OMAP4, USB PHY is connected via + OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via + OCP2SCP. + +endmenu diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile new file mode 100644 index 000..0ec50bc --- /dev/null +++ b/drivers/bus/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the bus drivers. +# + +obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c new file mode 100644 index 000..881d5bb --- /dev/null +++ b/drivers/bus/omap-ocp2scp.c @@ -0,0 +1,88 @@ +/* + * omap-ocp2scp.c - transform ocp interface protocol to scp protocol + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com + * 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. + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * 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. + * + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/err.h +#include linux/pm_runtime.h +#include linux/of.h +#include linux/of_platform.h + +static int ocp2scp_remove_devices(struct device *dev, void *c) +{ + struct platform_device *pdev = to_platform_device(dev); + + platform_device_unregister(pdev); + + return 0; +} + +static int __devinit omap_ocp2scp_probe(struct platform_device *pdev) +{ + int ret; + struct device_node *np = pdev-dev.of_node; + + if (np) { + ret = of_platform_populate(np, NULL, NULL, pdev-dev); + if (ret) { + dev_err(pdev-dev, failed to add resources for ocp2scp child\n); + goto err0; + } + } + pm_runtime_enable(pdev-dev); + + return 0; + +err0: + device_for_each_child(pdev-dev, NULL,
Re: [PATCH v3 1/2] drivers: bus: add a new driver for omap-ocp2scp
On Mon, Aug 06, 2012 at 04:55:30PM +0530, Kishon Vijay Abraham I wrote: Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of creating all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY is connected to ocp2scp. This also includes device tree support for ocp2scp driver and the documentation with device tree binding information is updated. Acked-by: Felipe Balbi ba...@ti.com Acked-by: Arnd Bergmann a...@arndb.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- .../devicetree/bindings/bus/omap-ocp2scp.txt | 10 +++ drivers/Kconfig|2 + drivers/Makefile |2 + drivers/bus/Kconfig| 15 drivers/bus/Makefile |5 ++ drivers/bus/omap-ocp2scp.c | 88 6 files changed, 122 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt create mode 100644 drivers/bus/Kconfig create mode 100644 drivers/bus/Makefile create mode 100644 drivers/bus/omap-ocp2scp.c diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt new file mode 100644 index 000..d2fe064 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt @@ -0,0 +1,10 @@ +* OMAP OCP2SCP - ocp interface to scp interface + +properties: +- compatible : Should be ti,omap-ocp2scp +- #address-cells, #size-cells : Must be present if the device has sub-nodes +- ranges : the child address space are mapped 1:1 onto the parent address space +- ti,hwmods : must be ocp2scp_usb_phy + +Sub-nodes: +All the devices connected to ocp2scp are described using sub-node to ocp2scp diff --git a/drivers/Kconfig b/drivers/Kconfig index ece958d..324e958 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -2,6 +2,8 @@ menu Device Drivers source drivers/base/Kconfig +source drivers/bus/Kconfig + source drivers/connector/Kconfig source drivers/mtd/Kconfig diff --git a/drivers/Makefile b/drivers/Makefile index 5b42184..f8cdeeb 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -5,6 +5,8 @@ # Rewritten to use lists instead of if-statements. # +obj-y+= bus/ + # GPIO must come after pinctrl as gpios may need to mux pins etc obj-y+= pinctrl/ obj-y+= gpio/ diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig new file mode 100644 index 000..6270415 --- /dev/null +++ b/drivers/bus/Kconfig @@ -0,0 +1,15 @@ +# +# Bus Devices +# + +menu Bus devices + +config OMAP_OCP2SCP + tristate OMAP OCP2SCP DRIVER + help + Driver to enable ocp2scp module which transforms ocp interface + protocol to scp protocol. In OMAP4, USB PHY is connected via + OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via + OCP2SCP. + +endmenu diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile new file mode 100644 index 000..0ec50bc --- /dev/null +++ b/drivers/bus/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the bus drivers. +# + +obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c new file mode 100644 index 000..881d5bb --- /dev/null +++ b/drivers/bus/omap-ocp2scp.c @@ -0,0 +1,88 @@ +/* + * omap-ocp2scp.c - transform ocp interface protocol to scp protocol + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com + * 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. + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * 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. + * + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/err.h +#include linux/pm_runtime.h +#include linux/of.h +#include linux/of_platform.h + +static int ocp2scp_remove_devices(struct device *dev, void *c) +{ + struct platform_device *pdev = to_platform_device(dev); + + platform_device_unregister(pdev); + + return 0; +} + +static int __devinit omap_ocp2scp_probe(struct platform_device *pdev) +{ + int ret; + struct device_node *np = pdev-dev.of_node; + + if (np) { + ret = of_platform_populate(np, NULL, NULL, pdev-dev); + if (ret) { + dev_err(pdev-dev, failed to add
Re: [PATCH] usb/dwc3: Correct DEPCFG for Config Action Modify
Hi, On Mon, Aug 06, 2012 at 03:33:16PM +0530, Pratyush Anand wrote: From: Pratyush ANAND pratyush.an...@st.com We need to issue DEPCFG (with Config Action Set to Modify) as per specification. Even if we do not respect this , it works in normal cases. But, I have observed one failure in very peculiar situation. If cpu clock is very slow and execution of connection done ISR takes long time (may be around 150 mS), then one will never be able to complete even first setup request. Setup bytes is received, but IN data for get device descriptor is never observed on wire. dwc3 always keeps on waiting for first data transfer complete event. It can easily be reproduced even when working with high cpu clock by deliberately putting delay around 150-200 mS at the start of connection done handler. Current patch corrects the error. Signed-off-by: Pratyush Anand pratyush.an...@st.com this is wrong, you implement it with weird heuristics based on the endpoint state. All you needed to do was pass another argument to the set_ep_config() function like I did... --- drivers/usb/dwc3/core.h |1 + drivers/usb/dwc3/gadget.c |9 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 133ed5a..e5b6496 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -489,6 +489,7 @@ enum dwc3_link_state { }; enum dwc3_device_state { + DWC3_ATTACHED_STATE, this is not a USB-defined state, so I don't want to use it. DWC3_DEFAULT_STATE, DWC3_ADDRESS_STATE, DWC3_CONFIGURED_STATE, diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index f6ba644..3926095 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -473,6 +473,9 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, struct dwc3_ep *dep, dep-interval = 1 (desc-bInterval - 1); } + if (dwc-dev_state != DWC3_ATTACHED_STATE) + params.param0 |= DWC3_DEPCFG_ACTION_MODIFY; the modify action is not available on all versions of the core. On older versions of the core, this was called Ignore Sequence Number bit. And this I have already patched, see below: commit 4b345c9a3c7452340fb477868d8db475f05978b1 Author: Felipe Balbi ba...@ti.com Date: Mon Jul 16 14:08:16 2012 +0300 usb: dwc3: gadget: set Ignore Sequence Number bit from ConnectDone Event Databook says we should set Ignore Sequence Number bit from ConnectDone Event, so let's do so. Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 58fdfad..283c0cb 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -431,7 +431,8 @@ static int dwc3_gadget_start_config(struct dwc3 *dwc, struct dwc3_ep *dep) static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, struct dwc3_ep *dep, const struct usb_endpoint_descriptor *desc, - const struct usb_ss_ep_comp_descriptor *comp_desc) + const struct usb_ss_ep_comp_descriptor *comp_desc, + bool ignore) { struct dwc3_gadget_ep_cmd_params params; @@ -441,6 +442,9 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, struct dwc3_ep *dep, | DWC3_DEPCFG_MAX_PACKET_SIZE(usb_endpoint_maxp(desc)) | DWC3_DEPCFG_BURST_SIZE(dep-endpoint.maxburst - 1); + if (ignore) + params.param0 |= DWC3_DEPCFG_IGN_SEQ_NUM; + params.param1 = DWC3_DEPCFG_XFER_COMPLETE_EN | DWC3_DEPCFG_XFER_NOT_READY_EN; @@ -498,7 +502,8 @@ static int dwc3_gadget_set_xfer_resource(struct dwc3 *dwc, struct dwc3_ep *dep) */ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, const struct usb_endpoint_descriptor *desc, - const struct usb_ss_ep_comp_descriptor *comp_desc) + const struct usb_ss_ep_comp_descriptor *comp_desc, + bool ignore) { struct dwc3 *dwc = dep-dwc; u32 reg; @@ -510,7 +515,7 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, return ret; } - ret = dwc3_gadget_set_ep_config(dwc, dep, desc, comp_desc); + ret = dwc3_gadget_set_ep_config(dwc, dep, desc, comp_desc, ignore); if (ret) return ret; @@ -683,7 +688,7 @@ static int dwc3_gadget_ep_enable(struct usb_ep *ep, dev_vdbg(dwc-dev, Enabling %s\n, dep-name); spin_lock_irqsave(dwc-lock, flags); - ret = __dwc3_gadget_ep_enable(dep, desc, ep-comp_desc); + ret = __dwc3_gadget_ep_enable(dep, desc, ep-comp_desc, false); spin_unlock_irqrestore(dwc-lock, flags); return ret; @@ -1518,14 +1523,14 @@ static int dwc3_gadget_start(struct usb_gadget *g, dwc3_gadget_ep0_desc.wMaxPacketSize = cpu_to_le16(512); dep = dwc-eps[0]; - ret
[RFC/PATCH v4] usb: dwc3: Introduce OTG driver for dwc3
This is first release of otg driver for the dwc3 Synopsys USB3 core. The otg driver implements the otg final state machine and control the activation of the device controller or host controller. In this first implementation, only simple DRD mode is implemented, determine if A or B device according to the ID pin as reflected in the OSTS.ConIDSts field. Signed-off-by: Ido Shayevitz i...@codeaurora.org --- drivers/usb/dwc3/Makefile|2 + drivers/usb/dwc3/core.c | 15 +- drivers/usb/dwc3/core.h | 55 - drivers/usb/dwc3/dwc3_otg.c | 537 ++ drivers/usb/dwc3/dwc3_otg.h | 59 + drivers/usb/dwc3/gadget.c| 63 + drivers/usb/host/xhci-plat.c | 21 ++ drivers/usb/host/xhci.c | 13 +- 8 files changed, 755 insertions(+), 10 deletions(-) create mode 100644 drivers/usb/dwc3/dwc3_otg.c create mode 100644 drivers/usb/dwc3/dwc3_otg.h diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile index d441fe4..ffb3f55 100644 --- a/drivers/usb/dwc3/Makefile +++ b/drivers/usb/dwc3/Makefile @@ -1,11 +1,13 @@ ccflags-$(CONFIG_USB_DWC3_DEBUG) := -DDEBUG ccflags-$(CONFIG_USB_DWC3_VERBOSE) += -DVERBOSE_DEBUG +ccflags-y += -Idrivers/usb/host obj-$(CONFIG_USB_DWC3) += dwc3.o dwc3-y := core.o dwc3-y += host.o dwc3-y += gadget.o ep0.o +dwc3-y += dwc3_otg.o ifneq ($(CONFIG_DEBUG_FS),) dwc3-y += debugfs.o diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index c34452a..5343e39 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -517,15 +517,24 @@ static int __devinit dwc3_probe(struct platform_device *pdev) break; case DWC3_MODE_DRD: dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG); + ret = dwc3_otg_init(dwc); + if (ret) { + dev_err(dev, failed to initialize otg\n); + goto err1; + } + ret = dwc3_host_init(dwc); if (ret) { dev_err(dev, failed to initialize host\n); + dwc3_otg_exit(dwc); goto err1; } ret = dwc3_gadget_init(dwc); if (ret) { dev_err(dev, failed to initialize gadget\n); + dwc3_host_exit(dwc); + dwc3_otg_exit(dwc); goto err1; } break; @@ -554,8 +563,9 @@ err2: dwc3_host_exit(dwc); break; case DWC3_MODE_DRD: - dwc3_host_exit(dwc); dwc3_gadget_exit(dwc); + dwc3_host_exit(dwc); + dwc3_otg_exit(dwc); break; default: /* do nothing */ @@ -588,8 +598,9 @@ static int __devexit dwc3_remove(struct platform_device *pdev) dwc3_host_exit(dwc); break; case DWC3_MODE_DRD: - dwc3_host_exit(dwc); dwc3_gadget_exit(dwc); + dwc3_host_exit(dwc); + dwc3_otg_exit(dwc); break; default: /* do nothing */ diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index c611d80..c2521ba 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -50,6 +50,8 @@ #include linux/usb/ch9.h #include linux/usb/gadget.h +#include dwc3_otg.h + /* Global constants */ #define DWC3_EP0_BOUNCE_SIZE 512 #define DWC3_ENDPOINTS_NUM 32 @@ -152,8 +154,9 @@ /* OTG Registers */ #define DWC3_OCFG 0xcc00 #define DWC3_OCTL 0xcc04 -#define DWC3_OEVTEN0xcc08 -#define DWC3_OSTS 0xcc0C +#define DWC3_OEVT 0xcc08 +#define DWC3_OEVTEN0xcc0c +#define DWC3_OSTS 0xcc10 /* Bit fields */ @@ -203,6 +206,9 @@ #define DWC3_GHWPARAMS4_HIBER_SCRATCHBUFS(n) (((n) (0x0f 13)) 13) #define DWC3_MAX_HIBER_SCRATCHBUFS 15 +/* Global HWPARAMS6 Register */ +#define DWC3_GHWPARAMS6_SRP_SUPPORT(1 10) + /* Device Configuration Register */ #define DWC3_DCFG_LPM_CAP (1 22) #define DWC3_DCFG_DEVADDR(addr)((addr) 3) @@ -358,6 +364,38 @@ #define DWC3_DEPCMD_TYPE_BULK 2 #define DWC3_DEPCMD_TYPE_INTR 3 +/* OTG Events Register */ +#define DWC3_OEVT_DEVICEMODE (1 31) +#define DWC3_OEVT_CLEAR_ALL(~DWC3_OEVT_DEVICEMODE) +#define DWC3_OEVTEN_OTGCONIDSTSCHNGEVNT(1 24) +#define DWC3_OEVTEN_OTGADEVBHOSTENDEVNT(1 20) +#define DWC3_OEVTEN_OTGADEVHOSTEVNT(1 19) +#define DWC3_OEVTEN_OTGADEVHNPCHNGEVNT (1 18) +#define DWC3_OEVTEN_OTGADEVSRPDETEVNT
[PATCH v7 6/7] drivers: usb: musb: Add device tree support for omap musb glue
Added device tree support for omap musb driver and updated the Documentation with device tree binding information. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/omap-usb.txt | 34 +++- drivers/usb/musb/omap2430.c| 54 2 files changed, 87 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 52f503b..49a90fb 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -1,4 +1,4 @@ -OMAP USB PHY +OMAP USB PHY AND GLUE OMAP USB2 PHY @@ -15,3 +15,35 @@ usb2phy@4a0ad080 { reg = 0x4a0ad080 0x58, 0x4a002300 0x1; }; + +OMAP MUSB GLUE + - compatible : Should be ti,musb-omap2430 + - ti,hwmods : must be usb_otg_hs + - multipoint : Should be 1 indicating the musb controller supports + multipoint. This is a MUSB configuration-specific setting. + - num_eps : Specifies the number of endpoints. This is also a + MUSB configuration-specific setting. Should be set to 16 + - ram_bits : Specifies the ram address size. Should be set to 12 + - interface_type : This is a board specific setting to describe the type of + interface between the controller and the phy. It should be 0 or 1 + specifying ULPI and UTMI respectively. + - mode : Should be 3 to represent OTG. 1 signifies HOST and 2 + represents PERIPHERAL. + - power : Should be 50. This signifies the controller can supply upto + 100mA when operating in host mode. + +SOC specific device node entry +usb_otg_hs: usb_otg_hs@4a0ab000 { + compatible = ti,musb-omap2430; + ti,hwmods = usb_otg_hs; + multipoint = 1; + num_eps = 16; + ram_bits = 12; +}; + +Board specific device node entry +usb_otg_hs { + interface_type = 1; + mode = 3; + power = 50; +}; diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 74dbd6f..8b1d7c0 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -30,6 +30,7 @@ #include linux/init.h #include linux/list.h #include linux/io.h +#include linux/of.h #include linux/platform_device.h #include linux/dma-mapping.h #include linux/pm_runtime.h @@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32); static int __devinit omap2430_probe(struct platform_device *pdev) { struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data; + struct omap_musb_board_data *data; struct platform_device *musb; struct omap2430_glue*glue; + struct device_node *np = pdev-dev.of_node; + struct musb_hdrc_config *config; struct resource *res; int ret = -ENOMEM; @@ -500,6 +504,42 @@ static int __devinit omap2430_probe(struct platform_device *pdev) if (glue-control_otghs == NULL) dev_dbg(pdev-dev, Failed to obtain control memory\n); + if (np) { + pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL); + if (!pdata) { + dev_err(pdev-dev, + failed to allocate musb platfrom data\n); + ret = -ENOMEM; + goto err1; + } + + data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL); + if (!data) { + dev_err(pdev-dev, + failed to allocate musb board data\n); + ret = -ENOMEM; + goto err1; + } + + config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL); + if (!data) { + dev_err(pdev-dev, + failed to allocate musb hdrc config\n); + goto err1; + } + + of_property_read_u32(np, mode, (u32 *)pdata-mode); + of_property_read_u32(np, interface_type, + (u32 *)data-interface_type); + of_property_read_u32(np, num_eps, (u32 *)config-num_eps); + of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits); + of_property_read_u32(np, power, (u32 *)pdata-power); + config-multipoint = of_property_read_bool(np, multipoint); + + pdata-board_data = data; + pdata-config = config; + } + pdata-platform_ops = omap2430_ops; platform_set_drvdata(pdev, glue); @@ -596,12 +636,26 @@ static struct dev_pm_ops omap2430_pm_ops = { #define DEV_PM_OPS NULL #endif +#ifdef CONFIG_OF +static const struct of_device_id omap2430_id_table[] = { + { + .compatible = ti,omap4-musb + }, + { +
[PATCH v7 2/7] arm: omap: hwmod: add a new addr space in otg for writing to control module
The mailbox register for usb otg in omap is present in control module. On detection of any events VBUS or ID, this register should be written to send the notification to musb core. Till we have a separate control module driver to write to control module, omap2430 will handle the register writes to control module by itself. So a new address space to represent this control module register is added to usb_otg_hs. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index e8e5405..6334e22 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -5885,6 +5885,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = { .pa_end = 0x4a0ab003, .flags = ADDR_TYPE_RT }, + { + .pa_start = 0x4a00233c, + .pa_end = 0x4a00233f, + .flags = ADDR_TYPE_RT + }, { } }; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/7] omap: musb: Add device tree support
This patch series adds device tree support for MUSB and device tree support for all the related modules to get MUSB working in OMAP platform. A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. musb core is _NOT_ yet converted to support device tree support as it would need lot of driver re-design because of its enormous use of function pointers. That will be in _TO DO_ list. Changes from v6: * Removed the dt data part of the patch series. It'll be sent as a separate series. * Replaced arch initcall in omap-usb2 phy driver with a module platform driver. Dependent drivers should use -EPROBE_DEFER. Changes from v5: minor cleanups like checking for return value in get_sync and few changes in the documentation has been done. Changes from v4: duplicate getting of 'mode' property is removed in omap-musb glue. Changes from v3: remove the address in the node name of usb_otg_hs since the usb_otg_hs node doesn't have a reg property. Thanks Ajay Gupta for finding this. Changes from v2: Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080 Changes from v1: * Fixed Rajendra Nayak comments (regulator naming, compatible naming of musb and other minor cleanups.) * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of ocp2scp, the documentation is updated accordingly. Changes from RFC: Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. Writing to control module register is now handled in otg driver itself. Once the system control module driver get upstreamed, I'll send a patch to make use of API's in control module driver to write to control module register. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv This patch series depends on [PATCH v3 0/2] omap: add ocp2scp as a bus driver Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP and OMAP3 beagle. Kishon Vijay Abraham I (7): drivers: usb: phy: add a new driver for omap usb2 phy arm: omap: hwmod: add a new addr space in otg for writing to control module drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 drivers: usb: twl6030: Add dt support for twl6030 usb drivers: usb: twl4030: Add device tree support for twl4030 usb drivers: usb: musb: Add device tree support for omap musb glue arm: omap: phy: remove unused functions from omap-phy-internal.c .../devicetree/bindings/bus/omap-ocp2scp.txt |3 + Documentation/devicetree/bindings/usb/omap-usb.txt | 49 .../devicetree/bindings/usb/twl-usb.txt| 40 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 + arch/arm/mach-omap2/omap_phy_internal.c| 138 -- arch/arm/mach-omap2/twl-common.c |5 - arch/arm/mach-omap2/usb-musb.c |3 - drivers/usb/musb/omap2430.c| 106 +++- drivers/usb/musb/omap2430.h|9 + drivers/usb/otg/twl4030-usb.c | 26 +- drivers/usb/otg/twl6030-usb.c | 157 drivers/usb/phy/Kconfig| 10 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c| 271 include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 16 files changed, 631 insertions(+), 272 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 4/7] drivers: usb: twl6030: Add dt support for twl6030 usb
Add device tree support for twl6030 usb driver. Update the Documentation with device tree binding information. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- .../devicetree/bindings/usb/twl-usb.txt| 21 +++ drivers/usb/otg/twl6030-usb.c | 39 +--- 2 files changed, 47 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt b/Documentation/devicetree/bindings/usb/twl-usb.txt new file mode 100644 index 000..930f9ff --- /dev/null +++ b/Documentation/devicetree/bindings/usb/twl-usb.txt @@ -0,0 +1,21 @@ +USB COMPARATOR OF TWL CHIPS + +TWL6030 USB COMPARATOR + - compatible : Should be ti,twl6030-usb + - interrupts : Two interrupt numbers to the cpu should be specified. First + interrupt number is the otg interrupt number that raises ID interrupts when + the controller has to act as host and the second interrupt number is the + usb interrupt number that raises VBUS interrupts when the controller has to + act as device + - usb-supply : phandle to the regulator device tree node. It should be vusb + if it is twl6030 or ldousb if it is twl6025 subclass. + +twl6030-usb { + compatible = ti,twl6030-usb; + interrupts = 4 10 ; +}; + +Board specific device node entry +twl6030-usb { + usb-supply = vusb; +}; diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c index 32525bb..fcadef7 100644 --- a/drivers/usb/otg/twl6030-usb.c +++ b/drivers/usb/otg/twl6030-usb.c @@ -105,7 +105,7 @@ struct twl6030_usb { u8 asleep; boolirq_enabled; boolvbus_enable; - unsigned long features; + const char *regulator; }; #definecomparator_to_twl(x) container_of((x), struct twl6030_usb, comparator) @@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion *comparator) static int twl6030_usb_ldo_init(struct twl6030_usb *twl) { - char *regulator_name; - - if (twl-features TWL6025_SUBCLASS) - regulator_name = ldousb; - else - regulator_name = vusb; - /* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */ twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG); @@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl) /* Program MISC2 register and set bit VUSB_IN_VBAT */ twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2); - twl-usb3v3 = regulator_get(twl-dev, regulator_name); + twl-usb3v3 = regulator_get(twl-dev, twl-regulator); if (IS_ERR(twl-usb3v3)) return -ENODEV; @@ -322,9 +315,9 @@ static int __devinit twl6030_usb_probe(struct platform_device *pdev) u32 ret; struct twl6030_usb *twl; int status, err; - struct twl4030_usb_data *pdata; - struct device *dev = pdev-dev; - pdata = dev-platform_data; + struct device_node *np = pdev-dev.of_node; + struct device *dev = pdev-dev; + struct twl4030_usb_data *pdata = dev-platform_data; twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL); if (!twl) @@ -333,7 +326,6 @@ static int __devinit twl6030_usb_probe(struct platform_device *pdev) twl-dev= pdev-dev; twl-irq1 = platform_get_irq(pdev, 0); twl-irq2 = platform_get_irq(pdev, 1); - twl-features = pdata-features; twl-linkstat = OMAP_MUSB_UNKNOWN; twl-comparator.set_vbus= twl6030_set_vbus; @@ -345,6 +337,18 @@ static int __devinit twl6030_usb_probe(struct platform_device *pdev) return -EPROBE_DEFER; } + if (np) { + twl-regulator = usb; + } else if (pdata) { + if (pdata-features TWL6025_SUBCLASS) + twl-regulator = ldousb; + else + twl-regulator = vusb; + } else { + dev_err(pdev-dev, twl6030 initialized without pdata\n); + return -EINVAL; + } + /* init spinlock for workqueue */ spin_lock_init(twl-lock); @@ -406,12 +410,21 @@ static int __exit twl6030_usb_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_OF +static const struct of_device_id twl6030_usb_id_table[] = { + { .compatible = ti,twl6030-usb }, + {} +}; +MODULE_DEVICE_TABLE(of, twl6030_usb_id_table); +#endif + static struct platform_driver twl6030_usb_driver = { .probe = twl6030_usb_probe, .remove = __exit_p(twl6030_usb_remove), .driver = { .name = twl6030_usb, .owner = THIS_MODULE, + .of_match_table =
[PATCH v7 7/7] arm: omap: phy: remove unused functions from omap-phy-internal.c
All the unnessary functions in omap-phy-internal is removed. These functionality are now handled by omap-usb2 phy driver. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/omap_phy_internal.c | 138 --- arch/arm/mach-omap2/twl-common.c|5 -- arch/arm/mach-omap2/usb-musb.c |3 - 3 files changed, 146 deletions(-) diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c index d52651a..874aecc 100644 --- a/arch/arm/mach-omap2/omap_phy_internal.c +++ b/arch/arm/mach-omap2/omap_phy_internal.c @@ -31,144 +31,6 @@ #include plat/usb.h #include control.h -/* OMAP control module register for UTMI PHY */ -#define CONTROL_DEV_CONF 0x300 -#define PHY_PD 0x1 - -#define USBOTGHS_CONTROL 0x33c -#defineAVALID BIT(0) -#defineBVALID BIT(1) -#defineVBUSVALID BIT(2) -#defineSESSEND BIT(3) -#defineIDDIG BIT(4) - -static struct clk *phyclk, *clk48m, *clk32k; -static void __iomem *ctrl_base; -static int usbotghs_control; - -int omap4430_phy_init(struct device *dev) -{ - ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K); - if (!ctrl_base) { - pr_err(control module ioremap failed\n); - return -ENOMEM; - } - /* Power down the phy */ - __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF); - - if (!dev) { - iounmap(ctrl_base); - return 0; - } - - phyclk = clk_get(dev, ocp2scp_usb_phy_ick); - if (IS_ERR(phyclk)) { - dev_err(dev, cannot clk_get ocp2scp_usb_phy_ick\n); - iounmap(ctrl_base); - return PTR_ERR(phyclk); - } - - clk48m = clk_get(dev, ocp2scp_usb_phy_phy_48m); - if (IS_ERR(clk48m)) { - dev_err(dev, cannot clk_get ocp2scp_usb_phy_phy_48m\n); - clk_put(phyclk); - iounmap(ctrl_base); - return PTR_ERR(clk48m); - } - - clk32k = clk_get(dev, usb_phy_cm_clk32k); - if (IS_ERR(clk32k)) { - dev_err(dev, cannot clk_get usb_phy_cm_clk32k\n); - clk_put(phyclk); - clk_put(clk48m); - iounmap(ctrl_base); - return PTR_ERR(clk32k); - } - return 0; -} - -int omap4430_phy_set_clk(struct device *dev, int on) -{ - static int state; - - if (on !state) { - /* Enable the phy clocks */ - clk_enable(phyclk); - clk_enable(clk48m); - clk_enable(clk32k); - state = 1; - } else if (state) { - /* Disable the phy clocks */ - clk_disable(phyclk); - clk_disable(clk48m); - clk_disable(clk32k); - state = 0; - } - return 0; -} - -int omap4430_phy_power(struct device *dev, int ID, int on) -{ - if (on) { - if (ID) - /* enable VBUS valid, IDDIG groung */ - __raw_writel(AVALID | VBUSVALID, ctrl_base + - USBOTGHS_CONTROL); - else - /* -* Enable VBUS Valid, AValid and IDDIG -* high impedance -*/ - __raw_writel(IDDIG | AVALID | VBUSVALID, - ctrl_base + USBOTGHS_CONTROL); - } else { - /* Enable session END and IDIG to high impedance. */ - __raw_writel(SESSEND | IDDIG, ctrl_base + - USBOTGHS_CONTROL); - } - return 0; -} - -int omap4430_phy_suspend(struct device *dev, int suspend) -{ - if (suspend) { - /* Disable the clocks */ - omap4430_phy_set_clk(dev, 0); - /* Power down the phy */ - __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF); - - /* save the context */ - usbotghs_control = __raw_readl(ctrl_base + USBOTGHS_CONTROL); - } else { - /* Enable the internel phy clcoks */ - omap4430_phy_set_clk(dev, 1); - /* power on the phy */ - if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) PHY_PD) { - __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF); - mdelay(200); - } - - /* restore the context */ - __raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL); - } - - return 0; -} - -int omap4430_phy_exit(struct device *dev) -{ - if (ctrl_base) -
[PATCH v7 1/7] drivers: usb: phy: add a new driver for omap usb2 phy
All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- .../devicetree/bindings/bus/omap-ocp2scp.txt |3 + Documentation/devicetree/bindings/usb/omap-usb.txt | 17 ++ drivers/usb/phy/Kconfig| 10 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c| 271 include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 7 files changed, 382 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt index d2fe064..bb0c7f4 100644 --- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt @@ -8,3 +8,6 @@ properties: Sub-nodes: All the devices connected to ocp2scp are described using sub-node to ocp2scp +- usb2phy : + The binding details of usb2phy can be found in: + Documentation/devicetree/bindings/usb/omap-usb.txt diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt new file mode 100644 index 000..52f503b --- /dev/null +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -0,0 +1,17 @@ +OMAP USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be ti,omap-usb2 + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added + +This is usually a subnode of ocp2scp to which it is connected. + +usb2phy@4a0ad080 { + compatible = ti,omap-usb2; + reg = 0x4a0ad080 0x58, + 0x4a002300 0x1; +}; diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index e7cf84f..c2ab461 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -4,6 +4,16 @@ comment USB Physical Layer drivers depends on USB || USB_GADGET +config OMAP_USB2 + tristate OMAP USB2 PHY Driver + depends on OMAP_OCP2SCP + select USB_OTG_UTILS + help + Enable this to support the transceiver that is part of SOC. This + driver takes care of all the PHY functionality apart from comparator. + The USB OTG controller communicates with the comparator using this + driver. + config USB_ISP1301 tristate NXP ISP1301 USB transceiver support depends on USB || USB_GADGET diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index eca095b..d3fcec9 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -4,4 +4,5 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG +obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o obj-$(CONFIG_USB_ISP1301) += isp1301.o diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c new file mode 100644 index 000..984899b --- /dev/null +++ b/drivers/usb/phy/omap-usb2.c @@ -0,0 +1,271 @@ +/* + * omap-usb2.c - USB PHY, talking to musb controller in OMAP. + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com + * 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. + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * 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. + * + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/slab.h +#include linux/of.h +#include linux/io.h +#include linux/usb/omap_usb.h +#include linux/usb/phy_companion.h +#include linux/clk.h +#include linux/err.h +#include linux/pm_runtime.h +#include linux/delay.h + +/** + * omap_usb2_set_comparator - links the comparator present in the sytem with + * this phy + * @comparator - the companion phy(comparator) for this phy + * + * The phy companion driver should call this API passing the phy_companion + * filled with set_vbus and
[PATCH v7 5/7] drivers: usb: twl4030: Add device tree support for twl4030 usb
Add device tree support for twl4030 usb driver. Update the Documentation with device tree binding information. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- .../devicetree/bindings/usb/twl-usb.txt| 19 ++ drivers/usb/otg/twl4030-usb.c | 26 +++- 2 files changed, 39 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt b/Documentation/devicetree/bindings/usb/twl-usb.txt index 930f9ff..36b9aed 100644 --- a/Documentation/devicetree/bindings/usb/twl-usb.txt +++ b/Documentation/devicetree/bindings/usb/twl-usb.txt @@ -19,3 +19,22 @@ Board specific device node entry twl6030-usb { usb-supply = vusb; }; + +TWL4030 USB PHY AND COMPARATOR + - compatible : Should be ti,twl4030-usb + - interrupts : The interrupt numbers to the cpu should be specified. First + interrupt number is the otg interrupt number that raises ID interrupts + and VBUS interrupts. The second interrupt number is optional. + - supply-name-supply : phandle to the regulator device tree node. + supply-name should be vusb1v5, vusb1v8 and vusb3v1 + - usb_mode : The mode used by the phy to connect to the controller. 1 + specifies ULPI mode and 2 specifies CEA2011_3PIN mode. + +twl4030-usb { + compatible = ti,twl4030-usb; + interrupts = 10 4 ; + usb1v5-supply = vusb1v5; + usb1v8-supply = vusb1v8; + usb3v1-supply = vusb3v1; + usb_mode = 1; +}; diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c index 523cad5..f0d2e75 100644 --- a/drivers/usb/otg/twl4030-usb.c +++ b/drivers/usb/otg/twl4030-usb.c @@ -585,23 +585,28 @@ static int __devinit twl4030_usb_probe(struct platform_device *pdev) struct twl4030_usb *twl; int status, err; struct usb_otg *otg; - - if (!pdata) { - dev_dbg(pdev-dev, platform_data not available\n); - return -EINVAL; - } + struct device_node *np = pdev-dev.of_node; twl = devm_kzalloc(pdev-dev, sizeof *twl, GFP_KERNEL); if (!twl) return -ENOMEM; + if (np) + of_property_read_u32(np, usb_mode, + (enum twl4030_usb_mode *)twl-usb_mode); + else if (pdata) + twl-usb_mode = pdata-usb_mode; + else { + dev_err(pdev-dev, twl4030 initialized without pdata\n); + return -EINVAL; + } + otg = devm_kzalloc(pdev-dev, sizeof *otg, GFP_KERNEL); if (!otg) return -ENOMEM; twl-dev= pdev-dev; twl-irq= platform_get_irq(pdev, 0); - twl-usb_mode = pdata-usb_mode; twl-vbus_supplied = false; twl-asleep = 1; twl-linkstat = OMAP_MUSB_UNKNOWN; @@ -690,12 +695,21 @@ static int __exit twl4030_usb_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_OF +static const struct of_device_id twl4030_usb_id_table[] = { + { .compatible = ti,twl4030-usb }, + {} +}; +MODULE_DEVICE_TABLE(of, twl4030_usb_id_table); +#endif + static struct platform_driver twl4030_usb_driver = { .probe = twl4030_usb_probe, .remove = __exit_p(twl4030_usb_remove), .driver = { .name = twl4030_usb, .owner = THIS_MODULE, + .of_match_table = of_match_ptr(twl4030_usb_id_table), }, }; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 3/7] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
All the PHY configuration other than VBUS, ID GND and OTG SRP are removed from twl6030. The phy configurations are taken care by the dedicated usb2 phy driver. So twl6030 is made as comparator driver for VBUS and ID detection. Writing to control module which is now handled in omap2430.c should be removed once a driver for control module is in place. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- drivers/usb/musb/omap2430.c | 52 +++--- drivers/usb/musb/omap2430.h |9 drivers/usb/otg/twl6030-usb.c | 118 +++-- 3 files changed, 72 insertions(+), 107 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 392fc7a..74dbd6f 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -44,6 +44,7 @@ struct omap2430_glue { struct platform_device *musb; enum omap_musb_vbus_id_status status; struct work_struct omap_musb_mailbox_work; + u32 __iomem *control_otghs; }; #define glue_to_musb(g)platform_get_drvdata(g-musb) @@ -51,6 +52,26 @@ struct omap2430_glue *_glue; static struct timer_list musb_idle_timer; +/** + * omap4_usb_phy_mailbox - write to usb otg mailbox + * @glue: struct omap2430_glue * + * @val: the value to be written to the mailbox + * + * On detection of a device (ID pin is grounded), this API should be called + * to set AVALID, VBUSVALID and ID pin is grounded. + * + * When OMAP is connected to a host (OMAP in device mode), this API + * is called to set AVALID, VBUSVALID and ID pin in high impedance. + * + * XXX: This function will be removed once we have a seperate driver for + * control module + */ +static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val) +{ + if (glue-control_otghs) + writel(val, glue-control_otghs); +} + static void musb_do_idle(unsigned long _musb) { struct musb *musb = (void *)_musb; @@ -245,6 +266,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox); static void omap_musb_set_mailbox(struct omap2430_glue *glue) { + u32 val; struct musb *musb = glue_to_musb(glue); struct device *dev = musb-controller; struct musb_hdrc_platform_data *pdata = dev-platform_data; @@ -260,7 +282,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue) musb-xceiv-last_event = USB_EVENT_ID; if (!is_otg_enabled(musb) || musb-gadget_driver) { pm_runtime_get_sync(dev); - usb_phy_init(musb-xceiv); + val = AVALID | VBUSVALID; + omap4_usb_phy_mailbox(glue, val); omap2430_musb_set_vbus(musb, 1); } break; @@ -273,7 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue) musb-xceiv-last_event = USB_EVENT_VBUS; if (musb-gadget_driver) pm_runtime_get_sync(dev); - usb_phy_init(musb-xceiv); + val = IDDIG | AVALID | VBUSVALID; + omap4_usb_phy_mailbox(glue, val); break; case OMAP_MUSB_ID_FLOAT: @@ -291,7 +315,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue) if (musb-xceiv-otg-set_vbus) otg_set_vbus(musb-xceiv-otg, 0); } - usb_phy_shutdown(musb-xceiv); + val = SESSEND | IDDIG; + omap4_usb_phy_mailbox(glue, val); break; default: dev_dbg(dev, ID float\n); @@ -366,6 +391,7 @@ err1: static void omap2430_musb_enable(struct musb *musb) { u8 devctl; + u32 val; unsigned long timeout = jiffies + msecs_to_jiffies(1000); struct device *dev = musb-controller; struct omap2430_glue *glue = dev_get_drvdata(dev-parent); @@ -375,7 +401,8 @@ static void omap2430_musb_enable(struct musb *musb) switch (glue-status) { case OMAP_MUSB_ID_GROUND: - usb_phy_init(musb-xceiv); + val = AVALID | VBUSVALID; + omap4_usb_phy_mailbox(glue, val); if (data-interface_type != MUSB_INTERFACE_UTMI) break; devctl = musb_readb(musb-mregs, MUSB_DEVCTL); @@ -394,7 +421,8 @@ static void omap2430_musb_enable(struct musb *musb) break; case OMAP_MUSB_VBUS_VALID: - usb_phy_init(musb-xceiv); + val = IDDIG | AVALID | VBUSVALID; + omap4_usb_phy_mailbox(glue, val); break; default: @@ -404,11 +432,14 @@ static void omap2430_musb_enable(struct musb *musb) static void omap2430_musb_disable(struct musb *musb) { + u32 val; struct device *dev = musb-controller; struct omap2430_glue *glue =
Re: [BUG] Kernel panic when try s3c-hsotg.c with kernel 3.5
Hi, Hi, On Mon, Aug 06, 2012 at 06:12:05PM +0800, Peiyong Feng wrote: I got a kernel panic when try hsotg of ok6410 which is based on s3c6410: As you said, you are using the ok6410. And it is based on the s3c6410 CPU. S3C6410 is a single core CPU. I assume that ok6410 is also single core? cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters Unable to handle kernel NULL pointer dereference at virtual address 0100 pgd = c0004000 [0100] *pgd= Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0Not tainted (3.5.0 #9) PC is at s3c_hsotg_handle_outdone+0x44/0x158 LR is at s3c_hsotg_irq+0x75c/0x804 pc : [c023e7fc]lr : [c024061c]psr: 6193 sp : c782fd20 ip : 0029 fp : c13a1460 r10: r9 : 0008 r8 : 00d0 r7 : c13a1400 r6 : 0002 r5 : r4 : 00060002 r3 : 00d0 r2 : r1 : 00080200 r0 : c13a1400 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 00c5387d Table: 50004008 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc782e268) Stack: (0xc782fd20 to 0xc783) fd20: c13a1460 c0200f64 00060002 0002 c13a1400 0010 fd40: c024061c 00060002 0002 0008 c782fda0 c139a5c0 fd60: c139a5c0 005a c04cc52c c04cc594 c04ea5fe c00565c0 fd80: c04cc52c c139a5c0 c04cc57c c04eb328 fda0: c04cc55c c04eb324 c04c44c0 c0056768 c04cc52c c04cc57c c0058d64 fdc0: 005a c04d7dd8 c005617c 005a c000efbc c04eb350 0001 fde0: c782fe08 c000853c c036c540 6013 c782fe3c c04cc57c c04cc55c fe00: 6013 c000dd80 c04cc57c c782c000 0001 6013 c04cc52c fe20: c139a5c0 005a c04cc57c c04cc55c 6013 c04c44c0 f601 c782fe50 fe40: c036c53c c036c540 6013 c023fec0 c00574c8 c008b2dc fe60: c023fec0 c13a1400 005a c139a5c0 c04cc52c c0057960 fe80: 005a c13a1400 c04c44b8 c051d238 c049b0ec c03688fc fea0: c7853e60 c13a1400 c7804f80 c04c44f4 6013 c7855a80 fec0: c04e1bb4 c04c44c0 c04c44c0 c04e1bb4 c04e1bb4 c051d238 c049b0ec fee0: c04eb040 c020588c c04c44c0 c0204524 c04c44c0 c04c44f4 c04e1bb4 c02046ac ff00: c13a01e0 c0204738 c782ff18 c04e1bb4 c0202e30 c7803878 c7823700 ff20: c04dd1d0 c040b8d4 c04e1bb4 c04e1bb4 c04dd1d0 c0203600 c040b8d4 c01b8568 ff40: c04e1bb4 0007 c04eb040 c782e000 c04a65e0 c0204ce8 ff60: c04a65d4 0007 c04eb040 c782e000 c0008628 c04c7ea0 ff80: 009c c0625cf9 c0037178 0006 0006 c0461b84 c042cee8 ffa0: c04c7ea0 c04abdd4 c04a65d4 0007 c04eb040 009c c04841b0 c04a65e0 ffc0: c048430c 0006 0006 c04841b0 c048421c ffe0: c000f08c 0013 c000f08c [c023e7fc] (s3c_hsotg_handle_outdone+0x44/0x158) from [c024061c] (s3c_hsotg_irq+0x75c/0x804) [c024061c] (s3c_hsotg_irq+0x75c/0x804) from [c00565c0] (handle_irq_event_percpu+0x50/0x1bc) [c00565c0] (handle_irq_event_percpu+0x50/0x1bc) from [c0056768] (handle_irq_event+0x3c/0x5c) [c0056768] (handle_irq_event+0x3c/0x5c) from [c0058d64] (handle_level_irq+0x8c/0x118) [c0058d64] (handle_level_irq+0x8c/0x118) from [c005617c] (generic_handle_irq+0x38/0x44) [c005617c] (generic_handle_irq+0x38/0x44) from [c000efbc] (handle_IRQ+0x30/0x84) [c000efbc] (handle_IRQ+0x30/0x84) from [c000853c] (vic_handle_irq+0x68/0xa8) [c000853c] (vic_handle_irq+0x68/0xa8) from [c000dd80] (__irq_svc+0x40/0x60) Exception stack(0xc782fe08 to 0xc782fe50) fe00: c04cc57c c782c000 0001 6013 c04cc52c fe20: c139a5c0 005a c04cc57c c04cc55c 6013 c04c44c0 f601 c782fe50 fe40: c036c53c c036c540 6013 [c000dd80] (__irq_svc+0x40/0x60) from [c036c540] (_raw_spin_unlock_irqrestore+0x10/0x14) [c036c540] (_raw_spin_unlock_irqrestore+0x10/0x14) from [c00574c8] (__setup_irq+0x178/0x3f8) [c00574c8] (__setup_irq+0x178/0x3f8) from [c0057960] (request_threaded_irq+0xc4/0x12c) [c0057960] (request_threaded_irq+0xc4/0x12c) from [c03688fc] (s3c_hsotg_probe+0x14c/0x700) [c03688fc] (s3c_hsotg_probe+0x14c/0x700) from [c020588c] (platform_drv_probe+0x18/0x1c) [c020588c] (platform_drv_probe+0x18/0x1c) from [c0204524] (driver_probe_device+0x78/0x200) [c0204524] (driver_probe_device+0x78/0x200) from [c0204738] (__driver_attach+0x8c/0x90) [c0204738] (__driver_attach+0x8c/0x90) from [c0202e30] (bus_for_each_dev+0x60/0x8c) [c0202e30] (bus_for_each_dev+0x60/0x8c) from [c0203600] (bus_add_driver+0xac/0x250) [c0203600] (bus_add_driver+0xac/0x250) from [c0204ce8] (driver_register+0x58/0x130) [c0204ce8] (driver_register+0x58/0x130) from [c0008628] (do_one_initcall+0x34/0x17c) [c0008628]
Re: Linux 3.2: USB mouse not recognized after resuming from suspend to RAM
Am Mittwoch, den 20.06.2012, 17:34 +0200 schrieb Paul Menzel: Am Mittwoch, den 20.06.2012, 11:11 -0400 schrieb Alan Stern: On Wed, 20 Jun 2012, Paul Menzel wrote: [This message is more a less the same as sent to the Debian BTS http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678215.] after replacing a broken PS/2 mouse, which worked fine before that, with an USB mouse $ lsusb # output from after the resume and replugged Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 004: ID 046d:c30f Logitech, Inc. Logicool HID-Compliant Keyboard (106 key) Bus 002 Device 003: ID 058f:9254 Alcor Micro Corp. Hub Bus 003 Device 003: ID 1241:1122 Belkin Typhoon Stream Optical Mouse USB+PS/2 the mouse is not working after resuming from suspend to RAM. Replugging the mouse works although that is quite inconvenient. ... [1.660039] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001 [1.660042] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [3.108025] usb 3-1: new low-speed USB device number 2 using ohci_hcd [3.273061] usb 3-1: New USB device found, idVendor=1241, idProduct=1122 [3.273066] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [3.282359] input: HID 1241:1122 as /devices/pci:00/:00:13.1/usb3/3-1/3-1:1.0/input/input2 [3.282472] generic-usb 0003:1241:1122.0003: input,hidraw2: USB HID v1.00 Mouse [HID 1241:1122] on usb-:00:13.1-1/input0 Now the system is resuming after `sudo pm-suspend`. [12498.968042] usb 2-2: reset full-speed USB device number 3 using ohci_hcd [12512.152050] usb 2-1: USB disconnect, device number 2 [12512.544068] usb 3-1: USB disconnect, device number 2 Could the above disconnect be the problem here? Undoubtedly it is related. [12512.968046] usb 2-1: new low-speed USB device number 4 using ohci_hcd [12513.143894] usb 2-1: New USB device found, idVendor=046d, idProduct=c30f [12513.143901] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [12513.143905] usb 2-1: Product: Logitech USB Keyboard [12513.143908] usb 2-1: Manufacturer: Logitech [12513.157357] input: Logitech Logitech USB Keyboard as /devices/pci:00/:00:13.0/usb2/2-1/2-1:1.0/input/input5 [12513.157747] generic-usb 0003:046D:C30F.0004: input,hidraw0: USB HID v1.10 Keyboard [Logitech Logitech USB Keyboard] on usb-:00:13.0-1/input0 [12513.170016] input: Logitech Logitech USB Keyboard as /devices/pci:00/:00:13.0/usb2/2-1/2-1:1.1/input/input6 [12513.170314] generic-usb 0003:046D:C30F.0005: input,hidraw1: USB HID v1.10 Device [Logitech Logitech USB Keyboard] on usb-:00:13.0-1/input1 The keyboard is detected twice, but not the mouse. [12710.284049] usb 3-2: new low-speed USB device number 3 using ohci_hcd [12710.449087] usb 3-2: New USB device found, idVendor=1241, idProduct=1122 [12710.449097] usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [12710.458732] input: HID 1241:1122 as /devices/pci:00/:00:13.1/usb3/3-2/3-2:1.0/input/input7 [12710.459106] generic-usb 0003:1241:1122.0006: input,hidraw2: USB HID v1.00 Mouse [HID 1241:1122] on usb-:00:13.1-2/input0 Replugging the mouse makes it work again. So the mouse is not recognized after the resume. Switching the USB port does not make any difference either. I used that mouse on an ASUS EeePC 701 4G with outdated Debian Sid/unstable and Linux 3.0.0 without problems. Evidently the mouse doesn't like the computer. Have you tried using a different mouse? No, I do not have another USB mouse here. The PS/2 one worked fine. I found another USB mouse and this worked without problems. Another problem indicating the board ASUS M2A-VM [1] behaves strangely, is that the USB keyboard also randomly stops working. When I switched the USB ports today I even got something in the Linux kernel ring buffer. $ dmesg | grep EMI [ 2454.450355] hub 4-0:1.0: port 2 disabled by hub (EMI?), re-enabling... If that happens only when you move the cable between ports, you don't need to worry about it. It should never
Re: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)
On Sun, Aug 5, 2012 at 11:26 PM, Rafael J. Wysocki r...@sisk.pl wrote: --- drivers/base/power/runtime.c | 82 +++ include/linux/pm.h |1 include/linux/pm_runtime.h | 14 +++ 3 files changed, 90 insertions(+), 7 deletions(-) Index: linux/drivers/base/power/runtime.c === --- linux.orig/drivers/base/power/runtime.c +++ linux/drivers/base/power/runtime.c @@ -484,6 +484,15 @@ static int rpm_suspend(struct device *de goto out; } +void rpm_queue_up_resume(struct device *dev) +{ + dev-power.request = RPM_REQ_RESUME; + if (!dev-power.request_pending) { + dev-power.request_pending = true; + queue_work(pm_wq, dev-power.work); + } +} + /** * rpm_resume - Carry out runtime resume of given device. * @dev: Device to resume. @@ -524,7 +533,9 @@ static int rpm_resume(struct device *dev * rather than cancelling it now only to restart it again in the near * future. */ - dev-power.request = RPM_REQ_NONE; + if (dev-power.request != RPM_REQ_RESUME || !dev-power.func) + dev-power.request = RPM_REQ_NONE; + if (!dev-power.timer_autosuspends) pm_runtime_deactivate_timer(dev); @@ -533,6 +544,12 @@ static int rpm_resume(struct device *dev goto out; } + if (dev-power.func (rpmflags RPM_ASYNC)) { + rpm_queue_up_resume(dev); + retval = 0; + goto out; + } + if (dev-power.runtime_status == RPM_RESUMING || dev-power.runtime_status == RPM_SUSPENDING) { DEFINE_WAIT(wait); @@ -591,11 +608,7 @@ static int rpm_resume(struct device *dev /* Carry out an asynchronous or a synchronous resume. */ if (rpmflags RPM_ASYNC) { - dev-power.request = RPM_REQ_RESUME; - if (!dev-power.request_pending) { - dev-power.request_pending = true; - queue_work(pm_wq, dev-power.work); - } + rpm_queue_up_resume(dev); retval = 0; goto out; } @@ -691,6 +704,7 @@ static int rpm_resume(struct device *dev static void pm_runtime_work(struct work_struct *work) { struct device *dev = container_of(work, struct device, power.work); + void (*func)(struct device *) = NULL; enum rpm_request req; spin_lock_irq(dev-power.lock); @@ -715,12 +729,24 @@ static void pm_runtime_work(struct work_ rpm_suspend(dev, RPM_NOWAIT | RPM_AUTO); break; case RPM_REQ_RESUME: - rpm_resume(dev, RPM_NOWAIT); + func = dev-power.func; + if (func) { + dev-power.func = NULL; + pm_runtime_get_noresume(dev); + rpm_resume(dev, 0); + } else { + rpm_resume(dev, RPM_NOWAIT); + } break; } out: spin_unlock_irq(dev-power.lock); + + if (func) { + func(dev); + pm_runtime_put(dev); + } } /** @@ -877,6 +903,48 @@ int __pm_runtime_resume(struct device *d } EXPORT_SYMBOL_GPL(__pm_runtime_resume); +int pm_runtime_get_and_call(struct device *dev, void (*func)(struct device *), +void (*func_async)(struct device *)) +{ + unsigned long flags; + int ret; + + atomic_inc(dev-power.usage_count); + + spin_lock_irqsave(dev-power.lock, flags); + + ret = dev-power.runtime_error; + if (ret) { + func = NULL; + goto out; + } + + if (dev-power.runtime_status != RPM_ACTIVE +dev-power.disable_depth == 0) + func = NULL; Looks the above is a bit odd, and your motivation is to call 'func' for a suspended and runtime-PM enabled device in irq context, isn't it? + + if (!func func_async) { + if (dev-power.func) { + ret = -EAGAIN; + goto out; + } else { + dev-power.func = func_async; + } + } + + rpm_resume(dev, RPM_ASYNC); + + out: + spin_unlock_irqrestore(dev-power.lock, flags); + + if (func) { + func(dev); Maybe the return value should be passed to caller. Also the race between 'func' and its .runtime_resume callback should be stated in comment. In fact, maybe it is better to call 'func' always first, then call ' rpm_resume(dev, RPM_ASYNC);', otherwise the driver may be confused about the order between 'func' and its .runtime_resume callback. + return 1; + } + +
[PATCH v4 2/2] arm/dts: omap4: Add ocp2scp data
Add ocp2scp data node in omap4 device tree file. Acked-by: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/boot/dts/omap4.dtsi |8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 04cbbcb..8a780b2 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -295,5 +295,13 @@ interrupt-parent = gic; ti,hwmods = dmic; }; + + ocp2scp { + compatible = ti,omap-ocp2scp; + #address-cells = 1; + #size-cells = 1; + ranges; + ti,hwmods = ocp2scp_usb_phy; + }; }; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] drivers: bus: add a new driver for omap-ocp2scp
Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of creating all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY is connected to ocp2scp. This also includes device tree support for ocp2scp driver and the documentation with device tree binding information is updated. Acked-by: Felipe Balbi ba...@ti.com Acked-by: Arnd Bergmann a...@arndb.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- .../devicetree/bindings/bus/omap-ocp2scp.txt | 10 +++ drivers/Kconfig|2 + drivers/Makefile |2 + drivers/bus/Kconfig| 15 drivers/bus/Makefile |5 ++ drivers/bus/omap-ocp2scp.c | 88 6 files changed, 122 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt create mode 100644 drivers/bus/Kconfig create mode 100644 drivers/bus/Makefile create mode 100644 drivers/bus/omap-ocp2scp.c diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt new file mode 100644 index 000..d2fe064 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt @@ -0,0 +1,10 @@ +* OMAP OCP2SCP - ocp interface to scp interface + +properties: +- compatible : Should be ti,omap-ocp2scp +- #address-cells, #size-cells : Must be present if the device has sub-nodes +- ranges : the child address space are mapped 1:1 onto the parent address space +- ti,hwmods : must be ocp2scp_usb_phy + +Sub-nodes: +All the devices connected to ocp2scp are described using sub-node to ocp2scp diff --git a/drivers/Kconfig b/drivers/Kconfig index ece958d..324e958 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -2,6 +2,8 @@ menu Device Drivers source drivers/base/Kconfig +source drivers/bus/Kconfig + source drivers/connector/Kconfig source drivers/mtd/Kconfig diff --git a/drivers/Makefile b/drivers/Makefile index 5b42184..f8cdeeb 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -5,6 +5,8 @@ # Rewritten to use lists instead of if-statements. # +obj-y += bus/ + # GPIO must come after pinctrl as gpios may need to mux pins etc obj-y += pinctrl/ obj-y += gpio/ diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig new file mode 100644 index 000..6270415 --- /dev/null +++ b/drivers/bus/Kconfig @@ -0,0 +1,15 @@ +# +# Bus Devices +# + +menu Bus devices + +config OMAP_OCP2SCP + tristate OMAP OCP2SCP DRIVER + help + Driver to enable ocp2scp module which transforms ocp interface + protocol to scp protocol. In OMAP4, USB PHY is connected via + OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via + OCP2SCP. + +endmenu diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile new file mode 100644 index 000..0ec50bc --- /dev/null +++ b/drivers/bus/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the bus drivers. +# + +obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c new file mode 100644 index 000..881d5bb --- /dev/null +++ b/drivers/bus/omap-ocp2scp.c @@ -0,0 +1,88 @@ +/* + * omap-ocp2scp.c - transform ocp interface protocol to scp protocol + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com + * 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. + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * 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. + * + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/err.h +#include linux/pm_runtime.h +#include linux/of.h +#include linux/of_platform.h + +static int ocp2scp_remove_devices(struct device *dev, void *c) +{ + struct platform_device *pdev = to_platform_device(dev); + + platform_device_unregister(pdev); + + return 0; +} + +static int __devinit omap_ocp2scp_probe(struct platform_device *pdev) +{ + int ret; + struct device_node *np = pdev-dev.of_node; + + if (np) { + ret = of_platform_populate(np, NULL, NULL, pdev-dev); + if (ret) { + dev_err(pdev-dev, failed to add resources for ocp2scp child\n); + goto err0; + } + } + pm_runtime_enable(pdev-dev); + + return 0; + +err0: + device_for_each_child(pdev-dev, NULL,
Re: [PATCH] usb/dwc3: Correct DEPCFG for Config Action Modify
On 8/6/2012 5:28 PM, Felipe Balbi wrote: Hi, On Mon, Aug 06, 2012 at 03:33:16PM +0530, Pratyush Anand wrote: From: Pratyush ANAND pratyush.an...@st.com We need to issue DEPCFG (with Config Action Set to Modify) as per specification. Even if we do not respect this , it works in normal cases. But, I have observed one failure in very peculiar situation. If cpu clock is very slow and execution of connection done ISR takes long time (may be around 150 mS), then one will never be able to complete even first setup request. Setup bytes is received, but IN data for get device descriptor is never observed on wire. dwc3 always keeps on waiting for first data transfer complete event. It can easily be reproduced even when working with high cpu clock by deliberately putting delay around 150-200 mS at the start of connection done handler. Current patch corrects the error. Signed-off-by: Pratyush Anand pratyush.an...@st.com this is wrong, you implement it with weird heuristics based on the endpoint state. All you needed to do was pass another argument to the set_ep_config() function like I did... I keep track of dwc3 patches, but somehow I missed your this particular patch :(. --- drivers/usb/dwc3/core.h |1 + drivers/usb/dwc3/gadget.c |9 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 133ed5a..e5b6496 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -489,6 +489,7 @@ enum dwc3_link_state { }; enum dwc3_device_state { + DWC3_ATTACHED_STATE, this is not a USB-defined state, so I don't want to use it. DWC3_DEFAULT_STATE, DWC3_ADDRESS_STATE, DWC3_CONFIGURED_STATE, diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index f6ba644..3926095 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -473,6 +473,9 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, struct dwc3_ep *dep, dep-interval = 1 (desc-bInterval - 1); } + if (dwc-dev_state != DWC3_ATTACHED_STATE) + params.param0 |= DWC3_DEPCFG_ACTION_MODIFY; the modify action is not available on all versions of the core. On older Ok. That I will take care in V2. versions of the core, this was called Ignore Sequence Number bit. And this I have already patched, see below: In fact, I had thought of exactly same implementation, but then did not try because of one doubt. See below. commit 4b345c9a3c7452340fb477868d8db475f05978b1 Author: Felipe Balbi ba...@ti.com Date: Mon Jul 16 14:08:16 2012 +0300 usb: dwc3: gadget: set Ignore Sequence Number bit from ConnectDone Event Databook says we should set Ignore Sequence Number bit from ConnectDone Event, so let's do so. Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 58fdfad..283c0cb 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -431,7 +431,8 @@ static int dwc3_gadget_start_config(struct dwc3 *dwc, struct dwc3_ep *dep) static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, struct dwc3_ep *dep, const struct usb_endpoint_descriptor *desc, - const struct usb_ss_ep_comp_descriptor *comp_desc) + const struct usb_ss_ep_comp_descriptor *comp_desc, + bool ignore) { struct dwc3_gadget_ep_cmd_params params; @@ -441,6 +442,9 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, struct dwc3_ep *dep, | DWC3_DEPCFG_MAX_PACKET_SIZE(usb_endpoint_maxp(desc)) | DWC3_DEPCFG_BURST_SIZE(dep-endpoint.maxburst - 1); + if (ignore) + params.param0 |= DWC3_DEPCFG_IGN_SEQ_NUM; + params.param1 = DWC3_DEPCFG_XFER_COMPLETE_EN | DWC3_DEPCFG_XFER_NOT_READY_EN; @@ -498,7 +502,8 @@ static int dwc3_gadget_set_xfer_resource(struct dwc3 *dwc, struct dwc3_ep *dep) */ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, const struct usb_endpoint_descriptor *desc, - const struct usb_ss_ep_comp_descriptor *comp_desc) + const struct usb_ss_ep_comp_descriptor *comp_desc, + bool ignore) { struct dwc3 *dwc = dep-dwc; u32 reg; @@ -510,7 +515,7 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, return ret; } - ret = dwc3_gadget_set_ep_config(dwc, dep, desc, comp_desc); + ret = dwc3_gadget_set_ep_config(dwc, dep, desc, comp_desc, ignore); if (ret) return ret; @@ -683,7 +688,7 @@ static int dwc3_gadget_ep_enable(struct usb_ep *ep, dev_vdbg(dwc-dev, Enabling %s\n, dep-name); spin_lock_irqsave(dwc-lock, flags); - ret = __dwc3_gadget_ep_enable(dep, desc, ep-comp_desc); + ret = __dwc3_gadget_ep_enable(dep, desc, ep-comp_desc,
Re: [RFC][PATCH 1/4 v3] usb: host: ehci-platform: BUG_ON() to WARN_ON() on probe
On Mon, 6 Aug 2012, Simon Horman wrote: On Sun, Aug 05, 2012 at 06:51:34PM -0700, kuninori.morimoto...@renesas.com wrote: We should avoid using BUG_ON() in drivers. This patch switch to use WARN_ON() from BUG_ON(), and avoid NULL pointer access by new macro. Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com --- v2 - v3 - BUG_ON - WARN_ON drivers/usb/host/ehci-platform.c | 18 ++ 1 files changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c index 4b1d896..db27dfe 100644 --- a/drivers/usb/host/ehci-platform.c +++ b/drivers/usb/host/ehci-platform.c @@ -21,6 +21,8 @@ #include linux/platform_device.h #include linux/usb/ehci_pdriver.h +#define ehci_pdata_get(pdata, x) ((pdata) ? (pdata)-x : 0) + FWIW, I think that an inline function would be a slight improvement over a macro here. Likewise for the 2nd patch of this series. No; we should not have either an inline function or a macro. This computation isn't necessary at all. If you're worried about the possibility that pdata might be NULL, just return -ENODEV from ehci_platform_probe() if it is: int irq; int err = -ENOMEM; - BUG_ON(!dev-dev.platform_data); + if (!dev-dev.platform_data) { + WARN_ON(1); + return -ENODEV; + } if (usb_disabled()) return -ENODEV; But even that may be unnecessary. Simply removing the BUG_ON will accomplish pretty much the same thing; people will realize something is wrong pretty quickly when the computer gets an access violation from trying to dereference a null pointer. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/4 v3] usb: host: ehci-platform: add platform specific power callback
On Sun, 5 Aug 2012 kuninori.morimoto...@renesas.com wrote: This patch enables to call platform specific power callback function. Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com --- v2 - v3 - add power multi functions - call it by macro drivers/usb/host/ehci-platform.c | 40 ++--- include/linux/usb/ehci_pdriver.h |5 2 files changed, 41 insertions(+), 4 deletions(-) diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c index db27dfe..bcdb9e4 100644 --- a/drivers/usb/host/ehci-platform.c +++ b/drivers/usb/host/ehci-platform.c @@ -22,6 +22,8 @@ #include linux/usb/ehci_pdriver.h #define ehci_pdata_get(pdata, x) ((pdata) ? (pdata)-x : 0) +#define ehci_pdata_call(pdata, x, args...) \ + ((!(pdata) || !((pdata)-x)) ? 0 : (pdata)-x(args)) I prefer not to have this. Just do the test before making each call. static int ehci_platform_resume(struct device *dev) { struct usb_hcd *hcd = dev_get_drvdata(dev); + struct usb_ehci_pdata *pdata = dev-platform_data; + struct platform_device *pdev = + container_of(dev, struct platform_device, dev); + + /* power resume if platform supported */ + ehci_pdata_call(pdata, power_resume, pdev); You didn't check the return value. ehci_resume(hcd, false); return 0; --- a/include/linux/usb/ehci_pdriver.h +++ b/include/linux/usb/ehci_pdriver.h @@ -41,6 +41,11 @@ struct usb_ehci_pdata { unsignedbig_endian_mmio:1; unsignedport_power_on:1; unsignedport_power_off:1; + + int (*power_on)(struct platform_device *pdev); + void (*power_off)(struct platform_device *pdev); + void (*power_suspend)(struct platform_device *pdev); + void (*power_resume)(struct platform_device *pdev); Shouldn't power_resume and power_on be the same function always? They do the same thing, even though the initial states of the power supplies might be different. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2]staging usbip Fix typos.
From: Justin P. Mattock justinmatt...@gmail.com Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- NOTE:I see *rc1 in the git web log, so hopefully its ok to send out. The below patch fixes typos found while reading through staging usbip. drivers/staging/usbip/stub_rx.c |2 +- drivers/staging/usbip/vhci_hcd.c |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/usbip/stub_rx.c b/drivers/staging/usbip/stub_rx.c index 1d5b3fc..694cfd7 100644 --- a/drivers/staging/usbip/stub_rx.c +++ b/drivers/staging/usbip/stub_rx.c @@ -155,7 +155,7 @@ static int tweak_set_configuration_cmd(struct urb *urb) * eventually reassigned to the device as far as driver matching * condition is kept. * -* Unfortunatelly, an existing usbip connection will be dropped +* Unfortunately, an existing usbip connection will be dropped * due to this driver unbinding. So, skip here. * A user may need to set a special configuration value before * exporting the device. diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c index 12a9a5f..a5b028d 100644 --- a/drivers/staging/usbip/vhci_hcd.c +++ b/drivers/staging/usbip/vhci_hcd.c @@ -828,11 +828,11 @@ static void vhci_shutdown_connection(struct usbip_device *ud) * disable endpoints. pending urbs are unlinked(dequeued). * * NOTE: After calling rh_port_disconnect(), the USB device drivers of a -* deteched device should release used urbs in a cleanup function(i.e. +* detached device should release used urbs in a cleanup function (i.e. * xxx_disconnect()). Therefore, vhci_hcd does not need to release * pushed urbs and their private data in this function. * -* NOTE: vhci_dequeue() must be considered carefully. When shutdowning +* NOTE: vhci_dequeue() must be considered carefully. When shutting down * a connection, vhci_shutdown_connection() expects vhci_dequeue() * gives back pushed urbs and frees their private data by request of * the cleanup function of a USB driver. When unlinking a urb with an -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb/dwc3: Correct DEPCFG for Config Action Modify
Hi, On Mon, Aug 06, 2012 at 07:22:52PM +0530, Pratyush Anand wrote: commit 4b345c9a3c7452340fb477868d8db475f05978b1 Author: Felipe Balbi ba...@ti.com Date: Mon Jul 16 14:08:16 2012 +0300 usb: dwc3: gadget: set Ignore Sequence Number bit from ConnectDone Event Databook says we should set Ignore Sequence Number bit from ConnectDone Event, so let's do so. Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 58fdfad..283c0cb 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -431,7 +431,8 @@ static int dwc3_gadget_start_config(struct dwc3 *dwc, struct dwc3_ep *dep) static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, struct dwc3_ep *dep, const struct usb_endpoint_descriptor *desc, -const struct usb_ss_ep_comp_descriptor *comp_desc) +const struct usb_ss_ep_comp_descriptor *comp_desc, +bool ignore) { struct dwc3_gadget_ep_cmd_params params; @@ -441,6 +442,9 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, struct dwc3_ep *dep, | DWC3_DEPCFG_MAX_PACKET_SIZE(usb_endpoint_maxp(desc)) | DWC3_DEPCFG_BURST_SIZE(dep-endpoint.maxburst - 1); +if (ignore) +params.param0 |= DWC3_DEPCFG_IGN_SEQ_NUM; + params.param1 = DWC3_DEPCFG_XFER_COMPLETE_EN | DWC3_DEPCFG_XFER_NOT_READY_EN; @@ -498,7 +502,8 @@ static int dwc3_gadget_set_xfer_resource(struct dwc3 *dwc, struct dwc3_ep *dep) */ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, const struct usb_endpoint_descriptor *desc, -const struct usb_ss_ep_comp_descriptor *comp_desc) +const struct usb_ss_ep_comp_descriptor *comp_desc, +bool ignore) { struct dwc3 *dwc = dep-dwc; u32 reg; @@ -510,7 +515,7 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, return ret; } -ret = dwc3_gadget_set_ep_config(dwc, dep, desc, comp_desc); +ret = dwc3_gadget_set_ep_config(dwc, dep, desc, comp_desc, ignore); if (ret) return ret; @@ -683,7 +688,7 @@ static int dwc3_gadget_ep_enable(struct usb_ep *ep, dev_vdbg(dwc-dev, Enabling %s\n, dep-name); spin_lock_irqsave(dwc-lock, flags); -ret = __dwc3_gadget_ep_enable(dep, desc, ep-comp_desc); +ret = __dwc3_gadget_ep_enable(dep, desc, ep-comp_desc, false); I was not sure about it. Databook specifically talks about to use modify on connection done. But, in description of Config Action: Modify, it says that this action is used when modifying an existing endpoint configuration. So, does it not mean that when we issue DEPCFG for the first time for any endpoint, then only we need to set Config Action :Initialize, else Config Action: Modify. My understanding is that this is only needed when we want to change any configuration of any endpoint without disabling it first. And the only case where this happens is with our physical endpoints 0 and 1. I guess it tells us to use Connect Done event for ep0/1 because at that time we already know the speed we're running, so we can reconfigure ep0/1 wMaxPacketSize properly. For all other endpoints, we only change configuration when the endpoint is disabled. See how the framework is designed today: when we change an interface, our endpoints will be disabled by the gadget driver and re-enabled with different descriptors. This means that, except for ep0/1, no endpoint has an existing configuration ;-) -- balbi signature.asc Description: Digital signature
Re: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)
On Sun, 5 Aug 2012, Rafael J. Wysocki wrote: I don't really think we'll need to store func_sync in dev-power. At least I don't see a reason to do that at the moment. You're right; I wasn't thinking straight. I also think that func_sync() would have to be called if runtime PM is disabled for the given device, so that callers don't have to check that condition themselves. Yes. What about the appended experimental patch? For now, I think it would be best to start with a single func argument. If it turns out that anyone really needs to have two separate arguments, the single-argument form can be reimplemented on top of the two-argument form easily enough. @@ -484,6 +484,15 @@ static int rpm_suspend(struct device *de goto out; } +void rpm_queue_up_resume(struct device *dev) +{ + dev-power.request = RPM_REQ_RESUME; + if (!dev-power.request_pending) { + dev-power.request_pending = true; + queue_work(pm_wq, dev-power.work); + } +} + /** * rpm_resume - Carry out runtime resume of given device. * @dev: Device to resume. @@ -524,7 +533,9 @@ static int rpm_resume(struct device *dev * rather than cancelling it now only to restart it again in the near * future. */ - dev-power.request = RPM_REQ_NONE; + if (dev-power.request != RPM_REQ_RESUME || !dev-power.func) + dev-power.request = RPM_REQ_NONE; + if (!dev-power.timer_autosuspends) pm_runtime_deactivate_timer(dev); @@ -533,6 +544,12 @@ static int rpm_resume(struct device *dev goto out; } + if (dev-power.func (rpmflags RPM_ASYNC)) { + rpm_queue_up_resume(dev); + retval = 0; + goto out; + } + if (dev-power.runtime_status == RPM_RESUMING || dev-power.runtime_status == RPM_SUSPENDING) { DEFINE_WAIT(wait); All those changes (and some of the following ones) are symptoms of a basic mistake in this approach. The idea of this new feature is to call func as soon as we know the device is at full power, no matter how it got there. That means we should call it near the end of rpm_resume() (just before the rpm_idle() call), not from within pm_runtime_work(). Doing it this way will be more efficient and (I think) will remove some races. @@ -877,6 +903,48 @@ int __pm_runtime_resume(struct device *d } EXPORT_SYMBOL_GPL(__pm_runtime_resume); +int pm_runtime_get_and_call(struct device *dev, void (*func)(struct device *), + void (*func_async)(struct device *)) +{ + unsigned long flags; + int ret; + + atomic_inc(dev-power.usage_count); + + spin_lock_irqsave(dev-power.lock, flags); + + ret = dev-power.runtime_error; + if (ret) { + func = NULL; + goto out; + } + + if (dev-power.runtime_status != RPM_ACTIVE + dev-power.disable_depth == 0) + func = NULL; + + if (!func func_async) { + if (dev-power.func) { + ret = -EAGAIN; + goto out; + } else { + dev-power.func = func_async; + } + } The logic here is kind of hard to follow. It will be simpler when there's only one func: If the status is RPM_ACTIVE or disable_depth 0 then call func directly. Otherwise save func in dev.power and do an async resume. Some more things: In __pm_runtime_set_status(), if power.func is set then I think we should call it if the new status is ACTIVE. Likwise at the end of rpm_suspend(), if the suspend fails. There should be an invariant: Whenever the status is RPM_ACTIVE, power.func must be NULL. pm_runtime_barrier() should always clear power.func, even if the rpm_resume() call fails. The documentation should explain that in some ways, func is like a workqueue callback routine: Subsystems and drivers have to be careful to make sure that it can't be invoked after the device is unbound. A safe way to do this is to call pm_runtime_barrier() from within the driver's .remove() routine, after making sure that pm_runtime_get_and_call() won't be invoked any more. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Continuous stream of small bulk transfers hangs on OHCI-based system
On Sun, 5 Aug 2012, Tomas Sokorai wrote: Here's after plugging in, but before the hang: - bus pci, device :00:04.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ... And finally the one after the USB is hung: - bus pci, device :00:04.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0020 FNO intrenable 0x805e MIE RHSC UE RD SF WDH There is a notable difference: After the hang, SF is set in intrenable. The driver does this in only a few places, basically when an Endpoint Descriptor is unlinked or when the ZFMicro quirk is set. Do you see any lines in the dmesg log from boot-up about enabled Compaq ZFMicro chipset quirks? The async pseudofile yields nothing, every time . Most likely something is going wrong with the ED unlink. Are you comfortable writing your own debugging patches, or would you prefer me to send you something? The place to check is these lines near the end of ohci_irq() in drivers/usb/host/ohci-hcd.c: if (ohci-ed_rm_list) finish_unlinks (ohci, ohci_frame_no(ohci)); if ((ints OHCI_INTR_SF) != 0 !ohci-ed_rm_list !ohci-ed_to_check ohci-rh_state == OHCI_RH_RUNNING) ohci_writel (ohci, OHCI_INTR_SF, regs-intrdisable); My guess is that ed_rm_list is non-NULL, but for some reason finish_unlinks() doesn't do anything -- in particular, it doesn't clear ed_rm_list. As a result the condition in the if statement fails and OHCI_INTR_SF doesn't get written to regs-intrdisable. If we can verify that, the next step will be to look inside finish_unlinks() to see why it's not doing anything. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Continuous stream of small bulk transfers hangs on OHCI-based system
On Mon, Aug 6, 2012 at 12:24 PM, Alan Stern st...@rowland.harvard.edu wrote: any lines in the dmesg log from boot-up about enabled Compaq ZFMicro chipset quirks? Nope, no quirks message at all in the boot log. Are you comfortable writing your own debugging patches, or would you Quite comfortable, I'll gather more info as soon as I get home from work. My guess is that ed_rm_list is non-NULL, but for some reason finish_unlinks() doesn't do anything -- in particular, it doesn't clear ed_rm_list. As a result the condition in the if statement fails and OHCI_INTR_SF doesn't get written to regs-intrdisable. I'll instrument-ate that area, thanks a lot for your input, Alan. -- Tomas J. Sokorai Sch. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Runtime PM defaults for USB hosts
Hi Alan and Rafael, Is there a reason why runtime PM is disabled by default for PCI USB host controllers? It would really be nice to have this turned on by default at boot, rather than running udev scripts or powertop. Are there PCI USB hosts that can't handle D3? Or something else preventing us from turning runtime PM on by default? Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
usb/host/ohci-tmio.c:105: bad switch statement
Hello there, I just ran the static analyser cppcheck over the source code of the linux kernel version 3.6-rc1. It said linux-3.6-rc1/drivers/usb/host/ohci-tmio.c:105]: (warning) Redundant bitwise operation on pm in switch The source code is switch (ohci-num_ports) { default: dev_err(dev-dev, Unsupported amount of ports: %d\n, ohci-num_ports); case 3: pm |= CCR_PM_USBPW3; case 2: pm |= CCR_PM_USBPW2; case 1: pm |= CCR_PM_USBPW1; } Someone seems to have forgotten some break statements. Suggest code rework. Regards David Binderman -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb/host/ohci-tmio.c:105: bad switch statement
On Mon, 6 Aug 2012, David Binderman wrote: Hello there, I just ran the static analyser cppcheck over the source code of the linux kernel version 3.6-rc1. It said linux-3.6-rc1/drivers/usb/host/ohci-tmio.c:105]: (warning) Redundant bitwise operation on pm in switch The source code is switch (ohci-num_ports) { default: dev_err(dev-dev, Unsupported amount of ports: %d\n, ohci-num_ports); case 3: pm |= CCR_PM_USBPW3; case 2: pm |= CCR_PM_USBPW2; case 1: pm |= CCR_PM_USBPW1; } Someone seems to have forgotten some break statements. Suggest code rework. No, actually it looks like there's a typo in the macro definitions. Starting at line 60: #define CCR_PM_USBPW10x0004 #define CCR_PM_USBPW20x0008 #define CCR_PM_USBPW30x0008 Probably that last one should 0x0010. But I don't know, and most recent person listed as an author is Dmitry. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Runtime PM defaults for USB hosts
On Mon, 6 Aug 2012, Sarah Sharp wrote: Hi Alan and Rafael, Is there a reason why runtime PM is disabled by default for PCI USB host controllers? It would really be nice to have this turned on by default at boot, rather than running udev scripts or powertop. As far as I know, the only reason is that runtime PM is disabled by default for _all_ devices, unless the subsystem or driver specifically enables it. Nobody has submitted a patch enabling runtime PM for PCI USB host controllers. Are there PCI USB hosts that can't handle D3? Or something else preventing us from turning runtime PM on by default? I'm not aware of any such problems. But that doesn't mean they don't exist -- it wouldn't be surprising if you start getting complaints when you enable runtime PM by default. I guess the only way to find out is to try. It's not a hard change; just call pm_runtime_allow(dev-dev) just before the normal return in usb_hcd_pci_probe(). Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)
On Monday, August 06, 2012, Alan Stern wrote: On Sun, 5 Aug 2012, Rafael J. Wysocki wrote: [...] What about the appended experimental patch? For now, I think it would be best to start with a single func argument. If it turns out that anyone really needs to have two separate arguments, the single-argument form can be reimplemented on top of the two-argument form easily enough. All right. @@ -484,6 +484,15 @@ static int rpm_suspend(struct device *de goto out; } +void rpm_queue_up_resume(struct device *dev) +{ + dev-power.request = RPM_REQ_RESUME; + if (!dev-power.request_pending) { + dev-power.request_pending = true; + queue_work(pm_wq, dev-power.work); + } +} + /** * rpm_resume - Carry out runtime resume of given device. * @dev: Device to resume. @@ -524,7 +533,9 @@ static int rpm_resume(struct device *dev * rather than cancelling it now only to restart it again in the near * future. */ - dev-power.request = RPM_REQ_NONE; + if (dev-power.request != RPM_REQ_RESUME || !dev-power.func) + dev-power.request = RPM_REQ_NONE; + if (!dev-power.timer_autosuspends) pm_runtime_deactivate_timer(dev); @@ -533,6 +544,12 @@ static int rpm_resume(struct device *dev goto out; } + if (dev-power.func (rpmflags RPM_ASYNC)) { + rpm_queue_up_resume(dev); + retval = 0; + goto out; + } + if (dev-power.runtime_status == RPM_RESUMING || dev-power.runtime_status == RPM_SUSPENDING) { DEFINE_WAIT(wait); All those changes (and some of the following ones) are symptoms of a basic mistake in this approach. Every time you say something like this (i.e. liks someone who knows better) I kind of feel like being under attach, which I hope is not your intention. Never mind. :-) Those changes are there for different reasons rather unrelated to the way func() is being called, so let me explain. First, rpm_queue_up_resume() is introduced, because the code it contains will have to be called in two different places. At least I don't see how to avoid that without increasing the code complexity too much. Second, the following change in rpm_resume() - dev-power.request = RPM_REQ_NONE; + if (dev-power.request != RPM_REQ_RESUME || !dev-power.func) + dev-power.request = RPM_REQ_NONE; is made to prevent rpm_resume() from canceling the execution of func() queued up by an earlier pm_runtime_get_and_call(). I believe it is necessary. Finally, this change in rpm_resume(): + if (dev-power.func (rpmflags RPM_ASYNC)) { + rpm_queue_up_resume(dev); + retval = 0; + goto out; + } is not strictly necessary if pm_runtime_get_and_call() is modified to run rpm_queue_up_resume() directly, like in the new version of the patch which is appended. This reduces the number of checks overall, so perhaps it's better. The idea of this new feature is to call func as soon as we know the device is at full power, no matter how it got there. Yes, it is so. That means we should call it near the end of rpm_resume() (just before the rpm_idle() call), not from within pm_runtime_work(). Doing it this way will be more efficient and (I think) will remove some races. Except that func() shouldn't be executed under dev-power.lock, which makes it rather difficult to call it from rpm_resume(). Or at least it seems so. Moreover, it should be called after we've changed the status to RPM_ACTIVE _and_ dropped the lock. Besides, I'd like to know what races you're referring to (perhaps you're seeing some more of them than I am). @@ -877,6 +903,48 @@ int __pm_runtime_resume(struct device *d } EXPORT_SYMBOL_GPL(__pm_runtime_resume); +int pm_runtime_get_and_call(struct device *dev, void (*func)(struct device *), +void (*func_async)(struct device *)) +{ + unsigned long flags; + int ret; + + atomic_inc(dev-power.usage_count); + + spin_lock_irqsave(dev-power.lock, flags); + + ret = dev-power.runtime_error; + if (ret) { + func = NULL; + goto out; + } + + if (dev-power.runtime_status != RPM_ACTIVE +dev-power.disable_depth == 0) + func = NULL; + + if (!func func_async) { + if (dev-power.func) { + ret = -EAGAIN; + goto out; + } else { + dev-power.func = func_async; + } + } The logic here is kind of hard to follow. It will be simpler when there's only one func: If the status is RPM_ACTIVE or disable_depth 0 then call func directly. Otherwise save func in dev.power and do an async resume. Yeah. But do not run func() under power.lock, right? Some more things: In
[RFC ebeam PATCH v3 1/2] hid: Blacklist new eBeam classic device
Signed-off-by: Yann Cantin yann.can...@laposte.net --- drivers/hid/hid-core.c |3 +++ drivers/hid/hid-ids.h |3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 60ea284..b1ed8ee 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1908,6 +1908,9 @@ static const struct hid_device_id hid_ignore_list[] = { { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) }, { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) }, { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) }, +#if defined(CONFIG_INPUT_EBEAM_USB) + { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_CLASSIC) }, +#endif { HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, USB_DEVICE_ID_ESSENTIAL_REALITY_P5) }, { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) }, { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) }, diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index 1dcb76f..b985059 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -271,6 +271,9 @@ #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_7349 0x7349 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001 0xa001 +#define USB_VENDOR_ID_EFI 0x2650 +#define USB_DEVICE_ID_EFI_CLASSIC 0x1311 + #define USB_VENDOR_ID_ELECOM 0x056e #define USB_DEVICE_ID_ELECOM_BM084 0x0061 -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC ebeam PATCH v3 0/2]
Hi, New USB input driver for eBeam devices. Currently, only the Luidia eBeam classic projection model is supported. Edge model and a NEC interactive video-projector support planned for the end of the mounth. Patch 1 to blacklist the device for hid generic-usb. Patch 2 is the actual driver. Changes from previous : - switch to div64_s64 for portable 64/64-bits divisions - some cosmetics in device name - unused include and def removed - variables name changes for readability Pending issues : - sysfs custom files : need to pass 13 parameters for calibration : choice is between lots of simply-handled, or few with a big sscanf. - is div64_s64 safe and available on all plateform ? this is the only use of this function i've found in all the kernel tree. The module run fine with a 3.3.6 and a 3.5.0 kernel, both x86_32 and 64. Thanks for your help. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC ebeam PATCH v3 2/2] input: misc: New USB eBeam input driver.
Signed-off-by: Yann Cantin yann.can...@laposte.net --- drivers/input/misc/ebeam.c | 764 1 file changed, 764 insertions(+) create mode 100644 drivers/input/misc/ebeam.c diff --git a/drivers/input/misc/ebeam.c b/drivers/input/misc/ebeam.c new file mode 100644 index 000..54e2cd6 --- /dev/null +++ b/drivers/input/misc/ebeam.c @@ -0,0 +1,764 @@ +/** + * + * eBeam driver + * + * Copyright (C) 2012 Yann Cantin (yann.can...@laposte.net) + * + * 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. + * + * based on + * + * usbtouchscreen.c by Daniel Ritz daniel.r...@gmx.ch + * aiptek.c (sysfs/settings) by Chris Atenasio ch...@crud.net + * Bryan W. Headley bwhead...@earthlink.net + * + */ + +#include linux/kernel.h +#include linux/slab.h +#include linux/math64.h +#include linux/input.h +#include linux/module.h +#include linux/init.h +#include linux/usb.h +#include linux/usb/input.h + +#define DRIVER_AUTHOR Yann Cantin yann.can...@laposte.net +#define DRIVER_DESCUSB eBeam Driver + +/* Common values for eBeam devices */ +#define REPT_SIZE 8 /* packet size*/ +#define MIN_RAW_X 0 /* raw coordinates ranges */ +#define MAX_RAW_X 0x +#define MIN_RAW_Y 0 +#define MAX_RAW_Y 0x + + +#define USB_VENDOR_ID_EFI 0x2650 /* Electronics For Imaging, Inc */ +#define USB_DEVICE_ID_EFI_CLASSIC 0x1311 /* Classic projection La banane */ + +#define EBEAM_BTN_TIP 0x1 /* tip*/ +#define EBEAM_BTN_LIT 0x2 /* little */ +#define EBEAM_BTN_BIG 0x4 /* big*/ + +/* ebeam settings */ +struct ebeam_settings { + int min_x; /* computed coordinates ranges for the input layer */ + int max_x; + int min_y; + int max_y; + + /* H matrix */ + s64 h1; + s64 h2; + s64 h3; + s64 h4; + s64 h5; + s64 h6; + s64 h7; + s64 h8; + s64 h9; +}; + +/* ebeam device */ +struct ebeam_device { + unsigned char*data; + dma_addr_t data_dma; + unsigned char*buffer; + int buf_len; + struct urb *irq; + struct usb_interface *interface; + struct input_dev *input; + char name[128]; + char phys[64]; + void *priv; + + struct ebeam_settingscursetting;/* device's current settings */ + struct ebeam_settingsnewsetting;/* ... and new ones */ + + bool calibrated;/* false : send raw */ + /* true : send computed */ + + u16 raw_x, raw_y; /* raw coordinates */ + int x, y; /* computed coordinates */ + int btn_map; /* internal buttons map */ +}; + +/* device types */ +enum { + DEVTYPE_CLASSIC, +}; + +static const struct usb_device_id ebeam_devices[] = { + {USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_CLASSIC), + .driver_info = DEVTYPE_CLASSIC}, + {} +}; + +static void ebeam_init_settings(struct ebeam_device *ebeam) +{ + ebeam-calibrated = false; + + /* Init (x,y) min/max to raw ones */ + ebeam-cursetting.min_x = ebeam-newsetting.min_x = MIN_RAW_X; + ebeam-cursetting.max_x = ebeam-newsetting.max_x = MAX_RAW_X; + ebeam-cursetting.min_y = ebeam-newsetting.min_y = MIN_RAW_Y; + ebeam-cursetting.max_y = ebeam-newsetting.max_y = MAX_RAW_Y; + + /* Safe values for the H matrix (Identity) */ + ebeam-cursetting.h1 = ebeam-newsetting.h1 = 1; + ebeam-cursetting.h2 = ebeam-newsetting.h2 = 0; + ebeam-cursetting.h3 = ebeam-newsetting.h3 = 0; + + ebeam-cursetting.h4 = ebeam-newsetting.h4 = 0; + ebeam-cursetting.h5 = ebeam-newsetting.h5 = 1; + ebeam-cursetting.h6 = ebeam-newsetting.h6 = 0; + + ebeam-cursetting.h7 = ebeam-newsetting.h7 = 0; + ebeam-cursetting.h8 = ebeam-newsetting.h8 = 0; + ebeam-cursetting.h9 = ebeam-newsetting.h9 = 1; +} + +static void ebeam_setup_input(struct ebeam_device *ebeam, + struct input_dev *input_dev) +{ + unsigned long flags; + + /* Take event lock while modifying parameters */ + spin_lock_irqsave(input_dev-event_lock, flags); + + /* Properties */ + set_bit(INPUT_PROP_DIRECT,
Re: [RFC ebeam PATCH v3 1/2] hid: Blacklist new eBeam classic device
On Mon, Aug 06, 2012 at 11:21:43PM +0200, Yann Cantin wrote: Signed-off-by: Yann Cantin yann.can...@laposte.net --- drivers/hid/hid-core.c |3 +++ drivers/hid/hid-ids.h |3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 60ea284..b1ed8ee 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1908,6 +1908,9 @@ static const struct hid_device_id hid_ignore_list[] = { { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) }, { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) }, { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) }, +#if defined(CONFIG_INPUT_EBEAM_USB) + { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_CLASSIC) }, +#endif Why is this #if in here? Just always do it, how could it not be defined? greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC ebeam PATCH v3 2/2] input: misc: New USB eBeam input driver.
On Mon, Aug 06, 2012 at 11:21:44PM +0200, Yann Cantin wrote: Signed-off-by: Yann Cantin yann.can...@laposte.net --- drivers/input/misc/ebeam.c | 764 1 file changed, 764 insertions(+) create mode 100644 drivers/input/misc/ebeam.c What adds this file to the build? greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC ebeam PATCH v3 0/2]
On Mon, Aug 06, 2012 at 11:21:42PM +0200, Yann Cantin wrote: Hi, New USB input driver for eBeam devices. Currently, only the Luidia eBeam classic projection model is supported. Edge model and a NEC interactive video-projector support planned for the end of the mounth. Patch 1 to blacklist the device for hid generic-usb. Patch 2 is the actual driver. Changes from previous : - switch to div64_s64 for portable 64/64-bits divisions - some cosmetics in device name - unused include and def removed - variables name changes for readability Pending issues : - sysfs custom files : need to pass 13 parameters for calibration : choice is between lots of simply-handled, or few with a big sscanf. sysfs is one value per file, so use lots of different files please. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC ebeam PATCH v3 1/2] hid: Blacklist new eBeam classic device
On Monday, August 06, 2012 02:43:40 PM Greg KH wrote: On Mon, Aug 06, 2012 at 11:21:43PM +0200, Yann Cantin wrote: Signed-off-by: Yann Cantin yann.can...@laposte.net --- drivers/hid/hid-core.c |3 +++ drivers/hid/hid-ids.h |3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 60ea284..b1ed8ee 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1908,6 +1908,9 @@ static const struct hid_device_id hid_ignore_list[] = { { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) }, { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) }, { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) }, +#if defined(CONFIG_INPUT_EBEAM_USB) + { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_CLASSIC) }, +#endif Why is this #if in here? Just always do it, how could it not be defined? User might disable the driver and CONFIG_INPUT_EBEAM_USB will not be set. But I agree, since the device is unusable with generic HID driver there is no point in doing this conditionally. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC ebeam PATCH v3 0/2]
On Monday, August 06, 2012 02:44:23 PM Greg KH wrote: On Mon, Aug 06, 2012 at 11:21:42PM +0200, Yann Cantin wrote: Hi, New USB input driver for eBeam devices. Currently, only the Luidia eBeam classic projection model is supported. Edge model and a NEC interactive video-projector support planned for the end of the mounth. Patch 1 to blacklist the device for hid generic-usb. Patch 2 is the actual driver. Changes from previous : - switch to div64_s64 for portable 64/64-bits divisions Do you really need this much precision? It will be slower on 32 bits.. - some cosmetics in device name - unused include and def removed - variables name changes for readability Pending issues : - sysfs custom files : need to pass 13 parameters for calibration : choice is between lots of simply-handled, or few with a big sscanf. sysfs is one value per file, so use lots of different files please. This is kind of a one value though - it is a transformation matrix. Maybe switch it to binary - 9 s32? -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: host: mips: sead3: Update for EHCI register structure.
From: Steven J. Hill sjh...@mips.com One line fix after 'struct ehci_regs' definition was changed in commit a46af4ebf9ffec35eea0390e89935197b833dc61. Signed-off-by: Steven J. Hill sjh...@mips.com --- drivers/usb/host/ehci-sead3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ehci-sead3.c b/drivers/usb/host/ehci-sead3.c index 58c96bd..0c9e43c 100644 --- a/drivers/usb/host/ehci-sead3.c +++ b/drivers/usb/host/ehci-sead3.c @@ -40,7 +40,7 @@ static int ehci_sead3_setup(struct usb_hcd *hcd) ehci-need_io_watchdog = 0; /* Set burst length to 16 words. */ - ehci_writel(ehci, 0x1010, ehci-regs-reserved[1]); + ehci_writel(ehci, 0x1010, ehci-regs-reserved1[1]); return ret; } -- 1.7.11.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Continuous stream of small bulk transfers hangs on OHCI-based system
On Mon, Aug 6, 2012 at 12:24 PM, Alan Stern st...@rowland.harvard.edu wrote: any lines in the dmesg log from boot-up about enabled Compaq ZFMicro chipset quirks? BTW, I printk'ed the ohci-flags just to be sure what quirks were enabled, and only the do not trust power was enabled. My guess is that ed_rm_list is non-NULL, but for some reason finish_unlinks() doesn't do anything -- in particular, it doesn't clear ed_rm_list. As a result the condition in the if statement fails and OHCI_INTR_SF doesn't get written to regs-intrdisable. Ding, Ding, Ding!, we have a winner :-) I did an ugly check: if (ohci-ed_rm_list) finish_unlinks (ohci, ohci_frame_no(ohci)); if ((ints OHCI_INTR_SF) != 0 !ohci-ed_rm_list !ohci-ed_to_check ohci-rh_state == OHCI_RH_RUNNING) ohci_writel (ohci, OHCI_INTR_SF, regs-intrdisable); else if ((ints OHCI_INTR_SF) != 0 ohci-ed_rm_list !ohci-ed_to_check ohci-rh_state == OHCI_RH_RUNNING) ohci_warn(ohci,SF intr should have been disabled, but ed_rm_list is not empty\n); spin_unlock (ohci-lock); Result: The ed_rm_list definitely stays not null forever after the hang. This non-empty ed_rm_list condition is raised even when not hung at quite a rate, but after its hung, this lovely message does a while(1) dmesg benchmark :-) -- Tomas J. Sokorai Sch. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC ebeam PATCH v3 2/2] input: misc: New USB eBeam input driver.
Hi, Le 06/08/2012 23:43, Greg KH a écrit : On Mon, Aug 06, 2012 at 11:21:44PM +0200, Yann Cantin wrote: Signed-off-by: Yann Cantin yann.can...@laposte.net --- drivers/input/misc/ebeam.c | 764 1 file changed, 764 insertions(+) create mode 100644 drivers/input/misc/ebeam.c What adds this file to the build? Sorry, i don't get it : what do you mean ? greg k-h -- Yann Cantin A4FEB47F -- -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/4 v4] usb: host: ehci-platform: add platform specific .power callback
Hi Alan, Felipe, Greg These are v4 of ehci/ohci-platform patches Kuninori Morimoto (4): usb: host: ehci-platform: BUG_ON() to WARN_ON() on probe usb: host: ohci-platform: BUG_ON() to WARN_ON() on probe usb: host: ehci-platform: add platform specific power callback usb: host: ohci-platform: add platform specific power callback drivers/usb/host/ehci-platform.c | 46 ++--- drivers/usb/host/ohci-platform.c | 42 -- include/linux/usb/ehci_pdriver.h |8 ++ include/linux/usb/ohci_pdriver.h |8 ++ 4 files changed, 97 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 1/4 v4] usb: host: ehci-platform: BUG_ON() to WARN_ON() on probe
usb_ehci_pdata is certainly required in ehci-platform driver. This patch avoids using BUG_ON() from driver, and return from probe with WARN_ON() if pdata was NULL. Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com --- v3 - v4 - remove macro - return probe if pdata was NULL drivers/usb/host/ehci-platform.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c index 4b1d896..a2aaef6 100644 --- a/drivers/usb/host/ehci-platform.c +++ b/drivers/usb/host/ehci-platform.c @@ -82,10 +82,14 @@ static int __devinit ehci_platform_probe(struct platform_device *dev) { struct usb_hcd *hcd; struct resource *res_mem; + struct usb_ehci_pdata *pdata = dev-dev.platform_data; int irq; int err = -ENOMEM; - BUG_ON(!dev-dev.platform_data); + if (!pdata) { + WARN_ON(1); + return -ENODEV; + } if (usb_disabled()) return -ENODEV; -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 2/4 v4] usb: host: ohci-platform: BUG_ON() to WARN_ON() on probe
usb_ohci_pdata is certainly required in ohci-platform driver. This patch avoids using BUG_ON() from driver, and return from probe with WARN_ON() if pdata was NULL. Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com --- v3 - v4 - remove macro - return probe if pdata was NULL drivers/usb/host/ohci-platform.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c index 670c705..4c886f9 100644 --- a/drivers/usb/host/ohci-platform.c +++ b/drivers/usb/host/ohci-platform.c @@ -83,10 +83,14 @@ static int __devinit ohci_platform_probe(struct platform_device *dev) { struct usb_hcd *hcd; struct resource *res_mem; + struct usb_ohci_pdata *pdata = dev-dev.platform_data; int irq; int err = -ENOMEM; - BUG_ON(!dev-dev.platform_data); + if (!pdata) { + WARN_ON(1); + return -ENODEV; + } if (usb_disabled()) return -ENODEV; -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 3/4] usb: host: ehci-platform: add platform specific power callback
This patch enables to call platform specific power callback function. Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com --- v3 - v4 - remove macro - remove .power_suspend - check return value on resume drivers/usb/host/ehci-platform.c | 40 +++-- include/linux/usb/ehci_pdriver.h |8 +++ 2 files changed, 45 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c index a2aaef6..91acdde 100644 --- a/drivers/usb/host/ehci-platform.c +++ b/drivers/usb/host/ehci-platform.c @@ -105,10 +105,18 @@ static int __devinit ehci_platform_probe(struct platform_device *dev) return -ENXIO; } + if (pdata-power_on) { + err = pdata-power_on(dev); + if (err 0) + return err; + } + hcd = usb_create_hcd(ehci_platform_hc_driver, dev-dev, dev_name(dev-dev)); - if (!hcd) - return -ENOMEM; + if (!hcd) { + err = -ENOMEM; + goto err_power; + } hcd-rsrc_start = res_mem-start; hcd-rsrc_len = resource_size(res_mem); @@ -136,12 +144,17 @@ err_release_region: release_mem_region(hcd-rsrc_start, hcd-rsrc_len); err_put_hcd: usb_put_hcd(hcd); +err_power: + if (pdata-power_off) + pdata-power_off(dev); + return err; } static int __devexit ehci_platform_remove(struct platform_device *dev) { struct usb_hcd *hcd = platform_get_drvdata(dev); + struct usb_ehci_pdata *pdata = dev-dev.platform_data; usb_remove_hcd(hcd); iounmap(hcd-regs); @@ -149,6 +162,9 @@ static int __devexit ehci_platform_remove(struct platform_device *dev) usb_put_hcd(hcd); platform_set_drvdata(dev, NULL); + if (pdata-power_off) + pdata-power_off(dev); + return 0; } @@ -157,14 +173,32 @@ static int __devexit ehci_platform_remove(struct platform_device *dev) static int ehci_platform_suspend(struct device *dev) { struct usb_hcd *hcd = dev_get_drvdata(dev); + struct usb_ehci_pdata *pdata = dev-platform_data; + struct platform_device *pdev = + container_of(dev, struct platform_device, dev); bool do_wakeup = device_may_wakeup(dev); + int ret; + + ret = ehci_suspend(hcd, do_wakeup); - return ehci_suspend(hcd, do_wakeup); + if (pdata-power_suspend) + pdata-power_suspend(pdev); + + return ret; } static int ehci_platform_resume(struct device *dev) { struct usb_hcd *hcd = dev_get_drvdata(dev); + struct usb_ehci_pdata *pdata = dev-platform_data; + struct platform_device *pdev = + container_of(dev, struct platform_device, dev); + + if (pdata-power_on) { + int err = pdata-power_on(pdev); + if (err 0) + return err; + } ehci_resume(hcd, false); return 0; diff --git a/include/linux/usb/ehci_pdriver.h b/include/linux/usb/ehci_pdriver.h index 1894f42..c9d09f8 100644 --- a/include/linux/usb/ehci_pdriver.h +++ b/include/linux/usb/ehci_pdriver.h @@ -41,6 +41,14 @@ struct usb_ehci_pdata { unsignedbig_endian_mmio:1; unsignedport_power_on:1; unsignedport_power_off:1; + + /* Turn on all power and clocks */ + int (*power_on)(struct platform_device *pdev); + /* Turn off all power and clocks */ + void (*power_off)(struct platform_device *pdev); + /* Turn on only VBUS suspend power and hotplug detection, +* turn off everything else */ + void (*power_suspend)(struct platform_device *pdev); }; #endif /* __USB_CORE_EHCI_PDRIVER_H */ -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 4/4] usb: host: ohci-platform: add platform specific power callback
This patch enables to call platform specific power callback function. Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com --- v3 - v4 - remove macro - remove .power_suspen - check return value on resume drivers/usb/host/ohci-platform.c | 36 ++-- include/linux/usb/ohci_pdriver.h |8 2 files changed, 42 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c index 4c886f9..10d85b9 100644 --- a/drivers/usb/host/ohci-platform.c +++ b/drivers/usb/host/ohci-platform.c @@ -107,10 +107,18 @@ static int __devinit ohci_platform_probe(struct platform_device *dev) return -ENXIO; } + if (pdata-power_on) { + err = pdata-power_on(dev); + if (err 0) + return err; + } + hcd = usb_create_hcd(ohci_platform_hc_driver, dev-dev, dev_name(dev-dev)); - if (!hcd) - return -ENOMEM; + if (!hcd) { + err = -ENOMEM; + goto err_power; + } hcd-rsrc_start = res_mem-start; hcd-rsrc_len = resource_size(res_mem); @@ -138,12 +146,17 @@ err_release_region: release_mem_region(hcd-rsrc_start, hcd-rsrc_len); err_put_hcd: usb_put_hcd(hcd); +err_power: + if (pdata-power_off) + pdata-power_off(dev); + return err; } static int __devexit ohci_platform_remove(struct platform_device *dev) { struct usb_hcd *hcd = platform_get_drvdata(dev); + struct usb_ohci_pdata *pdata = dev-dev.platform_data; usb_remove_hcd(hcd); iounmap(hcd-regs); @@ -151,6 +164,9 @@ static int __devexit ohci_platform_remove(struct platform_device *dev) usb_put_hcd(hcd); platform_set_drvdata(dev, NULL); + if (pdata-power_off) + pdata-power_off(dev); + return 0; } @@ -158,12 +174,28 @@ static int __devexit ohci_platform_remove(struct platform_device *dev) static int ohci_platform_suspend(struct device *dev) { + struct usb_ohci_pdata *pdata = dev-platform_data; + struct platform_device *pdev = + container_of(dev, struct platform_device, dev); + + if (pdata-power_suspend) + pdata-power_suspend(pdev); + return 0; } static int ohci_platform_resume(struct device *dev) { struct usb_hcd *hcd = dev_get_drvdata(dev); + struct usb_ohci_pdata *pdata = dev-platform_data; + struct platform_device *pdev = + container_of(dev, struct platform_device, dev); + + if (pdata-power_on) { + int err = pdata-power_on(pdev); + if (err 0) + return err; + } ohci_finish_controller_resume(hcd); return 0; diff --git a/include/linux/usb/ohci_pdriver.h b/include/linux/usb/ohci_pdriver.h index 2808f2a..74e7755 100644 --- a/include/linux/usb/ohci_pdriver.h +++ b/include/linux/usb/ohci_pdriver.h @@ -33,6 +33,14 @@ struct usb_ohci_pdata { unsignedbig_endian_desc:1; unsignedbig_endian_mmio:1; unsignedno_big_frame_no:1; + + /* Turn on all power and clocks */ + int (*power_on)(struct platform_device *pdev); + /* Turn off all power and clocks */ + void (*power_off)(struct platform_device *pdev); + /* Turn on only VBUS suspend power and hotplug detection, +* turn off everything else */ + void (*power_suspend)(struct platform_device *pdev); }; #endif /* __USB_CORE_OHCI_PDRIVER_H */ -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC ebeam PATCH v3 1/2] hid: Blacklist new eBeam classic device
Le 07/08/2012 00:07, Dmitry Torokhov a écrit : On Monday, August 06, 2012 02:43:40 PM Greg KH wrote: On Mon, Aug 06, 2012 at 11:21:43PM +0200, Yann Cantin wrote: Signed-off-by: Yann Cantin yann.can...@laposte.net --- drivers/hid/hid-core.c |3 +++ drivers/hid/hid-ids.h |3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 60ea284..b1ed8ee 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1908,6 +1908,9 @@ static const struct hid_device_id hid_ignore_list[] = { { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) }, { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) }, { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) }, +#if defined(CONFIG_INPUT_EBEAM_USB) + { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_CLASSIC) }, +#endif Why is this #if in here? Just always do it, how could it not be defined? User might disable the driver and CONFIG_INPUT_EBEAM_USB will not be set. But I agree, since the device is unusable with generic HID driver there is no point in doing this conditionally. There's a closed-source user-space stack (libusb based daemon + xorg driver + wine apps) provided for some distro (Ubuntu 10.04, works on mandriva 2010, maybe others but break on recent xorg). I don't know exactly what to do : i don't want to break hypothetical support, even proprietary. Leaving the choice at kernel compile time seems to be safer, no ? -- Yann Cantin A4FEB47F -- -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)
On Mon, Aug 6, 2012 at 10:47 PM, Alan Stern st...@rowland.harvard.edu wrote: No, no, you have completely misunderstood the whole point of this change. Sorry, you are right. And the callback should be renamed as '.runtime_post_resume', which should do something I/O related in theory just after device becomes active. The idea is for func to be called at a time when it is known that the device is at full power. That means it _has_ to be called after the runtime_resume callback returns. Yes, I agree, but I don't think it may make .runtime_post_resume not doable, do I? Also, func should not be stored in dev_pm_ops because it won't be a read-only value. Sorry, could you explain it in detail that why the 'func' has to switch to multiple functions dynamically? I understand one function is enough and sometimes it can be bypassed with one flag(such as, ignore_post_resume is introduced in dev_pm_info) set. Also, the driver can store the device specific states in its own device instance to deal with different situations in the callback. If the idea is doable, we can save one pointer in 'struct device', since the 'func' may not be used by more than 90% devices, also have document benefit, even may simplify implementation of the mechanism. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC ebeam PATCH v3 2/2] input: misc: New USB eBeam input driver.
On Tue, Aug 07, 2012 at 02:56:40AM +0200, Yann Cantin wrote: Hi, Le 06/08/2012 23:43, Greg KH a écrit : On Mon, Aug 06, 2012 at 11:21:44PM +0200, Yann Cantin wrote: Signed-off-by: Yann Cantin yann.can...@laposte.net --- drivers/input/misc/ebeam.c | 764 1 file changed, 764 insertions(+) create mode 100644 drivers/input/misc/ebeam.c What adds this file to the build? Sorry, i don't get it : what do you mean ? Greg meant that you forgot to include Makefile and Kconfig changes with this patch. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC ebeam PATCH v3 0/2]
Le 07/08/2012 00:09, Dmitry Torokhov a écrit : On Monday, August 06, 2012 02:44:23 PM Greg KH wrote: On Mon, Aug 06, 2012 at 11:21:42PM +0200, Yann Cantin wrote: Hi, New USB input driver for eBeam devices. Currently, only the Luidia eBeam classic projection model is supported. Edge model and a NEC interactive video-projector support planned for the end of the mounth. Patch 1 to blacklist the device for hid generic-usb. Patch 2 is the actual driver. Changes from previous : - switch to div64_s64 for portable 64/64-bits divisions Do you really need this much precision? It will be slower on 32 bits.. Yes. I can give the details if you want (homography computation without floating point maths). - some cosmetics in device name - unused include and def removed - variables name changes for readability Pending issues : - sysfs custom files : need to pass 13 parameters for calibration : choice is between lots of simply-handled, or few with a big sscanf. sysfs is one value per file, so use lots of different files please. This is kind of a one value though - it is a transformation matrix. Maybe switch it to binary - 9 s32? Right, but this somehow obfuscate the api. In the other hand, i doubt there will be lots of calibration tools other that mine. Is there any drawback for numerous sysfs custom files ? -- Yann Cantin A4FEB47F -- -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC ebeam PATCH v3 1/2] hid: Blacklist new eBeam classic device
On Tue, Aug 07, 2012 at 03:21:45AM +0200, Yann Cantin wrote: Le 07/08/2012 00:07, Dmitry Torokhov a écrit : On Monday, August 06, 2012 02:43:40 PM Greg KH wrote: On Mon, Aug 06, 2012 at 11:21:43PM +0200, Yann Cantin wrote: Signed-off-by: Yann Cantin yann.can...@laposte.net --- drivers/hid/hid-core.c |3 +++ drivers/hid/hid-ids.h |3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 60ea284..b1ed8ee 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1908,6 +1908,9 @@ static const struct hid_device_id hid_ignore_list[] = { { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) }, { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) }, { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) }, +#if defined(CONFIG_INPUT_EBEAM_USB) + { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_CLASSIC) }, +#endif Why is this #if in here? Just always do it, how could it not be defined? User might disable the driver and CONFIG_INPUT_EBEAM_USB will not be set. But I agree, since the device is unusable with generic HID driver there is no point in doing this conditionally. There's a closed-source user-space stack (libusb based daemon + xorg driver + wine apps) provided for some distro (Ubuntu 10.04, works on mandriva 2010, maybe others but break on recent xorg). I don't know exactly what to do : i don't want to break hypothetical support, even proprietary. Leaving the choice at kernel compile time seems to be safer, no ? If they are using libusb that means that they use userspace solution and do not require HID or any other in-kernel driver. They should still be able to claim the port even if your driver is in use. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Kernel panic when try s3c-hsotg.c with kernel 3.5
2012/8/6 Lukasz Majewski l.majew...@samsung.com: Hi, Hi, On Mon, Aug 06, 2012 at 06:12:05PM +0800, Peiyong Feng wrote: I got a kernel panic when try hsotg of ok6410 which is based on s3c6410: As you said, you are using the ok6410. And it is based on the s3c6410 CPU. S3C6410 is a single core CPU. I assume that ok6410 is also single core? yes cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters Unable to handle kernel NULL pointer dereference at virtual address 0100 pgd = c0004000 [0100] *pgd= Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0Not tainted (3.5.0 #9) PC is at s3c_hsotg_handle_outdone+0x44/0x158 LR is at s3c_hsotg_irq+0x75c/0x804 pc : [c023e7fc]lr : [c024061c]psr: 6193 sp : c782fd20 ip : 0029 fp : c13a1460 r10: r9 : 0008 r8 : 00d0 r7 : c13a1400 r6 : 0002 r5 : r4 : 00060002 r3 : 00d0 r2 : r1 : 00080200 r0 : c13a1400 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 00c5387d Table: 50004008 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc782e268) Stack: (0xc782fd20 to 0xc783) fd20: c13a1460 c0200f64 00060002 0002 c13a1400 0010 fd40: c024061c 00060002 0002 0008 c782fda0 c139a5c0 fd60: c139a5c0 005a c04cc52c c04cc594 c04ea5fe c00565c0 fd80: c04cc52c c139a5c0 c04cc57c c04eb328 fda0: c04cc55c c04eb324 c04c44c0 c0056768 c04cc52c c04cc57c c0058d64 fdc0: 005a c04d7dd8 c005617c 005a c000efbc c04eb350 0001 fde0: c782fe08 c000853c c036c540 6013 c782fe3c c04cc57c c04cc55c fe00: 6013 c000dd80 c04cc57c c782c000 0001 6013 c04cc52c fe20: c139a5c0 005a c04cc57c c04cc55c 6013 c04c44c0 f601 c782fe50 fe40: c036c53c c036c540 6013 c023fec0 c00574c8 c008b2dc fe60: c023fec0 c13a1400 005a c139a5c0 c04cc52c c0057960 fe80: 005a c13a1400 c04c44b8 c051d238 c049b0ec c03688fc fea0: c7853e60 c13a1400 c7804f80 c04c44f4 6013 c7855a80 fec0: c04e1bb4 c04c44c0 c04c44c0 c04e1bb4 c04e1bb4 c051d238 c049b0ec fee0: c04eb040 c020588c c04c44c0 c0204524 c04c44c0 c04c44f4 c04e1bb4 c02046ac ff00: c13a01e0 c0204738 c782ff18 c04e1bb4 c0202e30 c7803878 c7823700 ff20: c04dd1d0 c040b8d4 c04e1bb4 c04e1bb4 c04dd1d0 c0203600 c040b8d4 c01b8568 ff40: c04e1bb4 0007 c04eb040 c782e000 c04a65e0 c0204ce8 ff60: c04a65d4 0007 c04eb040 c782e000 c0008628 c04c7ea0 ff80: 009c c0625cf9 c0037178 0006 0006 c0461b84 c042cee8 ffa0: c04c7ea0 c04abdd4 c04a65d4 0007 c04eb040 009c c04841b0 c04a65e0 ffc0: c048430c 0006 0006 c04841b0 c048421c ffe0: c000f08c 0013 c000f08c [c023e7fc] (s3c_hsotg_handle_outdone+0x44/0x158) from [c024061c] (s3c_hsotg_irq+0x75c/0x804) [c024061c] (s3c_hsotg_irq+0x75c/0x804) from [c00565c0] (handle_irq_event_percpu+0x50/0x1bc) [c00565c0] (handle_irq_event_percpu+0x50/0x1bc) from [c0056768] (handle_irq_event+0x3c/0x5c) [c0056768] (handle_irq_event+0x3c/0x5c) from [c0058d64] (handle_level_irq+0x8c/0x118) [c0058d64] (handle_level_irq+0x8c/0x118) from [c005617c] (generic_handle_irq+0x38/0x44) [c005617c] (generic_handle_irq+0x38/0x44) from [c000efbc] (handle_IRQ+0x30/0x84) [c000efbc] (handle_IRQ+0x30/0x84) from [c000853c] (vic_handle_irq+0x68/0xa8) [c000853c] (vic_handle_irq+0x68/0xa8) from [c000dd80] (__irq_svc+0x40/0x60) Exception stack(0xc782fe08 to 0xc782fe50) fe00: c04cc57c c782c000 0001 6013 c04cc52c fe20: c139a5c0 005a c04cc57c c04cc55c 6013 c04c44c0 f601 c782fe50 fe40: c036c53c c036c540 6013 [c000dd80] (__irq_svc+0x40/0x60) from [c036c540] (_raw_spin_unlock_irqrestore+0x10/0x14) [c036c540] (_raw_spin_unlock_irqrestore+0x10/0x14) from [c00574c8] (__setup_irq+0x178/0x3f8) [c00574c8] (__setup_irq+0x178/0x3f8) from [c0057960] (request_threaded_irq+0xc4/0x12c) [c0057960] (request_threaded_irq+0xc4/0x12c) from [c03688fc] (s3c_hsotg_probe+0x14c/0x700) [c03688fc] (s3c_hsotg_probe+0x14c/0x700) from [c020588c] (platform_drv_probe+0x18/0x1c) [c020588c] (platform_drv_probe+0x18/0x1c) from [c0204524] (driver_probe_device+0x78/0x200) [c0204524] (driver_probe_device+0x78/0x200) from [c0204738] (__driver_attach+0x8c/0x90) [c0204738] (__driver_attach+0x8c/0x90) from [c0202e30] (bus_for_each_dev+0x60/0x8c) [c0202e30] (bus_for_each_dev+0x60/0x8c) from [c0203600] (bus_add_driver+0xac/0x250) [c0203600] (bus_add_driver+0xac/0x250) from [c0204ce8] (driver_register+0x58/0x130) [c0204ce8] (driver_register+0x58/0x130) from [c0008628]
Re: [PATCH 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
Hi, On Mon, Aug 6, 2012 at 3:21 PM, Praveen Paneri p.pan...@samsung.com wrote: Hi, On Mon, Aug 6, 2012 at 2:53 PM, Heiko Stübner he...@sntech.de wrote: Am Montag, 6. August 2012, 10:23:52 schrieb Kyungmin Park: Hi Praveen, On 8/6/12, Praveen Paneri p.pan...@samsung.com wrote: Hi Heiko, On Mon, Aug 6, 2012 at 3:24 AM, Heiko Stübner he...@sntech.de wrote: Hi Praveen, Am Mittwoch, 1. August 2012, 15:05:47 schrieb Praveen Paneri: This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. Looks cool. Thanks From what I've seen the phy controllers on newer Samsung SoCs are still somewhat similar to the one on my s3c2416/2450 machines. So hopefully at some point after the driver has settled, I'll find the time to add support for these to the phy driver. Yes! that's great. Out of curiosity, what does the sec in sec_usbphy for? Its Samsung Electronics Co. :) I'm also prefer to use 'samsung' or 'exynos'. Since I didn't see the 'sec' prefix for samsung drivers. I'd second that. All new generic samsung drivers look like this (i.e. gpio- samsung, pwm-samsung). On the second thought I am thinking 'sec' is shorter and cooler. I know that it has not been used anywhere else but there is always a first time :-P The shorter string helps in writing the code; especially when we have 80 character restriction. If you go through this driver itself you will realize this. Also there was a suggestion some time back to use 'sec' instead of 'samsung'. This is just my view about it. Please comment. Praveen Just checked the datasheets again. This general phy type is used in some form down to the S3C2443, so I'd prefer something with samsung in the name :-) Yes! That makes sense. I will change the name to samsung_usbphy Praveen Heiko Thank you, Kyungmin Park Praveen Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de Heiko --- .../devicetree/bindings/usb/samsung-usbphy.txt |9 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/sec_usbphy.c | 354 drivers/usb/phy/sec_usbphy.h 48 +++ include/linux/platform_data/s3c-hsotg.h|5 + 6 files changed, 425 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/sec_usbphy.c create mode 100644 drivers/usb/phy/sec_usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..fefd9c8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,9 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index e7cf84f..abbebe2 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -15,3 +15,11 @@ config USB_ISP1301 To compile this driver as a module, choose M here: the module will be called isp1301. + +config SEC_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index eca095b..6bb66f0 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -5,3 +5,4 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG obj-$(CONFIG_USB_ISP1301)+= isp1301.o +obj-$(CONFIG_SEC_USBPHY) += sec_usbphy.o diff --git a/drivers/usb/phy/sec_usbphy.c b/drivers/usb/phy/sec_usbphy.c new file mode 100644 index 000..33119eb --- /dev/null +++ b/drivers/usb/phy/sec_usbphy.c @@ -0,0 +1,354 @@ +/* linux/drivers/usb/phy/sec_usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be
[PATCH V2] usb/dwc3: Send DEPCFG with Config Action: Modify after conndone
From: Pratyush ANAND pratyush.an...@st.com For core 1.94A and latter, specification says to issue DEPCFG with Config Action: Modify for physical endpoint 0/1. Signed-off-by: Pratyush Anand pratyush.an...@st.com --- drivers/usb/dwc3/gadget.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 0ead4cd..e582a10 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -442,8 +442,12 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, struct dwc3_ep *dep, | DWC3_DEPCFG_MAX_PACKET_SIZE(usb_endpoint_maxp(desc)) | DWC3_DEPCFG_BURST_SIZE(dep-endpoint.maxburst); - if (ignore) - params.param0 |= DWC3_DEPCFG_IGN_SEQ_NUM; + if (ignore) { + if (dwc-revision DWC3_REVISION_194A) + params.param0 |= DWC3_DEPCFG_IGN_SEQ_NUM; + else + params.param0 |= DWC3_DEPCFG_ACTION_MODIFY; + } params.param1 = DWC3_DEPCFG_XFER_COMPLETE_EN | DWC3_DEPCFG_XFER_NOT_READY_EN; -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
On 8/7/12, Praveen Paneri p.pan...@samsung.com wrote: Hi, On Mon, Aug 6, 2012 at 3:21 PM, Praveen Paneri p.pan...@samsung.com wrote: Hi, On Mon, Aug 6, 2012 at 2:53 PM, Heiko Stübner he...@sntech.de wrote: Am Montag, 6. August 2012, 10:23:52 schrieb Kyungmin Park: Hi Praveen, On 8/6/12, Praveen Paneri p.pan...@samsung.com wrote: Hi Heiko, On Mon, Aug 6, 2012 at 3:24 AM, Heiko Stübner he...@sntech.de wrote: Hi Praveen, Am Mittwoch, 1. August 2012, 15:05:47 schrieb Praveen Paneri: This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. Looks cool. Thanks From what I've seen the phy controllers on newer Samsung SoCs are still somewhat similar to the one on my s3c2416/2450 machines. So hopefully at some point after the driver has settled, I'll find the time to add support for these to the phy driver. Yes! that's great. Out of curiosity, what does the sec in sec_usbphy for? Its Samsung Electronics Co. :) I'm also prefer to use 'samsung' or 'exynos'. Since I didn't see the 'sec' prefix for samsung drivers. I'd second that. All new generic samsung drivers look like this (i.e. gpio- samsung, pwm-samsung). On the second thought I am thinking 'sec' is shorter and cooler. I know that it has not I also think about it. but most of people think 'sec' is Securities and Exchange Commission or security instead of Samsung Electronics. Ans TLA is avoid if possible. Thank you, Kyungmin Park been used anywhere else but there is always a first time :-P The shorter string helps in writing the code; especially when we have 80 character restriction. If you go through this driver itself you will realize this. Also there was a suggestion some time back to use 'sec' instead of 'samsung'. This is just my view about it. Please comment. Praveen Just checked the datasheets again. This general phy type is used in some form down to the S3C2443, so I'd prefer something with samsung in the name :-) Yes! That makes sense. I will change the name to samsung_usbphy Praveen Heiko Thank you, Kyungmin Park Praveen Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de Heiko --- .../devicetree/bindings/usb/samsung-usbphy.txt |9 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/sec_usbphy.c | 354 drivers/usb/phy/sec_usbphy.h 48 +++ include/linux/platform_data/s3c-hsotg.h|5 + 6 files changed, 425 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/sec_usbphy.c create mode 100644 drivers/usb/phy/sec_usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..fefd9c8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,9 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index e7cf84f..abbebe2 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -15,3 +15,11 @@ config USB_ISP1301 To compile this driver as a module, choose M here: the module will be called isp1301. + +config SEC_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index eca095b..6bb66f0 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -5,3 +5,4 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG obj-$(CONFIG_USB_ISP1301)+= isp1301.o +obj-$(CONFIG_SEC_USBPHY) += sec_usbphy.o diff --git a/drivers/usb/phy/sec_usbphy.c b/drivers/usb/phy/sec_usbphy.c new file mode 100644 index 000..33119eb --- /dev/null +++ b/drivers/usb/phy/sec_usbphy.c @@ -0,0 +1,354 @@ +/* linux/drivers/usb/phy/sec_usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG
Re: [PATCH] ARM: EXYNOS: Add USB HSIC device
Hi, Now another person try to use drivers/usb/phy for it. usb: phy: samsung: Introducing usb phy driver for hsotg Can you use it instead of previous one? Thank you, Kyungmin Park On 8/6/12, Dongjin Kim tobet...@gmail.com wrote: This patch support to control USB HSIC of EXYNOS4, edited based on Samsung's GT-i9100 ICS Opensource Update7. Change-Id: Ifba33c6a5166abf3644794eee6abe528bd71f521 Signed-off-by: Dongjin Kim dongjin@agreeyamobility.net --- arch/arm/mach-exynos/common.c|5 + arch/arm/mach-exynos/include/mach/regs-pmu.h | 12 + arch/arm/mach-exynos/include/mach/regs-usb-phy.h | 97 + arch/arm/mach-exynos/setup-usb-phy.c | 493 -- drivers/usb/host/Kconfig | 14 + 5 files changed, 501 insertions(+), 120 deletions(-) diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c index 4eb39cd..94d58af 100644 --- a/arch/arm/mach-exynos/common.c +++ b/arch/arm/mach-exynos/common.c @@ -179,6 +179,11 @@ static struct map_desc exynos4_iodesc[] __initdata = { .length = SZ_4K, .type = MT_DEVICE, }, { + .virtual= (unsigned long)S5P_VA_GPIO2, + .pfn= __phys_to_pfn(EXYNOS4_PA_GPIO2), + .length = SZ_4K, + .type = MT_DEVICE, + }, { .virtual= (unsigned long)S5P_VA_DMC0, .pfn= __phys_to_pfn(EXYNOS4_PA_DMC0), .length = SZ_64K, diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h b/arch/arm/mach-exynos/include/mach/regs-pmu.h index 0bb21e2..d98c2fe 100644 --- a/arch/arm/mach-exynos/include/mach/regs-pmu.h +++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h @@ -185,6 +185,15 @@ #define S5P_PMU_LCD1_CONFS5P_PMUREG(0x3CA0) /* Only for EXYNOS4x12 */ +#define S5P_USB_PHY_CONTROL S5P_PMUREG(0x0704) +#define S5P_USB_PHY_ENABLE (0x1 0) + +#define S5P_HSIC_1_PHY_CONTROL S5P_PMUREG(0x0708) +#define S5P_HSIC_1_PHY_ENABLE(0x1 0) + +#define S5P_HSIC_2_PHY_CONTROL S5P_PMUREG(0x070C) +#define S5P_HSIC_2_PHY_ENABLE(0x1 0) + #define S5P_ISP_ARM_LOWPWR S5P_PMUREG(0x1050) #define S5P_DIS_IRQ_ISP_ARM_LOCAL_LOWPWR S5P_PMUREG(0x1054) #define S5P_DIS_IRQ_ISP_ARM_CENTRAL_LOWPWR S5P_PMUREG(0x1058) @@ -242,6 +251,9 @@ #define EXYNOS5_SYS_WDTRESET (1 20) +#define EXYNOS5_USBDEV_PHY_CONTROL S5P_PMUREG(0x0704) +#define EXYNOS5_USBHOST_PHY_CONTROL S5P_PMUREG(0x0708) + #define EXYNOS5_ARM_CORE0_SYS_PWR_REG S5P_PMUREG(0x1000) #define EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG S5P_PMUREG(0x1004) #define EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG S5P_PMUREG(0x1008) diff --git a/arch/arm/mach-exynos/include/mach/regs-usb-phy.h b/arch/arm/mach-exynos/include/mach/regs-usb-phy.h index 0727773..79021a0 100644 --- a/arch/arm/mach-exynos/include/mach/regs-usb-phy.h +++ b/arch/arm/mach-exynos/include/mach/regs-usb-phy.h @@ -43,6 +43,43 @@ #define EXYNOS4210_CLKSEL_12M(0x2 0) #define EXYNOS4210_CLKSEL_24M(0x3 0) +#define EXYNOS4210_HSIC1_NORMAL_MASK(0x3 11) +#define EXYNOS4210_HSIC1_SLEEP (1 12) +#define EXYNOS4210_HSIC1_FORCE_SUSPEND (1 11) +#define EXYNOS4210_HSIC0_NORMAL_MASK(0x3 9) +#define EXYNOS4210_HSIC0_SLEEP (1 10) +#define EXYNOS4210_HSIC0_FORCE_SUSPEND (1 9) + +#define EXYNOS4210_HOST_LINK_PORT_SWRST_MASK(0xf 6) +#define EXYNOS4210_HOST_LINK_PORT2_SWRST(1 9) +#define EXYNOS4210_HOST_LINK_PORT1_SWRST(1 8) +#define EXYNOS4210_HOST_LINK_PORT0_SWRST(1 7) +#define EXYNOS4210_HOST_LINK_ALL_SWRST (1 6) +#define EXYNOS4210_PHY1_SWRST_MASK (0x7 3) +#define EXYNOS4210_PHY1_HSIC_SWRST (1 5) +#define EXYNOS4210_PHY1_STD_SWRST (1 4) +#define EXYNOS4210_PHY1_ALL_SWRST (1 3) + +#define EXYNOS4X12_HSIC1_NORMAL_MASK (0x7 12) +#define EXYNOS4X12_HSIC1_SLEEP (1 14) +#define EXYNOS4X12_HSIC1_ANALOG_POWERDOWN(1 13) +#define EXYNOS4X12_HSIC1_FORCE_SUSPEND (1 12) +#define EXYNOS4X12_HSIC0_NORMAL_MASK (0x7 9) +#define EXYNOS4X12_HSIC0_SLEEP (1 11) +#define EXYNOS4X12_HSIC0_ANALOG_POWERDOWN(1 10) +#define EXYNOS4X12_HSIC0_FORCE_SUSPEND (1 9) + +#define EXYNOS4X12_HOST_LINK_PORT_SWRST_MASK (0xf 7) +#define EXYNOS4X12_HOST_LINK_PORT2_SWRST (1 10) +#define EXYNOS4X12_HOST_LINK_PORT1_SWRST (1 9) +#define
[PATCH] usb: dwc3: gadget: Fix sparse warnings
From: Moiz Sonasath m-sonas...@ti.com This patch fixes the following sparse warnings: drivers/usb/dwc3/gadget.c:1096:7: warning: symbol 'ret' shadows an earlier one drivers/usb/dwc3/gadget.c:1058:8: originally declared here drivers/usb/dwc3/gadget.c:1100:16: warning: symbol 'dwc' shadows an earlier one drivers/usb/dwc3/gadget.c:1057:15: originally declared here drivers/usb/dwc3/gadget.c:1118:16: warning: symbol 'dwc' shadows an earlier one drivers/usb/dwc3/gadget.c:1057:15: originally declared here drivers/usb/dwc3/gadget.c:1800:19: warning: symbol 'dep' shadows an earlier one drivers/usb/dwc3/gadget.c:1778:18: originally declared here Also, fix the potential checkpatch errors around the if() loops that this fix patch can create. Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/dwc3/gadget.c | 14 +++--- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 283c0cb..920d997 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1092,15 +1092,10 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req) * */ if (dep-flags DWC3_EP_PENDING_REQUEST) { - int ret; - ret = __dwc3_gadget_kick_transfer(dep, 0, true); - if (ret ret != -EBUSY) { - struct dwc3 *dwc = dep-dwc; - + if (ret ret != -EBUSY) dev_dbg(dwc-dev, %s: failed to kick transfers\n, dep-name); - } } /* @@ -1113,12 +1108,9 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req) WARN_ON_ONCE(!dep-resource_index); ret = __dwc3_gadget_kick_transfer(dep, dep-resource_index, false); - if (ret ret != -EBUSY) { - struct dwc3 *dwc = dep-dwc; - + if (ret ret != -EBUSY) dev_dbg(dwc-dev, %s: failed to kick transfers\n, dep-name); - } } /* @@ -1755,7 +1747,7 @@ static void dwc3_endpoint_transfer_complete(struct dwc3 *dwc, int i; for (i = 0; i DWC3_ENDPOINTS_NUM; i++) { - struct dwc3_ep *dep = dwc-eps[i]; + dep = dwc-eps[i]; if (!(dep-flags DWC3_EP_ENABLED)) continue; -- 1.7.12.rc0 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html