RE: [PATCH v7 00/11] usb: musb: adding multi instance support

2012-08-06 Thread Hiremath, Vaibhav
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

2012-08-06 Thread Oliver Neukum
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

2012-08-06 Thread Praveen Paneri
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

2012-08-06 Thread 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.

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

2012-08-06 Thread Simon Horman
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

2012-08-06 Thread Kuninori Morimoto

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

2012-08-06 Thread Felipe Balbi
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

2012-08-06 Thread Felipe Balbi
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

2012-08-06 Thread ABRAHAM, KISHON VIJAY
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

2012-08-06 Thread Heiko Stübner
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

2012-08-06 Thread ABRAHAM, KISHON VIJAY
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

2012-08-06 Thread Ying Xue
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

2012-08-06 Thread Felipe Balbi
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

2012-08-06 Thread Praveen Paneri
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

2012-08-06 Thread Pratyush Anand
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

2012-08-06 Thread Peiyong Feng
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

2012-08-06 Thread Felipe Balbi
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Felipe Balbi
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

2012-08-06 Thread Felipe Balbi
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

2012-08-06 Thread Ido Shayevitz
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Lukasz Majewski
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

2012-08-06 Thread Paul Menzel
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 ...)

2012-08-06 Thread Ming Lei
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Kishon Vijay Abraham I
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

2012-08-06 Thread Pratyush Anand

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

2012-08-06 Thread Alan Stern
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

2012-08-06 Thread Alan Stern
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.

2012-08-06 Thread Justin P. Mattock
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

2012-08-06 Thread Felipe Balbi
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 ...)

2012-08-06 Thread Alan Stern
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

2012-08-06 Thread Alan Stern
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

2012-08-06 Thread Tomas Sokorai
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

2012-08-06 Thread Sarah Sharp
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

2012-08-06 Thread David Binderman

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

2012-08-06 Thread Alan Stern
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

2012-08-06 Thread Alan Stern
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 ...)

2012-08-06 Thread Rafael J. Wysocki
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

2012-08-06 Thread Yann Cantin

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]

2012-08-06 Thread Yann Cantin
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.

2012-08-06 Thread Yann Cantin

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

2012-08-06 Thread Greg KH
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.

2012-08-06 Thread Greg KH
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]

2012-08-06 Thread Greg KH
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

2012-08-06 Thread Dmitry Torokhov
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]

2012-08-06 Thread Dmitry Torokhov
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.

2012-08-06 Thread Steven J. Hill
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

2012-08-06 Thread Tomas Sokorai
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.

2012-08-06 Thread Yann Cantin
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

2012-08-06 Thread kuninori . morimoto . gx

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

2012-08-06 Thread Kuninori Morimoto
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

2012-08-06 Thread Kuninori Morimoto
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

2012-08-06 Thread Kuninori Morimoto
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

2012-08-06 Thread Kuninori Morimoto
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

2012-08-06 Thread Yann Cantin
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 ...)

2012-08-06 Thread Ming Lei
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.

2012-08-06 Thread Dmitry Torokhov
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]

2012-08-06 Thread Yann Cantin
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

2012-08-06 Thread Dmitry Torokhov
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-08-06 Thread Peiyong Feng
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

2012-08-06 Thread Praveen Paneri
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

2012-08-06 Thread Pratyush Anand
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

2012-08-06 Thread Kyungmin Park
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

2012-08-06 Thread Kyungmin Park
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

2012-08-06 Thread Felipe Balbi
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