[PATCH 0/3] ARM: OMAP2+: Optimize soc_is calls

2015-09-07 Thread Keerthy 
The series implements optimizing soc_is calls for DRA7 and AM43XX
family of SoCs. Originally the soc_is calls for DRA7 involved parsing
device tree nodes and some repetitive string comparisons. Optimizing
to store the result and use the result in the subsequent calls.

The series is boot tested on am437x-gp-evm, dra7-evm, dra72-evm.

Keerthy (3):
  ARM: OMAP2: DRA7: Modify optimize string comparisons in soc_is calls
  ARM: dts: AM43x-epos-evm: Add AM438x compatible string for epos
  ARM: OMAP2: AM43XX: Modify optimize string comparisons in soc_is calls

 .../devicetree/bindings/arm/omap/omap.txt  |  5 +++-
 arch/arm/boot/dts/am43x-epos-evm.dts   |  2 +-
 arch/arm/mach-omap2/id.c   | 28 ++
 arch/arm/mach-omap2/soc.h  | 25 +++
 4 files changed, 53 insertions(+), 7 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] ARM: OMAP2: AM43XX: Modify optimize string comparisons in soc_is calls

2015-09-07 Thread Keerthy 
Currently everytime soc_is calls are made, firstly device tree nodes
are parsed and then string comparisons are made to determine the
soc version. Optimizing it to be done one time and store the result.
Use the stored value in all the subsequent checks for soc_is calls.

Signed-off-by: Keerthy 
---
 arch/arm/mach-omap2/id.c  | 11 +++
 arch/arm/mach-omap2/soc.h | 10 --
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 28acdb1..3de8015 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -61,6 +61,16 @@ void init_dra_soc_id(void)
soc_ids |= DRA72X;
 }
 
+void init_am43_soc_id(void)
+{
+   if (of_machine_is_compatible("ti,am43"))
+   soc_ids |= AM43XX;
+   if (of_machine_is_compatible("ti,am4372"))
+   soc_ids |= AM437X;
+   if (of_machine_is_compatible("ti,am438x"))
+   soc_ids |= AM438X;
+}
+
 int check_soc_version(unsigned long id)
 {
return soc_ids & id;
@@ -357,6 +367,7 @@ void __init omap3xxx_check_revision(void)
u16 hawkeye;
u8 rev;
 
+   init_am43_soc_id();
/*
 * We cannot access revision registers on ES1.0.
 * If the processor type is Cortex-A8 and the revision is 0x0
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 4b0a532..1c116e4 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -132,6 +132,9 @@
 #define DRA7XX BIT(0)
 #defineDRA74X  BIT(1)
 #define DRA72X BIT(2)
+#define AM43XX BIT(3)
+#define AM437X BIT(4)
+#define AM438X BIT(5)
 
 int check_soc_version(unsigned long id);
 int omap_type(void);
@@ -247,6 +250,7 @@ IS_AM_SUBCLASS(437x, 0x437)
 #define soc_is_am335x()0
 #define soc_is_am43xx()0
 #define soc_is_am437x()0
+#define soc_is_am438x()0
 #define cpu_is_omap44xx()  0
 #define cpu_is_omap443x()  0
 #define cpu_is_omap446x()  0
@@ -380,8 +384,10 @@ IS_OMAP_TYPE(3430, 0x3430)
 #ifdef CONFIG_SOC_AM43XX
 # undef soc_is_am43xx
 # undef soc_is_am437x
-# define soc_is_am43xx()   is_am43xx()
-# define soc_is_am437x()   is_am437x()
+# undef soc_is_am438x
+# define soc_is_am43xx()   check_soc_version(AM43XX)
+# define soc_is_am437x()   check_soc_version(AM437X)
+# define soc_is_am438x()   check_soc_version(AM438X)
 #endif
 
 # if defined(CONFIG_ARCH_OMAP4)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] ARM: dts: AM43x-epos-evm: Add AM438x compatible string for epos

2015-09-07 Thread Keerthy 
Add AM438x compatible property to identify the SoCs on epos evms.

Signed-off-by: Keerthy 
---
 Documentation/devicetree/bindings/arm/omap/omap.txt | 5 -
 arch/arm/boot/dts/am43x-epos-evm.dts| 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 9f4e513..dc3b5f2 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -100,6 +100,9 @@ SoCs:
 - AM4372
   compatible = "ti,am4372", "ti,am43"
 
+- AM438x
+  compatible = "ti,am438x", "ti,am43"
+
 Boards:
 
 - OMAP3 BeagleBoard : Low cost community board
@@ -142,7 +145,7 @@ Boards:
   compatible = "ti,omap5-evm", "ti,omap5"
 
 - AM43x EPOS EVM
-  compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
+  compatible = "ti,am43x-epos-evm", "ti,am438x", "ti,am43"
 
 - AM437x GP EVM
   compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 86c2dfb..1c9b9a0 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -18,7 +18,7 @@
 
 / {
model = "TI AM43x EPOS EVM";
-   compatible = "ti,am43x-epos-evm","ti,am4372","ti,am43";
+   compatible = "ti,am43x-epos-evm", "ti,am438x", "ti,am43";
 
aliases {
display0 = 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] ARM: OMAP2: DRA7: Modify optimize string comparisons in soc_is calls

2015-09-07 Thread Keerthy 
Currently everytime soc_is calls are made, firstly device tree nodes
are parsed and then string comparisons are made to determine the
soc version. Optimizing it to be done one time and store the result.
Use the stored value in all the subsequent checks for soc_is calls.

Signed-off-by: Keerthy 
---
 arch/arm/mach-omap2/id.c  | 17 +
 arch/arm/mach-omap2/soc.h | 15 ---
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index e3f713f..28acdb1 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -40,6 +40,7 @@
 #define OMAP_SOC_MAX_NAME_LENGTH   16
 
 static unsigned int omap_revision;
+static unsigned long soc_ids;
 static char soc_name[OMAP_SOC_MAX_NAME_LENGTH];
 static char soc_rev[OMAP_SOC_MAX_NAME_LENGTH];
 u32 omap_features;
@@ -50,6 +51,21 @@ unsigned int omap_rev(void)
 }
 EXPORT_SYMBOL(omap_rev);
 
+void init_dra_soc_id(void)
+{
+   if (of_machine_is_compatible("ti,dra7"))
+   soc_ids |= DRA7XX;
+   if (of_machine_is_compatible("ti,dra74"))
+   soc_ids |= DRA74X;
+   if (of_machine_is_compatible("ti,dra72"))
+   soc_ids |= DRA72X;
+}
+
+int check_soc_version(unsigned long id)
+{
+   return soc_ids & id;
+}
+
 int omap_type(void)
 {
static u32 val = OMAP2_DEVICETYPE_MASK;
@@ -643,6 +659,7 @@ void __init dra7xxx_check_revision(void)
u16 hawkeye;
u8 rev;
 
+   init_dra_soc_id();
idcode = read_tap_reg(OMAP_TAP_IDCODE);
hawkeye = (idcode >> 12) & 0x;
rev = (idcode >> 28) & 0xff;
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index f97654d..4b0a532 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -125,6 +125,15 @@
 #define OMAP2_DEVICE_TYPE_GP   3
 #define OMAP2_DEVICE_TYPE_BAD  4
 
+/*
+ * SoC types
+ */
+
+#define DRA7XX BIT(0)
+#defineDRA74X  BIT(1)
+#define DRA72X BIT(2)
+
+int check_soc_version(unsigned long id);
 int omap_type(void);
 
 /*
@@ -397,9 +406,9 @@ IS_OMAP_TYPE(3430, 0x3430)
 #undef soc_is_dra7xx
 #undef soc_is_dra74x
 #undef soc_is_dra72x
-#define soc_is_dra7xx()(of_machine_is_compatible("ti,dra7"))
-#define soc_is_dra74x()(of_machine_is_compatible("ti,dra74"))
-#define soc_is_dra72x()(of_machine_is_compatible("ti,dra72"))
+#define soc_is_dra7xx()check_soc_version(DRA7XX)
+#define soc_is_dra74x()check_soc_version(DRA74X)
+#define soc_is_dra72x()check_soc_version(DRA72X)
 #endif
 
 /* Various silicon revisions for omap2 */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 07/13] usb: otg: add OTG core

2015-09-07 Thread Li Jun 
On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
> The OTG core instantiates the OTG Finite State Machine
> per OTG controller and manages starting/stopping the
> host and gadget controllers based on the bus state.
> 
> It provides APIs for the following tasks
> 
> - Registering an OTG capable controller
> - Registering Host and Gadget controllers to OTG core
> - Providing inputs to and kicking the OTG state machine
> 
> Signed-off-by: Roger Quadros 
> ---
>  MAINTAINERS  |4 +-
>  drivers/usb/Kconfig  |2 +-
>  drivers/usb/Makefile |1 +
>  drivers/usb/common/Makefile  |3 +-
>  drivers/usb/common/usb-otg.c | 1061 
> ++
>  drivers/usb/common/usb-otg.h |   71 +++
>  drivers/usb/core/Kconfig |   11 +-
>  include/linux/usb/otg.h  |  189 +++-
>  8 files changed, 1321 insertions(+), 21 deletions(-)
>  create mode 100644 drivers/usb/common/usb-otg.c
>  create mode 100644 drivers/usb/common/usb-otg.h
> 

... ...

> +
> +/**
> + * Get OTG device from host or gadget device.
> + *
> + * For non device tree boot, the OTG controller is assumed to be
> + * the parent of the host/gadget device.

This assumption/restriction maybe a problem, as I pointed in your previous
version, usb_create_hcd() use the passed dev as its dev, but,
usb_add_gadget_udc() use the passed dev as its parent dev, so often the
host and gadget don't share the same parent device, at least it doesn't
apply to chipidea case.

> + * For device tree boot, the OTG controller is derived from the
> + * "otg-controller" property.
> + */
> +static struct device *usb_otg_get_device(struct device *hcd_gcd_dev)
> +{
> + struct device *otg_dev;
> +
> + if (!hcd_gcd_dev)
> + return NULL;
> +
> + if (hcd_gcd_dev->of_node) {
> + struct device_node *np;
> + struct platform_device *pdev;
> +
> + np = of_parse_phandle(hcd_gcd_dev->of_node, "otg-controller",
> +   0);
> + if (!np)
> + goto legacy;/* continue legacy way */
> +
> + pdev = of_find_device_by_node(np);
> + of_node_put(np);
> + if (!pdev) {
> + dev_err(>dev, "couldn't get otg-controller 
> device\n");
> + return NULL;
> + }
> +
> + otg_dev = >dev;
> + return otg_dev;
> + }
> +
> +legacy:
> + /* otg device is parent and must be registered */
> + otg_dev = hcd_gcd_dev->parent;
> + if (!usb_otg_get_data(otg_dev))
> + return NULL;
> +
> + return otg_dev;
> +}
> +

... ...

> +static void usb_otg_init_timers(struct usb_otg *otgd, unsigned *timeouts)
> +{
> + struct otg_fsm *fsm = >fsm;
> + unsigned long tmouts[NUM_OTG_FSM_TIMERS];
> + int i;
> +
> + /* set default timeouts */
> + tmouts[A_WAIT_VRISE] = TA_WAIT_VRISE;
> + tmouts[A_WAIT_VFALL] = TA_WAIT_VFALL;
> + tmouts[A_WAIT_BCON] = TA_WAIT_BCON;
> + tmouts[A_AIDL_BDIS] = TA_AIDL_BDIS;
> + tmouts[A_BIDL_ADIS] = TA_BIDL_ADIS;
> + tmouts[B_ASE0_BRST] = TB_ASE0_BRST;
> + tmouts[B_SE0_SRP] = TB_SE0_SRP;
> + tmouts[B_SRP_FAIL] = TB_SRP_FAIL;
> +
> + /* set controller provided timeouts */
> + if (timeouts) {
> + for (i = 0; i < NUM_OTG_FSM_TIMERS; i++) {
> + if (timeouts[i])
> + tmouts[i] = timeouts[i];
> + }
> + }
> +
> + otg_timer_init(A_WAIT_VRISE, otgd, set_tmout, TA_WAIT_VRISE,
> +>a_wait_vrise_tmout);
> + otg_timer_init(A_WAIT_VFALL, otgd, set_tmout, TA_WAIT_VFALL,
> +>a_wait_vfall_tmout);
> + otg_timer_init(A_WAIT_BCON, otgd, set_tmout, TA_WAIT_BCON,
> +>a_wait_bcon_tmout);
> + otg_timer_init(A_AIDL_BDIS, otgd, set_tmout, TA_AIDL_BDIS,
> +>a_aidl_bdis_tmout);
> + otg_timer_init(A_BIDL_ADIS, otgd, set_tmout, TA_BIDL_ADIS,
> +>a_bidl_adis_tmout);
> + otg_timer_init(B_ASE0_BRST, otgd, set_tmout, TB_ASE0_BRST,
> +>b_ase0_brst_tmout);
> +
> + otg_timer_init(B_SE0_SRP, otgd, set_tmout, TB_SE0_SRP,
> +>b_se0_srp);
> + otg_timer_init(B_SRP_FAIL, otgd, set_tmout, TB_SRP_FAIL,
> +>b_srp_done);
> +
> + /* FIXME: what about A_WAIT_ENUM? */

Either you init it as other timers, or you remove all of it, otherwise
there will be NULL pointer crash.

> +}
> +
> +/**
> + * OTG FSM ops function to add timer
> + */
> +static void usb_otg_add_timer(struct otg_fsm *fsm, enum otg_fsm_timer id)
> +{
> + struct usb_otg *otgd = container_of(fsm, struct usb_otg, fsm);
> + struct otg_timer *otgtimer = >timers[id];
> + struct hrtimer *timer = >timer;
> +
> + if (!otgd->fsm_running)
> + return;
> +
> + /* if timer is already active, exit */
> +

Re: [PATCH v4 13/13] usb: otg: Add dual-role device (DRD) support

2015-09-07 Thread Li Jun 
On Mon, Aug 24, 2015 at 04:21:24PM +0300, Roger Quadros wrote:
> DRD mode is a reduced functionality OTG mode. In this mode
> we don't support SRP, HNP and dynamic role-swap.
> 
> In DRD operation, the controller mode (Host or Peripheral)
> is decided based on the ID pin status. Once a cable plug (Type-A
> or Type-B) is attached the controller selects the state
> and doesn't change till the cable in unplugged and a different
> cable type is inserted.
> 
> As we don't need most of the complex OTG states and OTG timers
> we implement a lean DRD state machine in usb-otg.c.
> The DRD state machine is only interested in 2 hardware inputs
> 'id' and 'b_sess_vld'.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/common/usb-otg.c | 178 
> +--
>  include/linux/usb/otg-fsm.h  |   5 ++
>  include/linux/usb/otg.h  |   2 +
>  3 files changed, 177 insertions(+), 8 deletions(-)
> 

... ...

> +/* Called when entering a DRD state */
> +static void drd_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
> +{
> + struct usb_otg *otgd = container_of(fsm, struct usb_otg, fsm);
> +
> + if (fsm->otg->state == new_state)
> + return;
> +
> + fsm->state_changed = 1;
> + dev_dbg(otgd->dev, "otg: set state: %s\n",
> + usb_otg_state_string(new_state));
> + switch (new_state) {
> + case OTG_STATE_B_IDLE:
> + drd_set_protocol(fsm, PROTO_UNDEF);

You didn't address this comment for your previous version.

otg_drv_vbus(fsm, 0);

> + break;
> + case OTG_STATE_B_PERIPHERAL:
> + drd_set_protocol(fsm, PROTO_GADGET);

otg_drv_vbus(fsm, 0);

> + break;
> + case OTG_STATE_A_HOST:

otg_drv_vbus(fsm, 1);

> + drd_set_protocol(fsm, PROTO_HOST);
> + break;
> + case OTG_STATE_UNDEFINED:
> + case OTG_STATE_B_SRP_INIT:
> + case OTG_STATE_B_WAIT_ACON:
> + case OTG_STATE_B_HOST:
> + case OTG_STATE_A_IDLE:
> + case OTG_STATE_A_WAIT_VRISE:
> + case OTG_STATE_A_WAIT_BCON:
> + case OTG_STATE_A_SUSPEND:
> + case OTG_STATE_A_PERIPHERAL:
> + case OTG_STATE_A_WAIT_VFALL:
> + case OTG_STATE_A_VBUS_ERR:
> + default:
> + dev_warn(otgd->dev, "%s: otg: invalid state: %s\n",
> +  __func__, usb_otg_state_string(new_state));
> + break;
> + }
> +
> + fsm->otg->state = new_state;
> +}
> +
... ...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/9] usb: dwc3: add dual-role support

2015-09-07 Thread Roger Quadros 
Peter,

On 06/09/15 05:02, Peter Chen wrote:
> On Wed, Sep 02, 2015 at 05:24:16PM +0300, Roger Quadros wrote:
>> Register with the USB OTG core. Since we don't support
>> OTG yet we just work as a dual-role device even
>> if device tree says "otg".
>>
>> +
>> +static int dwc3_drd_init(struct dwc3 *dwc)
>> +{
>> +int ret, id, vbus;
>> +struct usb_otg_caps *otgcaps = >otg_config.otg_caps;
>> +
>> +otgcaps->otg_rev = 0;
>> +otgcaps->hnp_support = false;
>> +otgcaps->srp_support = false;
>> +otgcaps->adp_support = false;
>> +dwc->otg_config.fsm_ops = _drd_ops;
>> +
>> +if (!dwc->edev) {
>> +dev_err(dwc->dev, "No extcon device found for OTG mode\n");
>> +return -ENODEV;
>> +}
>> +
> 
> Do All dwc3 platforms id/vbus need to get through extcon? Do the
> SoCs have id/vbus pin?
> 
> 

Extcon access is in fact not needed from dwc3 driver and I will be getting
rid of this patch. We will support dual-role only via the OTG irq as in patch 5.

The way it works is that the OMAP glue layer dwc3-omap.c requests extcon device
and sets some mailbox register and this causes the VBUS/ID events to come over
OTG irq/status. So this patch is redundant.

The extcon device is not needed for all TI platforms. e.g. we need it for
DRA7 but not for AM437x.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 07/13] usb: otg: add OTG core

2015-09-07 Thread Roger Quadros 
On 07/09/15 04:23, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>> + * This is used by the USB Host stack to register the Host controller
>> + * to the OTG core. Host controller must not be started by the
>> + * caller as it is left upto the OTG state machine to do so.
>> + *
>> + * Returns: 0 on success, error value otherwise.
>> + */
>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>> + unsigned long irqflags, struct otg_hcd_ops *ops)
>> +{
>> +struct usb_otg *otgd;
>> +struct device *hcd_dev = hcd->self.controller;
>> +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>> +
> 
> One big problem here is: there are two designs for current (IP) driver
> code, one creates dedicated hcd device as roothub's parent, like dwc3.
> Another one doesn't do this, roothub's parent is core device (or otg device
> in your patch), like chipidea and dwc2.
> 
> Then, otg_dev will be glue layer device for chipidea after that.

OK. Let's add a way for the otg controller driver to provide the host and gadget
information to the otg core for such devices like chipidea and dwc2.

This API must be called before the hcd/gadget-driver is added so that the otg
core knows it's linked to an OTG controller.

Any better idea?

cheers,
-roger

> 
> Peter
> 
>> +if (!otg_dev)
>> +return -EINVAL; /* we're definitely not OTG */
>> +
>> +/* we're otg but otg controller might not yet be registered */
>> +mutex_lock(_list_mutex);
>> +otgd = usb_otg_get_data(otg_dev);
>> +mutex_unlock(_list_mutex);
>> +if (!otgd) {
>> +dev_dbg(hcd_dev,
>> +"otg: controller not yet registered. waiting..\n");
>> +/*
>> + * otg controller might register later. Put the hcd in
>> + * wait list and call us back when ready
>> + */
>> +if (usb_otg_hcd_wait_add(otg_dev, hcd, irqnum, irqflags, ops)) {
>> +dev_dbg(hcd_dev, "otg: failed to add to wait list\n");
>> +return -EINVAL;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +/* HCD will be started by OTG fsm when needed */
>> +mutex_lock(>fsm.lock);
>> +if (otgd->primary_hcd.hcd) {
>> +/* probably a shared HCD ? */
>> +if (usb_otg_hcd_is_primary_hcd(hcd)) {
>> +dev_err(otg_dev, "otg: primary host already 
>> registered\n");
>> +goto err;
>> +}
>> +
>> +if (hcd->shared_hcd == otgd->primary_hcd.hcd) {
>> +if (otgd->shared_hcd.hcd) {
>> +dev_err(otg_dev, "otg: shared host already 
>> registered\n");
>> +goto err;
>> +}
>> +
>> +otgd->shared_hcd.hcd = hcd;
>> +otgd->shared_hcd.irqnum = irqnum;
>> +otgd->shared_hcd.irqflags = irqflags;
>> +otgd->shared_hcd.ops = ops;
>> +dev_info(otg_dev, "otg: shared host %s registered\n",
>> + dev_name(hcd->self.controller));
>> +} else {
>> +dev_err(otg_dev, "otg: invalid shared host %s\n",
>> +dev_name(hcd->self.controller));
>> +goto err;
>> +}
>> +} else {
>> +if (!usb_otg_hcd_is_primary_hcd(hcd)) {
>> +dev_err(otg_dev, "otg: primary host must be registered 
>> first\n");
>> +goto err;
>> +}
>> +
>> +otgd->primary_hcd.hcd = hcd;
>> +otgd->primary_hcd.irqnum = irqnum;
>> +otgd->primary_hcd.irqflags = irqflags;
>> +otgd->primary_hcd.ops = ops;
>> +dev_info(otg_dev, "otg: primary host %s registered\n",
>> + dev_name(hcd->self.controller));
>> +}
>> +
>> +/*
>> + * we're ready only if we have shared HCD
>> + * or we don't need shared HCD.
>> + */
>> +if (otgd->shared_hcd.hcd || !otgd->primary_hcd.hcd->shared_hcd) {
>> +otgd->fsm.otg->host = hcd_to_bus(hcd);
>> +/* FIXME: set bus->otg_port if this is true OTG port with HNP */
>> +
>> +/* start FSM */
>> +usb_otg_start_fsm(>fsm);
>> +} else {
>> +dev_dbg(otg_dev, "otg: can't start till shared host 
>> registers\n");
>> +}
>> +
>> +mutex_unlock(>fsm.lock);
>> +
>> +return 0;
>> +
>> +err:
>> +mutex_unlock(>fsm.lock);
>> +return -EINVAL;
>> +}
>> +EXPORT_SYMBOL_GPL(usb_otg_register_hcd);
>> +
>> +/**
>> + * usb_otg_unregister_hcd - Unregister Host controller from OTG core
>> + * @hcd:Host controller device
>> + *
>> + * This is used by the USB Host stack to unregister the Host controller
>> + * from the OTG core. Ensures that Host controller is not running
>> + * on successful return.
>> + *
>> + *

Re: [PATCH v4 07/13] usb: otg: add OTG core

2015-09-07 Thread Roger Quadros 
On 07/09/15 10:40, Li Jun wrote:
> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>> The OTG core instantiates the OTG Finite State Machine
>> per OTG controller and manages starting/stopping the
>> host and gadget controllers based on the bus state.
>>
>> It provides APIs for the following tasks
>>
>> - Registering an OTG capable controller
>> - Registering Host and Gadget controllers to OTG core
>> - Providing inputs to and kicking the OTG state machine
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  MAINTAINERS  |4 +-
>>  drivers/usb/Kconfig  |2 +-
>>  drivers/usb/Makefile |1 +
>>  drivers/usb/common/Makefile  |3 +-
>>  drivers/usb/common/usb-otg.c | 1061 
>> ++
>>  drivers/usb/common/usb-otg.h |   71 +++
>>  drivers/usb/core/Kconfig |   11 +-
>>  include/linux/usb/otg.h  |  189 +++-
>>  8 files changed, 1321 insertions(+), 21 deletions(-)
>>  create mode 100644 drivers/usb/common/usb-otg.c
>>  create mode 100644 drivers/usb/common/usb-otg.h
>>
> 
> ... ...
> 
>> +
>> +/**
>> + * Get OTG device from host or gadget device.
>> + *
>> + * For non device tree boot, the OTG controller is assumed to be
>> + * the parent of the host/gadget device.
> 
> This assumption/restriction maybe a problem, as I pointed in your previous
> version, usb_create_hcd() use the passed dev as its dev, but,
> usb_add_gadget_udc() use the passed dev as its parent dev, so often the
> host and gadget don't share the same parent device, at least it doesn't
> apply to chipidea case.

Let's provide a way for OTG driver to provide the OTG core exactly which is
the related host/gadget device.

> 
>> + * For device tree boot, the OTG controller is derived from the
>> + * "otg-controller" property.
>> + */
>> +static struct device *usb_otg_get_device(struct device *hcd_gcd_dev)
>> +{
>> +struct device *otg_dev;
>> +
>> +if (!hcd_gcd_dev)
>> +return NULL;
>> +
>> +if (hcd_gcd_dev->of_node) {
>> +struct device_node *np;
>> +struct platform_device *pdev;
>> +
>> +np = of_parse_phandle(hcd_gcd_dev->of_node, "otg-controller",
>> +  0);
>> +if (!np)
>> +goto legacy;/* continue legacy way */
>> +
>> +pdev = of_find_device_by_node(np);
>> +of_node_put(np);
>> +if (!pdev) {
>> +dev_err(>dev, "couldn't get otg-controller 
>> device\n");
>> +return NULL;
>> +}
>> +
>> +otg_dev = >dev;
>> +return otg_dev;
>> +}
>> +
>> +legacy:
>> +/* otg device is parent and must be registered */
>> +otg_dev = hcd_gcd_dev->parent;
>> +if (!usb_otg_get_data(otg_dev))
>> +return NULL;
>> +
>> +return otg_dev;
>> +}
>> +
> 
> ... ...
> 
>> +static void usb_otg_init_timers(struct usb_otg *otgd, unsigned *timeouts)
>> +{
>> +struct otg_fsm *fsm = >fsm;
>> +unsigned long tmouts[NUM_OTG_FSM_TIMERS];
>> +int i;
>> +
>> +/* set default timeouts */
>> +tmouts[A_WAIT_VRISE] = TA_WAIT_VRISE;
>> +tmouts[A_WAIT_VFALL] = TA_WAIT_VFALL;
>> +tmouts[A_WAIT_BCON] = TA_WAIT_BCON;
>> +tmouts[A_AIDL_BDIS] = TA_AIDL_BDIS;
>> +tmouts[A_BIDL_ADIS] = TA_BIDL_ADIS;
>> +tmouts[B_ASE0_BRST] = TB_ASE0_BRST;
>> +tmouts[B_SE0_SRP] = TB_SE0_SRP;
>> +tmouts[B_SRP_FAIL] = TB_SRP_FAIL;
>> +
>> +/* set controller provided timeouts */
>> +if (timeouts) {
>> +for (i = 0; i < NUM_OTG_FSM_TIMERS; i++) {
>> +if (timeouts[i])
>> +tmouts[i] = timeouts[i];
>> +}
>> +}
>> +
>> +otg_timer_init(A_WAIT_VRISE, otgd, set_tmout, TA_WAIT_VRISE,
>> +   >a_wait_vrise_tmout);
>> +otg_timer_init(A_WAIT_VFALL, otgd, set_tmout, TA_WAIT_VFALL,
>> +   >a_wait_vfall_tmout);
>> +otg_timer_init(A_WAIT_BCON, otgd, set_tmout, TA_WAIT_BCON,
>> +   >a_wait_bcon_tmout);
>> +otg_timer_init(A_AIDL_BDIS, otgd, set_tmout, TA_AIDL_BDIS,
>> +   >a_aidl_bdis_tmout);
>> +otg_timer_init(A_BIDL_ADIS, otgd, set_tmout, TA_BIDL_ADIS,
>> +   >a_bidl_adis_tmout);
>> +otg_timer_init(B_ASE0_BRST, otgd, set_tmout, TB_ASE0_BRST,
>> +   >b_ase0_brst_tmout);
>> +
>> +otg_timer_init(B_SE0_SRP, otgd, set_tmout, TB_SE0_SRP,
>> +   >b_se0_srp);
>> +otg_timer_init(B_SRP_FAIL, otgd, set_tmout, TB_SRP_FAIL,
>> +   >b_srp_done);
>> +
>> +/* FIXME: what about A_WAIT_ENUM? */
> 
> Either you init it as other timers, or you remove all of it, otherwise
> there will be NULL pointer crash.

I want to initialize it but was not sure about the timeout value.
What timeout value I must use?

> 
>> +}
>> +
>> +/**
>> + * OTG FSM ops function to add timer
>> + */
>> +static void

Re: [PATCH 0/7] gpio: omap: fixes and improvements

2015-09-07 Thread Grygorii Strashko 

+Cc: Austin, Philipp

On 08/26/2015 10:53 AM, Linus Walleij wrote:

On Tue, Aug 18, 2015 at 1:10 PM, Grygorii Strashko
 wrote:


This patch series contains set of trivial fixes and improvements, and also
patches which fixes wrong APIs usage in atomic context as for -RT as for
non-RT kernel. The final goal of this series is to make TI OMAP GPIO
driver compatible with -RT kernel as much as possible.

Patch 1-4: trivial fixes and improvements
Patch 5: fixes wrong CLK clk_prepare/unprepare APIs usage in atomic contexet


I've applied patches 1-5 with Santosh's ACK and Tony's Tested-by.


Patch 6(rfc): required to be compatible with -RT kernel, because PM runtime
  can't be used in atimic context on -RT.
Patch 7(rfc): This patch converts TI OMAP GPIO driver to use generic irq
  handler instead of chained IRQ handler. This way OMAP GPIO driver will be
  compatible with RT kernel where it will be forced thread IRQ handler
  while in non-RT kernel it still will be executed in HW IRQ context.


Waiting for more feedback here.

Yours,
Linus Walleij



I've got some feedback here.
Patches were tested on to of TI -RT tree ti-rt-linux-4.1.y.



 Forwarded Message 
Subject: Re: [PATCH 0/7] gpio: omap: fixes and improvements
Date: Fri, 4 Sep 2015 21:42:03 +
From: Austin Schuh 
To: grygorii.stras...@ti.com
CC: Philipp Schrader 

Hi Grygorii,

We are running the entire patchset on top of
a7a6541db840cc4514a26fc12cc1bc94d1b9e873 from the git://
git.ti.com/ti-linux-kernel/ti-linux-kernel.git tree. I've pushed the
system pretty hard overnight and haven't seen any instability (with lockdep
enabled. We used to get splats pretty fast).

I wasn't on lkml when you sent the patchset out, so I'm not sure how to
best reply to the original thread with this info.

Tested-by: Austin Schuh 

Austin
 Forwarded Message 

--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/9] usb: dwc3: add dual-role support

2015-09-07 Thread Roger Quadros 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/09/15 12:06, Roger Quadros wrote:
> Felipe,
> 
> On 03/09/15 18:44, Felipe Balbi wrote:
>> Hi,
> 
>> On Thu, Sep 03, 2015 at 03:21:48PM +0300, Roger Quadros wrote:
> + dwc->fsm->id = id;
> + dwc->fsm->b_sess_vld = vbus;
> + usb_otg_sync_inputs(dwc->fsm);
> +}
> +
> +static int dwc3_drd_start_host(struct otg_fsm *fsm, int on)
> +{
> + struct device *dev = usb_otg_fsm_to_dev(fsm);
> + struct dwc3 *dwc = dev_get_drvdata(dev);

 how about adding a usb_otg_get_drvdata(fsm) ?
>>>
>>> You meant for otg core? That can be done.
> 
>> yeah. BTW, I think otg core needs quite a few changes to become actually
>> useful. Currently it's just too much pointer ping-pong going back and
>> forth between phy, otg core, udc and hcd.
> 
> Sure, any inputs for improvement appreciated.
> 
> 
>> Also, I caught a ton of issues with it and suspend/resume. You might
>> want to fix them before adding more users to it.
> 
> OK.
> 
> 
>> It's also rather racy and that needs fixing too. On top of all that, I
>> think there's too much being added to UDC just to get Dual-Role, let's
>> see if we can improve that too.
> 
> Would appreciate if you could give all your inputs on the otg core thread
> as early as you can :)
> 
> 
> @@ -843,6 +998,16 @@ static int dwc3_probe(struct platform_device *pdev)
>   hird_threshold = 12;
>  
>   if (node) {
> + if (of_property_read_bool(node, "extcon"))
> + dwc->edev = extcon_get_edev_by_phandle(dev, 0);
> + else if (of_property_read_bool(dev->parent->of_node, "extcon"))
> + dwc->edev = extcon_get_edev_by_phandle(dev->parent, 0);

 why do you need to check the parent ? Why isn't that done on the glue
 layer ?
>>>
>>> On DRA7-evm, the extcon device is defined in the glue layer node. But
>>> we need the device both at the glue layer and at the core layer.
> 
>> why do you need extcon here ? Glue updates core via UTMI about the
>> states, right ? So you should get proper VBUS and ID status via OTG IRQ.
>> Is that not working ?
> 
> I didn't even expect that would work. Let me give that a try.
> 
> 
>>> We do get the extcon device in dwc3-omap.c
>>>
>>> Any suggestion how to pass the extcon device from glue layer to core.c?
>>> Or should I add the extcon property to dwc3 USB node as well in the DT?
> 
>> GPIO toggles
>>   dwc3-omap extcon event
>> update status via UTMI STATUS register
>>   OTG IRQ on core
>> Horray!
> 
>> :-)
> 
> That's great. Thanks :)

This approach worked. Had to do the following change to the dwc3-omap glue
to make it work.

From: Roger Quadros 
Date: Fri, 4 Sep 2015 15:13:59 +0300
Subject: [PATCH] usb: dwc3: omap: Pass VBUS and ID events transparently

Don't make any decisions regarding VBUS session based on ID
status. That is best left to the OTG core.

Pass ID and VBUS events independent of each other so that OTG
core knows exactly what to do.

This makes dual-role with extcon work with OTG irq on OMAP platforms.

Signed-off-by: Roger Quadros 
- ---
 drivers/usb/dwc3/dwc3-omap.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index b18f2a3..751feee 100644
- --- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -233,19 +233,14 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
}
 
val = dwc3_omap_read_utmi_ctrl(omap);
- - val &= ~(USBOTGSS_UTMI_OTG_CTRL_IDDIG
- - | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID
- - | USBOTGSS_UTMI_OTG_CTRL_SESSEND);
- - val |= USBOTGSS_UTMI_OTG_CTRL_SESSVALID
- - | USBOTGSS_UTMI_OTG_CTRL_POWERPRESENT;
+   val &= ~USBOTGSS_UTMI_OTG_CTRL_IDDIG;
dwc3_omap_write_utmi_ctrl(omap, val);
break;
 
case OMAP_DWC3_VBUS_VALID:
val = dwc3_omap_read_utmi_ctrl(omap);
val &= ~USBOTGSS_UTMI_OTG_CTRL_SESSEND;
- - val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG
- - | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID
+   val |= USBOTGSS_UTMI_OTG_CTRL_VBUSVALID
| USBOTGSS_UTMI_OTG_CTRL_SESSVALID
| USBOTGSS_UTMI_OTG_CTRL_POWERPRESENT;
dwc3_omap_write_utmi_ctrl(omap, val);
@@ -254,14 +249,16 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
case OMAP_DWC3_ID_FLOAT:
if (omap->vbus_reg)
regulator_disable(omap->vbus_reg);
+   val = dwc3_omap_read_utmi_ctrl(omap);
+   val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG;
+   dwc3_omap_write_utmi_ctrl(omap, val);
 
case OMAP_DWC3_VBUS_OFF:
val =

Re: [PATCH v4 13/13] usb: otg: Add dual-role device (DRD) support

2015-09-07 Thread Roger Quadros 
On 07/09/15 10:53, Li Jun wrote:
> On Mon, Aug 24, 2015 at 04:21:24PM +0300, Roger Quadros wrote:
>> DRD mode is a reduced functionality OTG mode. In this mode
>> we don't support SRP, HNP and dynamic role-swap.
>>
>> In DRD operation, the controller mode (Host or Peripheral)
>> is decided based on the ID pin status. Once a cable plug (Type-A
>> or Type-B) is attached the controller selects the state
>> and doesn't change till the cable in unplugged and a different
>> cable type is inserted.
>>
>> As we don't need most of the complex OTG states and OTG timers
>> we implement a lean DRD state machine in usb-otg.c.
>> The DRD state machine is only interested in 2 hardware inputs
>> 'id' and 'b_sess_vld'.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/common/usb-otg.c | 178 
>> +--
>>  include/linux/usb/otg-fsm.h  |   5 ++
>>  include/linux/usb/otg.h  |   2 +
>>  3 files changed, 177 insertions(+), 8 deletions(-)
>>
> 
> ... ...
> 
>> +/* Called when entering a DRD state */
>> +static void drd_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
>> +{
>> +struct usb_otg *otgd = container_of(fsm, struct usb_otg, fsm);
>> +
>> +if (fsm->otg->state == new_state)
>> +return;
>> +
>> +fsm->state_changed = 1;
>> +dev_dbg(otgd->dev, "otg: set state: %s\n",
>> +usb_otg_state_string(new_state));
>> +switch (new_state) {
>> +case OTG_STATE_B_IDLE:
>> +drd_set_protocol(fsm, PROTO_UNDEF);
> 
> You didn't address this comment for your previous version.
> 
> otg_drv_vbus(fsm, 0);
> 
>> +break;
>> +case OTG_STATE_B_PERIPHERAL:
>> +drd_set_protocol(fsm, PROTO_GADGET);
> 
> otg_drv_vbus(fsm, 0);
> 
>> +break;
>> +case OTG_STATE_A_HOST:
> 
> otg_drv_vbus(fsm, 1);
> 

Sorry, I missed it. Will add in next version.

--
cheers,
-roger

>> +drd_set_protocol(fsm, PROTO_HOST);
>> +break;
>> +case OTG_STATE_UNDEFINED:
>> +case OTG_STATE_B_SRP_INIT:
>> +case OTG_STATE_B_WAIT_ACON:
>> +case OTG_STATE_B_HOST:
>> +case OTG_STATE_A_IDLE:
>> +case OTG_STATE_A_WAIT_VRISE:
>> +case OTG_STATE_A_WAIT_BCON:
>> +case OTG_STATE_A_SUSPEND:
>> +case OTG_STATE_A_PERIPHERAL:
>> +case OTG_STATE_A_WAIT_VFALL:
>> +case OTG_STATE_A_VBUS_ERR:
>> +default:
>> +dev_warn(otgd->dev, "%s: otg: invalid state: %s\n",
>> + __func__, usb_otg_state_string(new_state));
>> +break;
>> +}
>> +
>> +fsm->otg->state = new_state;
>> +}
>> +
> ... ...
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux 4.2.0-rc5: am335x: musb warnings

2015-09-07 Thread Yegor Yefremov 
On Mon, Aug 31, 2015 at 7:41 PM, Felipe Balbi  wrote:
> Hi,
>
> On Mon, Aug 31, 2015 at 11:41:59AM -0500, Felipe Balbi wrote:
>> On Mon, Aug 31, 2015 at 03:11:58PM +0200, Yegor Yefremov wrote:
>> > Hi Felipe,
>> >
>> > On Fri, Aug 7, 2015 at 12:57 PM, Yegor Yefremov
>> >  wrote:
>> > > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov
>> > >  wrote:
>> > >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi  wrote:
>> > >>> HI,
>> > >>>
>> > >>> On Thu, Aug 06, 2015 at 09:40:26AM +0200, Yegor Yefremov wrote:
>> >  I performed a stress test with several FT4232H chips connected to a
>> > >>>
>> > >>> how many ?
>> > >>
>> > >> # lsusb -t
>> > >> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> > >> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> > >> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>> > >> |__ Port 1: Dev 3, If 0, Class=, Driver=ftdi_sio, 480M
>> > >> |__ Port 1: Dev 3, If 1, Class=, Driver=ftdi_sio, 480M
>> > >> |__ Port 1: Dev 3, If 2, Class=, Driver=ftdi_sio, 480M
>> > >> |__ Port 1: Dev 3, If 3, Class=, Driver=ftdi_sio, 480M
>> > >> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>> > >> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>> > >> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>> > >> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>> > >> |__ Port 3: Dev 5, If 0, Class=, Driver=ftdi_sio, 480M
>> > >> |__ Port 3: Dev 5, If 1, Class=, Driver=ftdi_sio, 480M
>> > >> |__ Port 3: Dev 5, If 2, Class=, Driver=ftdi_sio, 480M
>> > >> |__ Port 3: Dev 5, If 3, Class=, Driver=ftdi_sio, 480M
>> > >>
>> > >> 3 chips a 4-ports are attached.
>> > >
>> > > Warnings appear on another device (without internal hub) with only one
>> > > FT4232H too:
>> > >
>> > > # lsusb -t
>> > > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> > > |__ Port 1: Dev 2, If 0, Class=, Driver=ftdi_sio, 480M
>> > > |__ Port 1: Dev 2, If 1, Class=, Driver=ftdi_sio, 480M
>> > > |__ Port 1: Dev 2, If 2, Class=, Driver=ftdi_sio, 480M
>> > > |__ Port 1: Dev 2, If 3, Class=, Driver=ftdi_sio, 480M
>> > >
>> >  hub, that is attached to one of the musb ports. So far the test was
>> >  successful for several hours. But I've seen following warnings:
>> > 
>> >  musb_host_rx 1973: Rx interrupt with no errors or packet!
>> >  musb_ep_program 931: broken !rx_reinit, ep5 csr 0203
>> >  musb_host_rx 1973: Rx interrupt with no errors or packet!
>> >  musb_host_rx 1973: Rx interrupt with no errors or packet!
>> >  musb_host_rx 1973: Rx interrupt with no errors or packet!
>> >  musb_host_rx 1973: Rx interrupt with no errors or packet!
>> >  musb_ep_program 931: broken !rx_reinit, ep5 csr 0003
>> >  musb_host_rx 1973: Rx interrupt with no errors or packet!
>> >  musb_ep_program 931: broken !rx_reinit, ep7 csr 0003
>> > 
>> >  Is this expected behavior?
>> > >>>
>> > >>> no, that shouldn't happen, but it does and, apparently, in more than 
>> > >>> one
>> > >>> implementation. Wondering if you're running into endpoint limitation 
>> > >>> due
>> > >>> to MUSB's poor transfer scheduling for non-bulk endpoints.
>> > >>>
>> > >>> --
>> > >>> balbi
>> >
>> > Now I have another trouble with msub and FTDI FT4232H chip. If I start
>> > something like this on all 4 ports at 115200b/s, then pull USB cable
>> > and the system freezes:
>> >
>> > cat /dev/urandom > /dev/ttyUSB0
>> > ...
>> > cat /dev/urandom > /dev/ttyUSB3
>> >
>> > I see these messages:
>> >
>> > ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb
>> > status: -110
>> > ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb
>> > status: -110
>> > ftdi_sio ttyUSB1: usb_serial_generic_write_bulk_callback - nonzero urb
>> > status: -110
>> > ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb
>> > status: -110
>> > ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb
>> > status: -110
>> > ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb
>> > status: -110
>> > ftdi_sio ttyUSB1: usb_serial_generic_write_bulk_callback - nonzero urb
>> > status: -110
>> > ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb
>> > status: -110
>> > ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb
>> > status: -110
>> >
>> > After them system reboots as my watchdog time expires.
>> >
>> > Kernel 4.2.0-rc5
>> >
>> > Older FTDI chips like FT2232 have no problems. Somehow is musb really
>> > allergic to FTDI and vice versa :-(
>>
>> those are just messages of URB time out. They should be expected. No
>> idea why you're getting a reboot though. I'll see if I can reproduce.
>
> okay, reproduced. Seems to be a race somewhere. some

Re: [PATCH v4 00/13] USB: OTG/DRD Core functionality

2015-09-07 Thread Roger Quadros 
On 06/09/15 10:06, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:11PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> This series centralizes OTG/Dual-role functionality in the kernel.
>> As of now I've got Dual-role functionality working pretty reliably on
>> dra7-evm and am437x-gp-evm.
>>
>> DWC3 controller and platform related patches will be sent separately.
>>
>> Series is based on Greg's usb-next tree.
>>
>> Changelog:
>> -
>> v4:
>> - Added DT support for tying otg-controller to host and gadget
>>  controllers. For DT we no longer have the constraint that
>>  OTG controller needs to be parent of host and gadget. They can be
>>  tied together using the "otg-controller" property.
>> - Relax the requirement for DT case that otg controller must register before
>>  host/gadget. We maintain a wait list of host/gadget devices
>>  waiting on the otg controller.
>> - Use a single struct usb_otg for otg data.
>> - Don't override host/gadget start/stop APIs. Let the controller
>>  drivers do what they want as they know best. Helper API is provided
>>  for controller start/stop that controller driver can use.
>> - Introduce struct usb_otg_config to pass the otg capabilities,
>>  otg ops and otg timer timeouts during otg controller registration.
>> - rebased on Greg's usb.git/usb-next
> 
> Roger, thanks for your hard work. Since it is complicated, and can't
> know its correctness and scalable well just reading code. I will run
> it for chipidea driver, wait some time please.

No problem and thanks for the tests.

cheers,
-roger

> 
> Peter
>>
>> v3:
>> - all otg related definations now in otg.h
>> - single kernel config USB_OTG to enable OTG core and FSM.
>> - resolved symbol dependency issues.
>> - use dev_vdbg instead of VDBG() in usb-otg-fsm.c
>> - rebased on v4.2-rc1
>>
>> v2:
>> - Use add/remove_hcd() instead of start/stop_hcd() to enable/disable
>>  the host controller
>> - added dual-role-device (DRD) state machine which is a much simpler
>>  mode of operation when compared to OTG. Here we don't support fancy
>>  OTG features like HNP, SRP, on the fly role-swap. The mode of operation
>>  is determined based on ID pin (cable type) and the role doesn't change
>>  till the cable type changes.
>>
>> Why?:
>> 
>>
>> Most of the OTG drivers have been dealing with the OTG state machine
>> themselves and there is a scope for code re-use. This has been
>> partly addressed by the usb/common/usb-otg-fsm.c but it still
>> leaves the instantiation of the state machine and OTG timers
>> to the controller drivers. We re-use usb-otg-fsm.c but
>> go one step further by instantiating the state machine and timers
>> thus making it easier for drivers to implement OTG functionality.
>>
>> Newer OTG cores support standard host interface (e.g. xHCI) so
>> host and gadget functionality are no longer closely knit like older
>> cores. There needs to be a way to co-ordinate the operation of the
>> host and gadget in OTG mode. i.e. to stop and start them from a
>> central location. This central location should be the USB OTG core.
>>
>> Host and gadget controllers might be sharing resources and can't
>> be always running. One has to be stopped for the other to run.
>> This can't be done as of now and can be done from the OTG core.
>>
>> What?:
>> -
>>
>> The OTG core instantiates the OTG/DRD Finite State Machine
>> per OTG controller and manages starting/stopping the
>> host and gadget controllers based on the bus state.
>> 
>> It provides APIs for the following
>> 
>> - Registering an OTG capable controller
>> struct otg_fsm *usb_otg_register(struct device *dev,
>>  struct usb_otg_config *config);
>>
>> int usb_otg_unregister(struct device *dev);
>>
>> - Registering Host controllers to OTG core (used by hcd-core)
>> int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>>  unsigned long irqflags, struct otg_hcd_ops *ops);
>> int usb_otg_unregister_hcd(struct usb_hcd *hcd);
>>
>>
>> - Registering Gadget controllers to OTG core (used by udc-core)
>> int usb_otg_register_gadget(struct usb_gadget *gadget,
>> struct otg_gadget_ops *ops);
>> int usb_otg_unregister_gadget(struct usb_gadget *gadget);
>>
>>
>> - Providing inputs to and kicking the OTG state machine
>> void usb_otg_sync_inputs(struct otg_fsm *fsm);
>> int usb_otg_kick_fsm(struct device *hcd_gcd_device);
>>
>> - Getting controller device structure from OTG state machine instance
>> struct device *usb_otg_fsm_to_dev(struct otg_fsm *fsm);
>>
>> 'struct otg_fsm' is the interface to the OTG state machine.
>> It contains inputs to the fsm, status of the fsm and operations
>> for the OTG controller driver.
>>
>> - Helper APIs for starting/stopping host/gadget controllers
>> int usb_otg_start_host(struct otg_fsm *fsm, int on);
>> int usb_otg_start_gadget(struct otg_fsm *fsm, int on);
>>
>> Usage model:
>> ---
>>
>> - The OTG core needs to know what host and

[net-next PATCH v3] drivers: net: cpsw: Add support to drive gpios for ethernet to be functional

2015-09-07 Thread Mugunthan V N 
In DRA72x EVM, by default slave 1 is connected to the onboard
phy, but slave 2 pins are also muxed with video input module
which is controlled by pcf857x gpio and currently to select slave
0 to connect to phy gpio hogging is used, but with
omap2plus_defconfig the pcf857x gpio is built as module. So when
using NFS on DRA72x EVM, board doesn't boot as gpio hogging do
not set proper gpio state to connect slave 0 to phy as it is
built as module and you do not see any errors for not setting
gpio and just mentions dhcp reply not got.

To solve this issue, introducing "mode-gpios" in DT when gpio
based muxing is required. This will throw a warning when gpio
get fails and returns probe defer. When gpio-pcf857x module is
installed, cpsw probes again and ethernet becomes functional.
Verified this on DRA72x with pcf as module and ramdisk.

Signed-off-by: Mugunthan V N 
---

Changes from v2:
* Used mode-gpios, so that the driver is generic enough to handle
  multiple gpios

This patch is tested on DRA72x, Logs [1] and pushed a branch [2]

[1]: http://pastebin.ubuntu.com/12306224/
[2]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
cpsw-gpio-optional-v3

---
 Documentation/devicetree/bindings/net/cpsw.txt | 7 +++
 drivers/net/ethernet/ti/cpsw.c | 9 +
 2 files changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index a9df21a..676ecf6 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -30,6 +30,13 @@ Optional properties:
 - dual_emac: Specifies Switch to act as Dual EMAC
 - syscon   : Phandle to the system control device node, which is
  the control module device of the am33x
+- mode-gpios   : Should be added if one/multiple gpio lines are
+ required to be driven so that cpsw data lines
+ can be connected to the phy via selective mux.
+ For example in dra72x-evm, pcf gpio has to be
+ driven low so that cpsw slave 0 and phy data
+ lines are connected via mux.
+
 
 Slave Properties:
 Required properties:
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 8fc90f1..c670317 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2207,6 +2208,7 @@ static int cpsw_probe(struct platform_device *pdev)
void __iomem*ss_regs;
struct resource *res, *ss_res;
const struct of_device_id   *of_id;
+   struct gpio_descs   *mode;
u32 slave_offset, sliver_offset, slave_size;
int ret = 0, i;
int irq;
@@ -2232,6 +2234,13 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ndev_ret;
}
 
+   mode = devm_gpiod_get_array_optional(>dev, "mode", GPIOD_OUT_LOW);
+   if (IS_ERR(mode)) {
+   ret = PTR_ERR(mode);
+   dev_err(>dev, "gpio request failed, ret %d\n", ret);
+   goto clean_ndev_ret;
+   }
+
/*
 * This may be required here for child devices.
 */
-- 
2.6.0.rc0.24.gec371ff

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 04/13] otg-fsm: move usb_bus_start_enum into otg-fsm->ops

2015-09-07 Thread Roger Quadros 
On 07/09/15 04:24, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:15PM +0300, Roger Quadros wrote:
>> This is to prevent missing symbol build error if OTG is
>> enabled (built-in) and HCD core (CONFIG_USB) is module.
>>
>> Signed-off-by: Roger Quadros 
>> Acked-by: Peter Chen 
>> ---
>>  drivers/usb/common/usb-otg-fsm.c | 6 --
>>  drivers/usb/phy/phy-fsl-usb.c| 2 ++
>>  include/linux/usb/otg-fsm.h  | 1 +
>>  3 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/common/usb-otg-fsm.c 
>> b/drivers/usb/common/usb-otg-fsm.c
>> index a46f29a..6e56c8c 100644
>> --- a/drivers/usb/common/usb-otg-fsm.c
>> +++ b/drivers/usb/common/usb-otg-fsm.c
>> @@ -165,8 +165,10 @@ static int otg_set_state(struct otg_fsm *fsm, enum 
>> usb_otg_state new_state)
>>  otg_loc_conn(fsm, 0);
>>  otg_loc_sof(fsm, 1);
>>  otg_set_protocol(fsm, PROTO_HOST);
>> -usb_bus_start_enum(fsm->otg->host,
>> -fsm->otg->host->otg_port);usb_bus_start_enum
>> +if (fsm->ops->start_enum) {
>> +fsm->ops->start_enum(fsm->otg->host,
>> + fsm->otg->host->otg_port);
>> +}
>>  break;
>>  case OTG_STATE_A_IDLE:
>>  otg_drv_vbus(fsm, 0);
>> diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
>> index ee3f2c2..19541ed 100644
>> --- a/drivers/usb/phy/phy-fsl-usb.c
>> +++ b/drivers/usb/phy/phy-fsl-usb.c
>> @@ -783,6 +783,8 @@ static struct otg_fsm_ops fsl_otg_ops = {
>>  
>>  .start_host = fsl_otg_start_host,
>>  .start_gadget = fsl_otg_start_gadget,
>> +
>> +.start_enum = usb_bus_start_enum,
>>  };
>>  
>>  /* Initialize the global variable fsl_otg_dev and request IRQ for OTG */
>> diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
>> index 672551c..75e82cc 100644
>> --- a/include/linux/usb/otg-fsm.h
>> +++ b/include/linux/usb/otg-fsm.h
>> @@ -199,6 +199,7 @@ struct otg_fsm_ops {
>>  void(*del_timer)(struct otg_fsm *fsm, enum otg_fsm_timer timer);
>>  int (*start_host)(struct otg_fsm *fsm, int on);
>>  int (*start_gadget)(struct otg_fsm *fsm, int on);
>> +int (*start_enum)(struct usb_bus *bus, unsigned port_num);
>>  };
>>  
>>  
> 
> Get one build warning:
> 
> In file included from 
> /u/home/b29397/work/projects/usb/drivers/usb/chipidea/udc.c:23:0:
> /u/home/b29397/work/projects/usb/include/linux/usb/otg-fsm.h:207:27: warning: 
> 'struct usb_bus' declared inside parameter list
>   int (*start_enum)(struct usb_bus *bus, unsigned port_num);
>  ^
> /u/home/b29397/work/projects/usb/include/linux/usb/otg-fsm.h:207:27: warning: 
> its scope is only this definition or declaration, which is probably not what 
> you want
> 
> It probably dues to we should not have struct usb_bus* at udc driver
> 
How about changing it to struct otg_fsm instead like the other APIs?
And do we leave usb_bus_start_enum() as it is?

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: omap3-igep: Move eth IRQ pinmux to IGEPv2 common dtsi

2015-09-07 Thread Javier Martinez Canillas 
Only the IGEPv2 boards have a LAN9221i chip connected to the GPMC
so the pinmux configuration for the GPIO connected to the IRQ line
of the LAN chip should not be defined in the IGEP common dtsi but
in the one common to the IGEPv2 boards.

While there, use the OMAP3_CORE1_IOPAD() macro for the padconf reg.

Suggested-by: Ladislav Michl 
Signed-off-by: Javier Martinez Canillas 

---

 arch/arm/boot/dts/omap3-igep.dtsi| 6 --
 arch/arm/boot/dts/omap3-igep0020-common.dtsi | 6 ++
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
index d5e5cd449b16..2230e1c03320 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -78,12 +78,6 @@
>;
};
 
-   smsc9221_pins: pinmux_smsc9221_pins {
-   pinctrl-single,pins = <
-   0x1a2 (PIN_INPUT | MUX_MODE4)   /* 
mcspi1_cs2.gpio_176 */
-   >;
-   };
-
i2c1_pins: pinmux_i2c1_pins {
pinctrl-single,pins = <
0x18a (PIN_INPUT | MUX_MODE0)   /* i2c1_scl.i2c1_scl */
diff --git a/arch/arm/boot/dts/omap3-igep0020-common.dtsi 
b/arch/arm/boot/dts/omap3-igep0020-common.dtsi
index e458c2185e3c..5ad688c57a00 100644
--- a/arch/arm/boot/dts/omap3-igep0020-common.dtsi
+++ b/arch/arm/boot/dts/omap3-igep0020-common.dtsi
@@ -156,6 +156,12 @@
OMAP3_CORE1_IOPAD(0x217a, PIN_INPUT | MUX_MODE0)
/* uart2_rx.uart2_rx */
>;
};
+
+   smsc9221_pins: pinmux_smsc9221_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x21d2, PIN_INPUT | MUX_MODE4)
/* mcspi1_cs2.gpio_176 */
+   >;
+   };
 };
 
 _pmx_core2 {
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: omap3-igep: Move eth IRQ pinmux to IGEPv2 common dtsi

2015-09-07 Thread Enric Balletbo Serra 
2015-09-07 18:24 GMT+02:00 Javier Martinez Canillas :
> Only the IGEPv2 boards have a LAN9221i chip connected to the GPMC
> so the pinmux configuration for the GPIO connected to the IRQ line
> of the LAN chip should not be defined in the IGEP common dtsi but
> in the one common to the IGEPv2 boards.
>
> While there, use the OMAP3_CORE1_IOPAD() macro for the padconf reg.
>
> Suggested-by: Ladislav Michl 
> Signed-off-by: Javier Martinez Canillas 
>
> ---
>
>  arch/arm/boot/dts/omap3-igep.dtsi| 6 --
>  arch/arm/boot/dts/omap3-igep0020-common.dtsi | 6 ++
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
> b/arch/arm/boot/dts/omap3-igep.dtsi
> index d5e5cd449b16..2230e1c03320 100644
> --- a/arch/arm/boot/dts/omap3-igep.dtsi
> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
> @@ -78,12 +78,6 @@
> >;
> };
>
> -   smsc9221_pins: pinmux_smsc9221_pins {
> -   pinctrl-single,pins = <
> -   0x1a2 (PIN_INPUT | MUX_MODE4)   /* 
> mcspi1_cs2.gpio_176 */
> -   >;
> -   };
> -
> i2c1_pins: pinmux_i2c1_pins {
> pinctrl-single,pins = <
> 0x18a (PIN_INPUT | MUX_MODE0)   /* i2c1_scl.i2c1_scl 
> */
> diff --git a/arch/arm/boot/dts/omap3-igep0020-common.dtsi 
> b/arch/arm/boot/dts/omap3-igep0020-common.dtsi
> index e458c2185e3c..5ad688c57a00 100644
> --- a/arch/arm/boot/dts/omap3-igep0020-common.dtsi
> +++ b/arch/arm/boot/dts/omap3-igep0020-common.dtsi
> @@ -156,6 +156,12 @@
> OMAP3_CORE1_IOPAD(0x217a, PIN_INPUT | MUX_MODE0)  
>   /* uart2_rx.uart2_rx */
> >;
> };
> +
> +   smsc9221_pins: pinmux_smsc9221_pins {
> +   pinctrl-single,pins = <
> +   OMAP3_CORE1_IOPAD(0x21d2, PIN_INPUT | MUX_MODE4)  
>   /* mcspi1_cs2.gpio_176 */
> +   >;
> +   };
>  };
>
>  _pmx_core2 {
> --
> 2.4.3
>

Looks good to me.

Acked-by: Enric Balletbo i Serra 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html