[PATCH 2/3] power_supply: Add support for tps65217-charger.

2015-09-08 Thread Enric Balletbo i Serra 
This patch adds support for the tps65217 charger driver. This driver is
responsible for controlling the charger aspect of the tps65217 mfd.
Currently, this mainly consists of turning on and off the charger, but
some other features of the charger can be supported through this driver.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/power/Kconfig|   7 +
 drivers/power/Makefile   |   1 +
 drivers/power/tps65217_charger.c | 269 +++
 3 files changed, 277 insertions(+)
 create mode 100644 drivers/power/tps65217_charger.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index f8758d6..57fdc80 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -434,6 +434,13 @@ config CHARGER_TPS65090
 Say Y here to enable support for battery charging with TPS65090
 PMIC chips.
 
+config CHARGER_TPS65217
+   tristate "TPS65217 battery charger driver"
+   depends on MFD_TPS65217
+   help
+Say Y here to enable support for battery charging with TPS65217
+PMIC chips.
+
 config BATTERY_GAUGE_LTC2941
tristate "LTC2941/LTC2943 Battery Gauge Driver"
depends on I2C
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 5752ce8..c1409b3 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_CHARGER_BQ25890) += bq25890_charger.o
 obj-$(CONFIG_POWER_AVS)+= avs/
 obj-$(CONFIG_CHARGER_SMB347)   += smb347-charger.o
 obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
+obj-$(CONFIG_CHARGER_TPS65217) += tps65217_charger.o
 obj-$(CONFIG_POWER_RESET)  += reset/
 obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
 obj-$(CONFIG_AXP288_CHARGER)   += axp288_charger.o
diff --git a/drivers/power/tps65217_charger.c b/drivers/power/tps65217_charger.c
new file mode 100644
index 000..0b6a30d
--- /dev/null
+++ b/drivers/power/tps65217_charger.c
@@ -0,0 +1,269 @@
+/*
+ * Battery charger driver for TI's tps65217
+ *
+ * Copyright (c) 2015, Collabora Ltd.
+
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+
+ * This program is distributed in the hope 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, see .
+ */
+
+/*
+ * Battery charger driver for TI's tps65217
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define POLL_INTERVAL  (HZ * 2)
+
+struct tps65217_charger {
+   struct tps65217 *tps;
+   struct device *dev;
+   struct power_supply *ac;
+
+   int ac_online;
+   int prev_ac_online;
+
+   struct task_struct  *poll_task;
+};
+
+static enum power_supply_property tps65217_ac_props[] = {
+   POWER_SUPPLY_PROP_ONLINE,
+};
+
+static int tps65217_config_charger(struct tps65217_charger *charger)
+{
+   int ret;
+
+   dev_dbg(charger->dev, "%s\n", __func__);
+
+   /*
+* tps65217 rev. G, p. 31 (see p. 32 for NTC schematic)
+*
+* The device can be configured to support a 100k NTC (B = 3960) by
+* setting the the NTC_TYPE bit in register CHGCONFIG1 to 1. However it
+* is not recommended to do so. In sleep mode, the charger continues
+* charging the battery, but all register values are reset to default
+* values. Therefore, the charger would get the wrong temperature
+* information. If 100k NTC setting is required, please contact the
+* factory.
+*
+* ATTENTION, conflicting information, from p. 46
+*
+* NTC TYPE (for battery temperature measurement)
+*   0 – 100k (curve 1, B = 3960)
+*   1 – 10k  (curve 2, B = 3480) (default on reset)
+*
+*/
+   ret = tps65217_clear_bits(charger->tps, TPS65217_REG_CHGCONFIG1,
+   TPS65217_CHGCONFIG1_NTC_TYPE,
+   TPS65217_PROTECT_NONE);
+   if (ret) {
+   dev_err(charger->dev,
+   "failed to set 100k NTC setting: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int tps65217_enable_charging(struct tps65217_charger *charger)
+{
+   int ret;
+
+   /* charger already enabled */
+   if (charger->ac_online)
+   return 0;
+
+   dev_dbg(charger->dev, "%s: enable charging\n", __func__);
+   ret = tps65217_set_bits(charger->tps, TPS65217_REG_CHGCONFIG1,
+

[PATCH 0/3] Add support for tps65217 charger

2015-09-08 Thread Enric Balletbo i Serra 
Hi all,

The following series add initial support for tps65217 battery charger. This
series is a first attempt and will have mistake so all comments and
suggestions are welcomed.

Best regards,

Enric Balletbo i Serra (3):
  devicetree: Add TPS65217 charger binding.
  power_supply: Add support for tps65217-charger.
  mfd: Add battery charger as subdevice to the tps65217.

 .../bindings/power_supply/tps65217_charger.txt |  12 +
 drivers/mfd/tps65217.c |   4 +
 drivers/power/Kconfig  |   7 +
 drivers/power/Makefile |   1 +
 drivers/power/tps65217_charger.c   | 269 +
 5 files changed, 293 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power_supply/tps65217_charger.txt
 create mode 100644 drivers/power/tps65217_charger.c

-- 
2.1.0

--
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] devicetree: Add TPS65217 charger binding.

2015-09-08 Thread Enric Balletbo i Serra 
The TPS65217 charger is a subnode of the TPS65217 MFD.

Signed-off-by: Enric Balletbo i Serra 
---
 .../devicetree/bindings/power_supply/tps65217_charger.txt| 12 
 1 file changed, 12 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power_supply/tps65217_charger.txt

diff --git 
a/Documentation/devicetree/bindings/power_supply/tps65217_charger.txt 
b/Documentation/devicetree/bindings/power_supply/tps65217_charger.txt
new file mode 100644
index 000..98d131a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/tps65217_charger.txt
@@ -0,0 +1,12 @@
+TPS65217 Charger
+
+Required Properties:
+-compatible: "ti,tps65217-charger"
+
+This node is a subnode of the tps65217 PMIC.
+
+Example:
+
+   tps65217-charger {
+   compatible = "ti,tps65090-charger";
+   };
-- 
2.1.0

--
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-08 Thread Peter Chen 
On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
> 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.
> 

Roger, not only chipidea and dwc2, I think the musb uses the same
hierarchy. If the host, device, and otg share the same register
region, host part can't be a platform driver since we don't want
to remap the same register region again.

So, in the design, we may need to consider both situations, one
is otg/host/device has its own register region, and host is a
separate platform device (A), the other is three parts share the
same register region, there is only one platform driver (B).

A:

IP core device 
|
|
  |-|-|
  gadget   host platform device 
|
roothub

B:

IP core device
|
|
  |-|-|
  gadget roothub


> 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?
> 

A flag stands for this hcd controller is the same with otg controller
can be used, this flag can be stored at struct usb_otg_config.

Peter

P.S: I still read your code, I find not all APIs in this file are used
in your dwc3 example. 
> > 
> >> +  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;
> >> +  }
> >> +
> >> +

[PATCH 3/3] mfd: Add battery charger as subdevice to the tps65217.

2015-09-08 Thread Enric Balletbo i Serra 
Add tps65217 battery charger subdevice.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/mfd/tps65217.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index 55add04..d32b5442 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -39,6 +39,10 @@ static const struct mfd_cell tps65217s[] = {
.name = "tps65217-bl",
.of_compatible = "ti,tps65217-bl",
},
+   {
+   .name = "tps65217-charger",
+   .of_compatible = "ti,tps65217-charger",
+   },
 };
 
 /**
-- 
2.1.0

--
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: omap2plus_defconfig: make PCF857x built-in

2015-09-08 Thread Kishon Vijay Abraham I 
Hello,

On Wednesday 05 August 2015 07:13 PM, Kishon Vijay Abraham I wrote:
> One of the lines from PCF857x is connected to the vdd line of MMC1
> in DRA74x and DRA72x EVMs and is modelled as a regulator. If PCF857x
> is not made as built-in, the regulator_get in omap_hsmmc fails making
> it difficult to use MMC1 as rootfs.
> 
> Make PCF857x built-in.

Can this be picked for 4.3?

Thanks
Kishon

> 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Sekhar Nori 
> ---
>  arch/arm/configs/omap2plus_defconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig 
> b/arch/arm/configs/omap2plus_defconfig
> index ac521e7..7cedfe9 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -236,7 +236,7 @@ CONFIG_SSI_PROTOCOL=m
>  CONFIG_PINCTRL_SINGLE=y
>  CONFIG_DEBUG_GPIO=y
>  CONFIG_GPIO_SYSFS=y
> -CONFIG_GPIO_PCF857X=m
> +CONFIG_GPIO_PCF857X=y
>  CONFIG_GPIO_TWL4030=y
>  CONFIG_GPIO_PALMAS=y
>  CONFIG_W1=m
> 
--
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-08 Thread Peter Chen 
On Mon, Sep 07, 2015 at 12:57:21PM +0300, Roger Quadros wrote:
> 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?
> 

You have defined struct otg_hcd_ops to let otg visit hcd stuff, how
about move this to otg_hcd_ops?

> cheers,
> -roger

-- 

Best Regards,
Peter Chen
--
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-08 Thread Roger Quadros 
On 08/09/15 09:54, Peter Chen wrote:
> On Mon, Sep 07, 2015 at 12:57:21PM +0300, Roger Quadros wrote:
>> 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?
>>
> 
> You have defined struct otg_hcd_ops to let otg visit hcd stuff, how
> about move this to otg_hcd_ops?

Yes, this is a better idea. Thanks.

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] dmaengine: omap-dma: Add support for memcpy

2015-09-08 Thread Laurent Pinchart 
Hi Peter,

Thank you for the patch.

While trying to port the omap_vout driver to the DMA engine API I noticed that 
the driver makes use of double-indexed transfers, which are not supported by 
the omap-dma driver. I haven't checked in details what would be required, but 
the interleaved API might be a good candidate for this. Do you have any plan 
to add support for double-indexed transfers to the omap-dma driver ?

On Wednesday 22 April 2015 10:34:29 Peter Ujfalusi wrote:
> The sDMA controller is capable of performing memory copy operation. It need
> to be configured to software triggered mode and without HW synchronization.
> The sDMA can copy data which is aligned to 8, 16 or 32 bits.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/dma/omap-dma.c | 51 +--
>  1 file changed, 49 insertions(+), 2 deletions(-)

-- 
Regards,

Laurent Pinchart

--
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

mysterious crashes on OMAP5 uevm

2015-09-08 Thread Grazvydas Ignotas 
Hi,

this is a longstanding problem I'm seeing since the very beginning,
which was around 3.12 or so (when I've first got the hardware) and it
seems 4.2 is affected by it still. Basically what happens is Xorg
randomly segfaults at some "impossible" location. I don't have the
details at the moment (could get them is needed), but from what I
examined with gdb some time ago the situation did not make any sense.

There are 2 workarounds that I know which make the problem go away
(one is enough):
- recompile Xorg with -marm (I'm using Debian armhf so it's thumb2 by default)
- disable ARCH_MULTI_V6 in the kernel config

Because of the above workarounds I have forgotten about it several
times, but it regularly comes back and bites again. It would look like
some missing erratum workaround, but I have all of them enabled in the
kernel.

Does anyone know about this? Perhaps some missing erratum workaround
in the bootloader? u-boot isn't too old here (2015.07).

Gražvydas
--
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-08 Thread Roger Quadros 


On 08/09/15 11:31, Peter Chen wrote:
> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
>> 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.
>>
> 
> Roger, not only chipidea and dwc2, I think the musb uses the same
> hierarchy. If the host, device, and otg share the same register
> region, host part can't be a platform driver since we don't want
> to remap the same register region again.
> 
> So, in the design, we may need to consider both situations, one
> is otg/host/device has its own register region, and host is a
> separate platform device (A), the other is three parts share the
> same register region, there is only one platform driver (B).
> 
> A:
> 
>   IP core device 
>   |
>   |
> |-|-|
> gadget   host platform device 
>   |
>   roothub
> 
> B:
> 
>   IP core device
>   |
>   |
> |-|-|
> gadget roothub
>   
> 
>> 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?
>>
> 
> A flag stands for this hcd controller is the same with otg controller
> can be used, this flag can be stored at struct usb_otg_config.

What if there is another architecture like so?

C:
[Parent]
   |
   |
|--|--|
[OTG core]  [gadget][host]

We need a more flexible mechanism to link the gadget and
host device to the otg core for non DT case.

How about adding struct usb_otg parameter to usb_otg_register_hcd()?

e.g.
int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)

If otg is NULL it will try DT otg-controller property or parent to
get the otg controller.

> 
> Peter
> 
> P.S: I still read your code, I find not all APIs in this file are used
> in your dwc3 example. 

Which ones? The ones for registering/unregistered host/gadget are used
by hcd/udc core as part of usb_add/remove_hcd() and
udc_bind_to_driver()/usb_gadget_remove_driver()

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] dmaengine: omap-dma: Add support for memcpy

2015-09-08 Thread Peter Ujfalusi 
Laurent,

On 09/08/2015 02:24 PM, Laurent Pinchart wrote:
> Hi Peter,
> 
> Thank you for the patch.
> 
> While trying to port the omap_vout driver to the DMA engine API I noticed 
> that 
> the driver makes use of double-indexed transfers, which are not supported by 
> the omap-dma driver. I haven't checked in details what would be required, but 
> the interleaved API might be a good candidate for this. Do you have any plan 
> to add support for double-indexed transfers to the omap-dma driver ?

If double-indexed transfer support is needed by drivers still using the
legacy/direct sDMA API, then I don't think we have other options..
So far I have not looked at that part and where it would fit.
I'll try to find time to look at this. I hope not in the distant future ;)

> On Wednesday 22 April 2015 10:34:29 Peter Ujfalusi wrote:
>> The sDMA controller is capable of performing memory copy operation. It need
>> to be configured to software triggered mode and without HW synchronization.
>> The sDMA can copy data which is aligned to 8, 16 or 32 bits.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/dma/omap-dma.c | 51 +--
>>  1 file changed, 49 insertions(+), 2 deletions(-)
> 

-- 
Péter
--
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: [net-next PATCH v3] drivers: net: cpsw: Add support to drive gpios for ethernet to be functional

2015-09-08 Thread Tony Lindgren 
* Mugunthan V N  [150907 02:50]:
> 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 

Acked-by: Tony Lindgren 

> ---
> 
> 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 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node

2015-09-08 Thread Tony Lindgren 
* Kevin Hilman  [150908 11:36]:
> On Wed, Sep 2, 2015 at 6:07 AM, Tony Lindgren  wrote:
> > * Neil Brown  [150901 23:23]:
> >> Kevin Hilman  writes:
> >>
> >> > ping... this boot failure has now landed in mainline
> >>
> >> sorry, I'm on leave at the moment and travelling so I'm unlikely to be
> >> able to look at this properly.  I should be able to examine this issue
> >> before the end of the month but cannot promise sooner than that (though
> >> it is not impossible).
> >>
> >> Maybe it would be best to just revert it until a proper analysis can be
> >> done.
> >
> > OK yeah let's revert this one for now until we know what goes wrong.
> 
> Looks like this is still in mainline.
> 
> Tony, can you revert?

Probably best that Sebastian does it as there's another fix needed
too. It seems the following are needed:

- Revert $subject patch 3fc3895e4fe1 ("twl4030_charger: correctly
  handle -EPROBE_DEFER from devm_usb_get_phy_by_node")

- Apply compile fix "[PATCH] twl4030_charger: fix another compile
  error"

Just in case Sebastian is travelling or something.. Sebastian,
can you please confirm?

Regards,

Tony
--
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: mysterious crashes on OMAP5 uevm

2015-09-08 Thread Tony Lindgren 
* Grazvydas Ignotas  [150908 13:44]:
> On Tue, Sep 8, 2015 at 4:38 PM, Tony Lindgren  wrote:
> > * Grazvydas Ignotas  [150908 05:50]:
> >> Hi,
> >>
> >> this is a longstanding problem I'm seeing since the very beginning,
> >> which was around 3.12 or so (when I've first got the hardware) and it
> >> seems 4.2 is affected by it still. Basically what happens is Xorg
> >> randomly segfaults at some "impossible" location. I don't have the
> >> details at the moment (could get them is needed), but from what I
> >> examined with gdb some time ago the situation did not make any sense.
> >>
> >> There are 2 workarounds that I know which make the problem go away
> >> (one is enough):
> >> - recompile Xorg with -marm (I'm using Debian armhf so it's thumb2 by 
> >> default)
> >> - disable ARCH_MULTI_V6 in the kernel config
> >>
> >> Because of the above workarounds I have forgotten about it several
> >> times, but it regularly comes back and bites again. It would look like
> >> some missing erratum workaround, but I have all of them enabled in the
> >> kernel.
> >>
> >> Does anyone know about this? Perhaps some missing erratum workaround
> >> in the bootloader? u-boot isn't too old here (2015.07).
> >
> > Seems like some incorrect handling with CONFIG_CPU_V6 compiled in..
> > Maybe try to narrow it down by commenting out some CONFIG_CPU_V6 and
> > __LINUX_ARM_ARCH__ = 6 ifdefs in the git grep CONFIG_CPU_V6
> > places ignoring uncompress and davinci code.
> 
> ok with that it was quite easy to find. On a kernel with ARCH_MULTI_V6
> disabled, it is enough to just do this:
> 
> --- a/arch/arm/kernel/signal.c
> +++ b/arch/arm/kernel/signal.c
> @@ -340,13 +340,13 @@ setup_return(struct pt_regs *regs, struct ksignal *ksig,
> /*
>  * The LSB of the handler determines if we're going to
>  * be using THUMB or ARM mode for this signal handler.
>  */
> thumb = handler & 1;
> 
> -#if __LINUX_ARM_ARCH__ >= 7
> +#if 0 //__LINUX_ARM_ARCH__ >= 7
> /*
>  * Clear the If-Then Thumb-2 execution state
>  * ARM spec requires this to be all 000s in ARM mode
>  * Snapdragon S4/Krait misbehaves on a Thumb=>ARM
>  * signal transition without this.
>  */
> 
> ... and the problem appears, so I guess this needs some real
> multiplatform handling,.

OK nice to hear you found it. Yeah looks like some runtime
capability check is needed.
 
> > Do you have some easy way to reproduce this issue?
> 
> Just moving a browser window around with mouse usually triggers it
> within a minute.

OK good to know.

Regards,

Tony
--
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: mysterious crashes on OMAP5 uevm

2015-09-08 Thread Grazvydas Ignotas 
On Tue, Sep 8, 2015 at 4:38 PM, Tony Lindgren  wrote:
> * Grazvydas Ignotas  [150908 05:50]:
>> Hi,
>>
>> this is a longstanding problem I'm seeing since the very beginning,
>> which was around 3.12 or so (when I've first got the hardware) and it
>> seems 4.2 is affected by it still. Basically what happens is Xorg
>> randomly segfaults at some "impossible" location. I don't have the
>> details at the moment (could get them is needed), but from what I
>> examined with gdb some time ago the situation did not make any sense.
>>
>> There are 2 workarounds that I know which make the problem go away
>> (one is enough):
>> - recompile Xorg with -marm (I'm using Debian armhf so it's thumb2 by 
>> default)
>> - disable ARCH_MULTI_V6 in the kernel config
>>
>> Because of the above workarounds I have forgotten about it several
>> times, but it regularly comes back and bites again. It would look like
>> some missing erratum workaround, but I have all of them enabled in the
>> kernel.
>>
>> Does anyone know about this? Perhaps some missing erratum workaround
>> in the bootloader? u-boot isn't too old here (2015.07).
>
> Seems like some incorrect handling with CONFIG_CPU_V6 compiled in..
> Maybe try to narrow it down by commenting out some CONFIG_CPU_V6 and
> __LINUX_ARM_ARCH__ = 6 ifdefs in the git grep CONFIG_CPU_V6
> places ignoring uncompress and davinci code.

ok with that it was quite easy to find. On a kernel with ARCH_MULTI_V6
disabled, it is enough to just do this:

--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -340,13 +340,13 @@ setup_return(struct pt_regs *regs, struct ksignal *ksig,
/*
 * The LSB of the handler determines if we're going to
 * be using THUMB or ARM mode for this signal handler.
 */
thumb = handler & 1;

-#if __LINUX_ARM_ARCH__ >= 7
+#if 0 //__LINUX_ARM_ARCH__ >= 7
/*
 * Clear the If-Then Thumb-2 execution state
 * ARM spec requires this to be all 000s in ARM mode
 * Snapdragon S4/Krait misbehaves on a Thumb=>ARM
 * signal transition without this.
 */

... and the problem appears, so I guess this needs some real
multiplatform handling,.

> Do you have some easy way to reproduce this issue?

Just moving a browser window around with mouse usually triggers it
within a minute.

>
> Regards,
>
> Tony

Gražvydas
--
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] gpio: omap: Fix GPIO numbering for deferred probe

2015-09-08 Thread Linus Walleij 
On Thu, Sep 3, 2015 at 7:31 PM, Tony Lindgren  wrote:

> If gpio-omap probe fails with -EPROBE_DEFER, the GPIO numbering
> keeps increasing. Only increase the gpio count if gpiochip_add()
> was successful as otherwise the numbers will increase for each
> probe attempt.
>
> Cc: Grygorii Strashko 
> Cc: Javier Martinez Canillas 
> Cc: Kevin Hilman 
> Cc: Santosh Shilimkar 
> Signed-off-by: Tony Lindgren 

Patch applied with Grygorii's review tag.

Yours,
Linus Walleij
--
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] pinctrl: core: Warn about NULL gpio_chip in pinctrl_ready_for_gpio_range()

2015-09-08 Thread Linus Walleij 
On Thu, Sep 3, 2015 at 7:34 PM, Tony Lindgren  wrote:

> If the gpio driver is confused about the numbers for gpio-ranges,
> pinctrl_ready_for_gpio_range() may get called with invalid GPIO
> causing a NULL pointer exception. Let's instead provide a warning
> that allows fixing the problem and return with error.
>
> Signed-off-by: Tony Lindgren 

Patch applied for fixes.

Yours,
Linus Walleij
--
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-08 Thread Alan Stern 
On Tue, 8 Sep 2015, Roger Quadros wrote:

> On 08/09/15 11:31, Peter Chen wrote:
> > On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
> >> 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.
> >>
> > 
> > Roger, not only chipidea and dwc2, I think the musb uses the same
> > hierarchy. If the host, device, and otg share the same register
> > region, host part can't be a platform driver since we don't want
> > to remap the same register region again.
> > 
> > So, in the design, we may need to consider both situations, one
> > is otg/host/device has its own register region, and host is a
> > separate platform device (A), the other is three parts share the
> > same register region, there is only one platform driver (B).
> > 
> > A:
> > 
> > IP core device 
> > |
> > |
> >   |-|-|
> >   gadget   host platform device 
> > |
> > roothub
> > 
> > B:
> > 
> > IP core device
> > |
> > |
> >   |-|-|
> >   gadget roothub
> > 
> > 
> >> 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?
> >>
> > 
> > A flag stands for this hcd controller is the same with otg controller
> > can be used, this flag can be stored at struct usb_otg_config.
> 
> What if there is another architecture like so?
> 
> C:
>   [Parent]
>  |
>  |
>   |--|--|
>   [OTG core]  [gadget][host]
> 
> We need a more flexible mechanism to link the gadget and
> host device to the otg core for non DT case.
> 
> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
> 
> e.g.
> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
> 
> If otg is NULL it will try DT otg-controller property or parent to
> get the otg controller.

This seems a lot like something Peter and I discussed recently.  See

http://marc.info/?l=linux-usb=143977568021328=2

and the following messages in that thread.

Alan Stern


--
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] pwm: tipwmss: enable on TI DRA7x and AM437x

2015-09-08 Thread Sekhar Nori 
From: Vignesh R 

TIPWMSS is present on TI's DRA7x and
AM437x SoCs. Enable its usage.

Instead of adding each SoC individually,
use the more generic ARCH_OMAP2PLUS
instead.

Signed-off-by: Vignesh R 
Signed-off-by: Sekhar Nori 
---
 drivers/pwm/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index b1541f40fd8d..c446f367f18a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -319,7 +319,7 @@ config PWM_TEGRA
 
 config  PWM_TIECAP
tristate "ECAP PWM support"
-   depends on SOC_AM33XX || ARCH_DAVINCI_DA8XX
+   depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX
help
  PWM driver support for the ECAP APWM controller found on AM33XX
  TI SOC
@@ -329,7 +329,7 @@ config  PWM_TIECAP
 
 config  PWM_TIEHRPWM
tristate "EHRPWM PWM support"
-   depends on SOC_AM33XX || ARCH_DAVINCI_DA8XX
+   depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX
help
  PWM driver support for the EHRPWM controller found on AM33XX
  TI SOC
@@ -339,7 +339,7 @@ config  PWM_TIEHRPWM
 
 config  PWM_TIPWMSS
bool
-   default y if SOC_AM33XX && (PWM_TIECAP || PWM_TIEHRPWM)
+   default y if (ARCH_OMAP2PLUS) && (PWM_TIECAP || PWM_TIEHRPWM)
help
  PWM Subsystem driver support for AM33xx SOC.
 
-- 
2.4.4.408.g16da57c

--
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-08 Thread Felipe Balbi 
On Mon, Sep 07, 2015 at 12:32:10PM +0200, Yegor Yefremov wrote:
> 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

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

2015-09-08 Thread Peter Chen 
On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
> 
> 
> On 08/09/15 11:31, Peter Chen wrote:
> > On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
> >> 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.
> >>
> > 
> > Roger, not only chipidea and dwc2, I think the musb uses the same
> > hierarchy. If the host, device, and otg share the same register
> > region, host part can't be a platform driver since we don't want
> > to remap the same register region again.
> > 
> > So, in the design, we may need to consider both situations, one
> > is otg/host/device has its own register region, and host is a
> > separate platform device (A), the other is three parts share the
> > same register region, there is only one platform driver (B).
> > 
> > A:
> > 
> > IP core device 
> > |
> > |
> >   |-|-|
> >   gadget   host platform device 
> > |
> > roothub
> > 
> > B:
> > 
> > IP core device
> > |
> > |
> >   |-|-|
> >   gadget roothub
> > 
> > 
> >> 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?
> >>
> > 
> > A flag stands for this hcd controller is the same with otg controller
> > can be used, this flag can be stored at struct usb_otg_config.
> 
> What if there is another architecture like so?
> 
> C:
>   [Parent]
>  |
>  |
>   |--|--|
>   [OTG core]  [gadget][host]
> 
> We need a more flexible mechanism to link the gadget and
> host device to the otg core for non DT case.
> 
> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
> 
> e.g.
> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
> 
> If otg is NULL it will try DT otg-controller property or parent to
> get the otg controller.

How usb_otg_register_hcd get struct usb_otg, from where?

> 
> > 
> > Peter
> > 
> > P.S: I still read your code, I find not all APIs in this file are used
> > in your dwc3 example. 
> 
> Which ones? The ones for registering/unregistered host/gadget are used
> by hcd/udc core as part of usb_add/remove_hcd() and
> udc_bind_to_driver()/usb_gadget_remove_driver()
> 

Ok, now I understand your design, usb_create_hcd must be called before
the fsm kicks off. The call flow like below:

usb_otg_register->usb_create_hcd->usb_add_hcd->usb_otg_register_hcd->
usb_otg_start_host->usb_otg_add_hcd

We need to make some changes to let chipidea work since usb_create_hcd
is included at host->start.

-- 

Best Regards,
Peter Chen
--
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 10/13] usb: hcd: Adapt to OTG core

2015-09-08 Thread Peter Chen 
On Mon, Aug 24, 2015 at 04:21:21PM +0300, Roger Quadros wrote:
> The existing usb_add/remove_hcd() functionality
> remains unchanged for non-OTG devices. For OTG
> devices they only register the HCD with the OTG core.
> 
> Introduce usb_otg_add/remove_hcd() for use by OTG core.
> These functions actually add/remove the HCD.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/core/hcd.c | 55 
> +-
>  1 file changed, 50 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index c0fd1f6..4851682 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -46,6 +46,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "usb.h"
>  
> @@ -2625,8 +2626,8 @@ static void usb_put_invalidate_rhdev(struct usb_hcd 
> *hcd)
>   * buffers of consistent memory, register the bus, request the IRQ line,
>   * and call the driver's reset() and start() routines.
>   */
> -int usb_add_hcd(struct usb_hcd *hcd,
> - unsigned int irqnum, unsigned long irqflags)
> +static int usb_otg_add_hcd(struct usb_hcd *hcd,
> +unsigned int irqnum, unsigned long irqflags)

You may change the kernel doc to this name too.

>  {
>   int retval;
>   struct usb_device *rhdev;
> @@ -2839,17 +2840,16 @@ err_phy:
>   }
>   return retval;
>  }
> -EXPORT_SYMBOL_GPL(usb_add_hcd);
>  
>  /**
> - * usb_remove_hcd - shutdown processing for generic HCDs
> + * usb_otg_remove_hcd - shutdown processing for generic HCDs
>   * @hcd: the usb_hcd structure to remove
>   * Context: !in_interrupt()
>   *
>   * Disconnects the root hub, then reverses the effects of usb_add_hcd(),
>   * invoking the HCD's stop() method.
>   */
> -void usb_remove_hcd(struct usb_hcd *hcd)
> +static void usb_otg_remove_hcd(struct usb_hcd *hcd)
>  {
>   struct usb_device *rhdev = hcd->self.root_hub;
>  
> @@ -2923,6 +2923,51 @@ void usb_remove_hcd(struct usb_hcd *hcd)
>  
>   usb_put_invalidate_rhdev(hcd);
>  }
> +
> +static struct otg_hcd_ops otg_hcd_intf = {
> + .add = usb_otg_add_hcd,
> + .remove = usb_otg_remove_hcd,
> +};
> +
> +/**
> + * usb_add_hcd - finish generic HCD structure initialization and register
> + * @hcd: the usb_hcd structure to initialize
> + * @irqnum: Interrupt line to allocate
> + * @irqflags: Interrupt type flags
> + *
> + * Finish the remaining parts of generic HCD initialization: allocate the
> + * buffers of consistent memory, register the bus, request the IRQ line,
> + * and call the driver's reset() and start() routines.
> + * If it is an OTG device then it only registers the HCD with OTG core.
> + *
> + */
> +int usb_add_hcd(struct usb_hcd *hcd,
> + unsigned int irqnum, unsigned long irqflags)
> +{
> + /* If OTG device, OTG core takes care of adding HCD */
> + if (usb_otg_register_hcd(hcd, irqnum, irqflags, _hcd_intf))
> + return usb_otg_add_hcd(hcd, irqnum, irqflags);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(usb_add_hcd);
> +
> +/**
> + * usb_remove_hcd - shutdown processing for generic HCDs
> + * @hcd: the usb_hcd structure to remove
> + * Context: !in_interrupt()
> + *
> + * Disconnects the root hub, then reverses the effects of usb_add_hcd(),
> + * invoking the HCD's stop() method.
> + * If it is an OTG device then it unregisters the HCD from OTG core
> + * as well.
> + */
> +void usb_remove_hcd(struct usb_hcd *hcd)
> +{
> + /* If OTG device, OTG core takes care of stopping HCD */
> + if (usb_otg_unregister_hcd(hcd))
> + usb_otg_remove_hcd(hcd);
> +}
>  EXPORT_SYMBOL_GPL(usb_remove_hcd);
>  
>  void
> -- 
> 2.1.4
> 

-- 

Best Regards,
Peter Chen
--
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: multi_v7_defconfig: Enable PBIAS regulator

2015-09-08 Thread Guenter Roeck 
On Sun, Sep 06, 2015 at 04:41:10PM -0700, Guenter Roeck wrote:
> On Thu, Sep 03, 2015 at 03:25:11PM +0530, Kishon Vijay Abraham I wrote:
> > PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
> > OMAP5 and DRA7 SoCs. Enable it here.
> > 
> > Signed-off-by: Kishon Vijay Abraham I 
> 
> Tested-by: Guenter Roeck 
> 
This problem is now causing various runtime failures in mainline.
I see the following qemu test failures:

arm:beagle:multi_v7_defconfig:omap3-beagle
arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
arm:overo:multi_v7_defconfig:omap3-overo-tobi

I would expect all omap2/3/4/5 runtime tests with multi_v7_defconfig to fail.

Also, FWIW,

Fixes: 6a9b2ff07d04 ("mmc: host: omap_hsmmc: return on fatal errors from 
omap_hsmmc_reg_get")

Guenter

> > ---
> >  arch/arm/configs/multi_v7_defconfig |1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/configs/multi_v7_defconfig 
> > b/arch/arm/configs/multi_v7_defconfig
> > index 5fd8df6..f497c96 100644
> > --- a/arch/arm/configs/multi_v7_defconfig
> > +++ b/arch/arm/configs/multi_v7_defconfig
> > @@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y
> >  CONFIG_REGULATOR_MAX77686=y
> >  CONFIG_REGULATOR_MAX77693=m
> >  CONFIG_REGULATOR_PALMAS=y
> > +CONFIG_REGULATOR_PBIAS=y
> >  CONFIG_REGULATOR_S2MPS11=y
> >  CONFIG_REGULATOR_S5M8767=y
> >  CONFIG_REGULATOR_TPS51632=y
> > -- 
> > 1.7.9.5
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > 
--
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: mysterious crashes on OMAP5 uevm

2015-09-08 Thread Tony Lindgren 
* Grazvydas Ignotas  [150908 05:50]:
> Hi,
> 
> this is a longstanding problem I'm seeing since the very beginning,
> which was around 3.12 or so (when I've first got the hardware) and it
> seems 4.2 is affected by it still. Basically what happens is Xorg
> randomly segfaults at some "impossible" location. I don't have the
> details at the moment (could get them is needed), but from what I
> examined with gdb some time ago the situation did not make any sense.
> 
> There are 2 workarounds that I know which make the problem go away
> (one is enough):
> - recompile Xorg with -marm (I'm using Debian armhf so it's thumb2 by default)
> - disable ARCH_MULTI_V6 in the kernel config
> 
> Because of the above workarounds I have forgotten about it several
> times, but it regularly comes back and bites again. It would look like
> some missing erratum workaround, but I have all of them enabled in the
> kernel.
> 
> Does anyone know about this? Perhaps some missing erratum workaround
> in the bootloader? u-boot isn't too old here (2015.07).

Seems like some incorrect handling with CONFIG_CPU_V6 compiled in.. 
Maybe try to narrow it down by commenting out some CONFIG_CPU_V6 and
__LINUX_ARM_ARCH__ = 6 ifdefs in the git grep CONFIG_CPU_V6
places ignoring uncompress and davinci code.

Do you have some easy way to reproduce this issue?

Regards,

Tony
--
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] gpio: omap: Fix gpiochip_add() handling for deferred probe

2015-09-08 Thread Linus Walleij 
On Fri, Aug 28, 2015 at 8:44 PM, Tony Lindgren  wrote:

> Currently we gpio-omap breaks if gpiochip_add() returns -EPROBE_DEFER:
>
> [0.57] gpiochip_add: GPIOs 0..31 (gpio) failed to register
> [0.57] omap_gpio 4831.gpio: Could not register gpio chip -517
> ...
> [3.67] omap_gpio 4831.gpio: Unbalanced pm_runtime_enable!
>
> Let's fix the issue by adding the missing pm_runtime_put() on error.
>
> Cc: Grygorii Strashko 
> Cc: Javier Martinez Canillas 
> Cc: Kevin Hilman 
> Cc: Santosh Shilimkar 
> Signed-off-by: Tony Lindgren 
> ---
>  drivers/gpio/gpio-omap.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index b0c57d5..f09bf0b 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1232,8 +1232,11 @@ static int omap_gpio_probe(struct platform_device 
> *pdev)
> omap_gpio_mod_init(bank);
>
> ret = omap_gpio_chip_init(bank, irqc);
> -   if (ret)
> +   if (ret) {
> +   pm_runtime_put_sync(bank->dev);
> +   pm_runtime_disable(bank->dev);
> return ret;
> +   }
>
> omap_gpio_show_rev(bank);

Patch applied for fixes with Santosh's ACK.

Yours,
Linus Walleij
--
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-08 Thread Roger Quadros 
Alan,

On 08/09/15 17:34, Alan Stern wrote:
> On Tue, 8 Sep 2015, Roger Quadros wrote:
> 
>> On 08/09/15 11:31, Peter Chen wrote:
>>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
 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.

>>>
>>> Roger, not only chipidea and dwc2, I think the musb uses the same
>>> hierarchy. If the host, device, and otg share the same register
>>> region, host part can't be a platform driver since we don't want
>>> to remap the same register region again.
>>>
>>> So, in the design, we may need to consider both situations, one
>>> is otg/host/device has its own register region, and host is a
>>> separate platform device (A), the other is three parts share the
>>> same register region, there is only one platform driver (B).
>>>
>>> A:
>>>
>>> IP core device 
>>> |
>>> |
>>>   |-|-|
>>>   gadget   host platform device 
>>> |
>>> roothub
>>>
>>> B:
>>>
>>> IP core device
>>> |
>>> |
>>>   |-|-|
>>>   gadget roothub
>>> 
>>>
 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?

>>>
>>> A flag stands for this hcd controller is the same with otg controller
>>> can be used, this flag can be stored at struct usb_otg_config.
>>
>> What if there is another architecture like so?
>>
>> C:
>>  [Parent]
>> |
>> |
>>  |--|--|
>>  [OTG core]  [gadget][host]
>>
>> We need a more flexible mechanism to link the gadget and
>> host device to the otg core for non DT case.
>>
>> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
>>
>> e.g.
>> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
>>
>> If otg is NULL it will try DT otg-controller property or parent to
>> get the otg controller.
> 
> This seems a lot like something Peter and I discussed recently.  See
> 
>   http://marc.info/?l=linux-usb=143977568021328=2
> 
> and the following messages in that thread.
> 

If I understood right, your proposal was to add a usb_pointers data
struct to the device's drvdata?

This is fine only if the otg/gadget/host share the same device.
It does not solve the problem where each have different platform devices.

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 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node

2015-09-08 Thread Kevin Hilman 
On Wed, Sep 2, 2015 at 6:07 AM, Tony Lindgren  wrote:
> * Neil Brown  [150901 23:23]:
>> Kevin Hilman  writes:
>>
>> > ping... this boot failure has now landed in mainline
>>
>> sorry, I'm on leave at the moment and travelling so I'm unlikely to be
>> able to look at this properly.  I should be able to examine this issue
>> before the end of the month but cannot promise sooner than that (though
>> it is not impossible).
>>
>> Maybe it would be best to just revert it until a proper analysis can be
>> done.
>
> OK yeah let's revert this one for now until we know what goes wrong.

Looks like this is still in mainline.

Tony, can you revert?

Kevin
--
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